Future reuse of code

[Harley]

Re: Future reuse of code


"Jacob" <jacob@yahoo.co m> wrote in message
news:3F2E721E.5 080709@yahoo.co m...
| James Cameron wrote:
| > Hi I'm developing a program and the client is worried about future
| > reuse of the code. Say 5, 10, 15 years down the road. This will be a
| > major factor in selecting the development language. Any comments on
| > past experience, research articles, comments on the matter would be
| > much appreciated. I suspect something like C would be the best based
| > on comments I received from the VB news group.
|
| NOTHING will run 10 years from now!

You might want to qualify this by language.
(NOTHING written in ? will run 10 years from now!)
Be careful, there are people out there with 10 year old software that is
still running.

Come to think of it, you might want to include the hardware, and operating
system.

|
| So just make sure (in logical design, system architechture,
| well written easy-to-read code, proven algorithms, adequate
| domain and storage models and system documentation presence)
| that the fundamental ideas can move along.
|

[Jacob]

Re: Future reuse of code

Harley wrote:

[color=blue]
> | NOTHING will run 10 years from now!
>
> You might want to qualify this by language.[/color]

Just keep it as a rule of thumb. If something made today
runs 10 years from now it is either pure luck or a dead
slow organization. If you expect the world to go on, you
oraganize your software so it can go along.

The fact that 15 years old Cobol (or C or PL/1 or UniFace)
software is still out there is no *proof* that it has
outlived time. Maybe it's is just written in a way that
makes it impossible to move on.

[Dario]

Re: Future reuse of code

Jacob wrote:[color=blue]
> James Cameron wrote:
>[color=green]
>> Hi I'm developing a program and the client is worried about future
>> reuse of the code. Say 5, 10, 15 years down the road. This will be a
>> major factor in selecting the development language. Any comments on
>> past experience, research articles, comments on the matter would be
>> much appreciated. I suspect something like C would be the best based
>> on comments I received from the VB news group.[/color]
>
> NOTHING will run 10 years from now![/color]

Ehm....

I have a lot of C programs that run perfectly
after more than 10 years!

E.g. see the following C programs that play Draughts
(Dama in italian) written on september 1989:
You can compile the original untouched C-source
(e.g. using gcc) and play it again immediately!

- Dario

#define linee_bianche (void)printf("\ n\n");
#define odd(exp) ((exp)%2)

typedef int scacchiera[9][9];

struct mossa {
int a,b,a1,b1;
int valutatore;
};

static scacchiera s;


static
inizializza(s)
scacchiera s;
{
int r,c;

for (r=1; r<=8; r++)
for (c=1; c<=8; c++)
if (odd(r+c) || (r==4) || (r==5))
s[r][c] = 0;
else
{
if (r>=1 && r<=3)
s[r][c]= -1;
else
s[r][c] = 1;
}
}


static
read_2n(a,b)
int *a;
int *b;
{
char c;

*a = 0;
*b = 0;
do
if (1 != scanf("%c",&c))
c = '0';
while (c<'0' || c>'8');
*a = c-'0';
if (*a)
{
do
if (1 != scanf("%c",&c))
c = '0';
while (c<'0' || c>'8');
*b = c-'0';
if (*b == 0)
*a = 0;
}
}


static
posizione_in_sc acchiera(r,c)
int r;
int c;
{
return (r >= 1) && (r <= 8) && (c >= 1) && (c <= 8);
}


static
muovi(s,r,c,r1, c1)
scacchiera s;
int r,c,r1,c1;
{
s[r1][c1] = s[r][c];
s[r][c] = 0;
if (abs(r1-r) == 2)
s[(r1+r)/2][(c1+c)/2] = 0;
if ( ((r1==1) && (s[r1][c1]== 1))
|| ((r1==8) && (s[r1][c1]==-1))
)
{
s[r1][c1] = s[r1][c1]*2;
(void)printf(" DAMA!\n");
}
}


static
leggi_mossa(s)
scacchiera s;
{
int casella_partenz a_giusta;
int r,c;
int fine;

fine = 0;
casella_partenz a_giusta = 0;
do
{
linee_bianche;
(void)printf(" DA? ");
read_2n(&r,&c);
if (posizione_in_s cacchiera(r,c))
{
if (s[r][c] > 0)

leggi_posizione _arrivo(s,r,c,& casella_partenz a_giusta);
else
(void)printf(" POSIZIONE DI PARTENZA ERRATA.\n");
}
else
{
fine = 1;
linee_bianche;
(void)printf(" HAI ABBANDONATO E QUINDI HAI PERSO.\n");
}
}
while (!(casella_part enza_giusta || fine));
return fine;
}


static
leggi_posizione _arrivo(s,r,c,m ossa_giusta)
scacchiera s;
int r,c;
int *mossa_giusta;
{
int r1,c1;

(void)printf(" A? ");
read_2n(&r1,&c1 );
if (posizione_in_s cacchiera(r1,c1 ))
{
if (mossa_corretta (s,r,c,r1,c1))
{
*mossa_giusta = 1;
muovi(s,r,c,r1, c1);
if (abs(r1-r) == 2)
leggi_altre_pre se(s,r1,c1);
}
else
(void)printf(" MOSSA SCORRETTA.\n");
}
else
(void)printf(" RICOMINCIA DA CAPO.\n");
}


static
mossa_corretta( s,r,c,r1,c1)
scacchiera s;
int r,c,r1,c1;
{
int casella_arrivo_ vuota, senso_giusto, presa_corretta;
int rr,cc;

casella_arrivo_ vuota = s[r1][c1] == 0;
senso_giusto = (abs(r1-r)==abs(c1-c)) &&
(abs(s[r][c])==2 || (r1-r)*s[r][c] < 0);
rr = (r1+r)/2;
cc = (c1+c)/2;
if (abs(r1-r) == 2)
presa_corretta = (s[r][c]*s[rr][cc] < 0) &&
(abs(s[r][c]) >= abs(s[rr][cc]));
else
presa_corretta = abs(r1-r) == 1;
return casella_arrivo_ vuota && senso_giusto && presa_corretta;
}


static
leggi_altre_pre se(s,r,c)
scacchiera s;
int r,c;
{
int r1,c1;

do
{
(void)printf(" +A? ");
read_2n(&r1,&c1 );
if (posizione_in_s cacchiera(r1,c1 ))
{
if ((abs(r1-r)==2) && mossa_corretta( s,r,c,r1,c1))
{
muovi(s,r,c,r1, c1);
r = r1;
c = c1;
}
else
(void)printf(" PRESA SCORRETTA.\n");
}
}
while (posizione_in_s cacchiera(r1,c1 ));
}


static
stampa_scacchie ra(s)
scacchiera s;
{
int r,c;

linee_bianche;
(void)printf(" 1 2 3 4 5 6 7 8\n");
for (r=1; r<=8; r++)
{
(void)printf(" %1d ",r);
for (c=1; c<=8; c++)
switch (s[r][c])
{
case -2: (void)printf("D N"); break;
case -1: (void)printf("-N"); break;
case 0: if (odd(r+c))
(void)printf(" ");
else
(void)printf("--");
break;
case 1: (void)printf("-B"); break;
case 2: (void)printf("D B"); break;
}
(void)printf("\ n");
}
}


static
elabora_mossa(s )
scacchiera s;
{
int r,c;
int fine;
struct mossa m;

fine = 0;
m.valutatore = -99;
for (r=1; r<=8; r++)
for (c=1; c<=8; c++)
if (s[r][c] < 0)
esamina_mossa(s ,r,c,&m,0);
if (m.valutatore == -99)
{
fine = 1;
linee_bianche;
(void)printf(" HAI VINTO.\n");
}
else
{
/* (void)printf("% c",12); */
linee_bianche;
(void)printf(" DA %1d %1d\n",m.a,m.b) ;
do
{
(void)printf(" A %1d %1d\n",m.a1,m.b 1);
muovi(s,m.a,m.b ,m.a1,m.b1);
m.valutatore = -99;
if (abs(m.a1-m.a) == 2)
esamina_mossa(s ,m.a1,m.b1,&m,1 );
}
while(!( (m.valutatore == -99)
|| ( (m.valutatore <= 18)
&& ( (m.a==1) || (m.a==8) || (m.b==1) || (m.b==8) )
)
));
}
return fine;
}


static
esamina_mossa(s ,r,c,m,mangia_s olamente)
scacchiera s;
int r,c;
struct mossa *m;
int mangia_solament e;
{
int r1,c1,dr,dc;

for (dr= -1; dr<=1; dr++)
for (dc= -1; dc<=1; dc++)
if ((dr!=0) && (dc!=0) && ((s[r][c]==-2) || (dr==1)))
{
r1 = r+dr;
c1 = c+dc;
if (posizione_in_s cacchiera(r1,c1 ))
{
if ((s[r1][c1] == 0) && ! mangia_solament e)
valuta_mossa(s, r,c,r1,c1,m);
else
if ( (s[r1][c1] > 0)
&& (abs(s[r][c])>=
abs(s[r1][c1]))
)
{
r1 += dr;
c1 += dc;
if
(posizione_in_s cacchiera(r1,c1 ))
if (s[r1][c1] == 0)

valuta_mossa(s, r,c,r1,c1,m);
}
}
}

}


static
valuta_mossa(s, r,c,r1,c1,m)
scacchiera s;
int r,c;
int r1,c1;
struct mossa *m;
{
int dr,dc,v;

if (r1>r)
dr = 1;
else
dr = -1;
v = 0;
if (r==1)
{
if (s[r][c] == -1)
v-= 8;
else
v-= 1;
}
if (dr ==- 1)
v+= 1;
if (s[r][c] == -1)
v+= 2;
if ((r==8) || (r==1))
v+= 4;
if (s[r][c]==-1 && r1==8)
v+= 8;
if (abs(r1-r)==2)
v+= 20;
else
if (presa(s,r,c))
v+= 6;
for (dc= -1; dc<=1 ; dc++)
if (dc!=0 && posizione_in_sc acchiera(r1+dr, c1+dc))
{
if (s[r1+dr][c1+dc]<0)
v+= 4;
else
if (s[r1+dr][c1+dc]>0 &&
possibile_presa (s,r,c,r1,c1,dr ,dc))
v-= 8;
}
if (v > m->valutatore)
{
m->valutatore = v;
m->a = r;
m->b = c;
m->a1 = r1;
m->b1 = c1;
}
}


static
possibile_presa (s,r,c,r1,c1,dr ,dc)
scacchiera s;
int r,c,r1,c1,dr,dc ;
{
int cas_davanti_vuo ta;
int cas_dietro_occu pata;
int avversario_temi bile;

if (posizione_in_s cacchiera(r1-dr,c1-dc))
{
cas_davanti_vuo ta = (s[r1-dr][c1-dc]==0) ||
(r1-dr==r) && (c1-dc==c) ||
(r1-2*dr==r) && (c1-2*dc==c);
avversario_temi bile = s[r1+dr][c1+dc] >= -s[r][c];
cas_dietro_occu pata = 1;
if (abs(r1-r)==2 && posizione_in_sc acchiera(r1+2*d r,c1+2*dc))
cas_dietro_occu pata = s[r1+2*dr][c1+2*dc] != 0;
return cas_davanti_vuo ta && cas_dietro_occu pata &&
avversario_temi bile;
}
else
return 0;
}


static
presa(s,r,c)
scacchiera s;
int r,c;
{
int dr,dc;
int p;

p = 0;
if ( (r>=2) && (r<=7) && (c>=2) && (c<=7) )
for (dr= -1; dr<=1; dr++)
for (dc= -1; dc<=1; dc++)
if ( (s[r+dr][c+dc] > 0)
&& (s[r-dr][c-dc] == 0)
)
p = p || (dr==1) || (s[r+dr][c+dc]==2);
return p;
}


static
help()
{
(void)printf("D ama (c) 1987 - Dario Dariol\n");
(void)printf("\ n");
(void)printf("I l computer (nero) gioca contro l'avversario (bianco)\n");
(void)printf("a dottando le regole della Dama italiana.\n");
(void)printf("L 'unica eccezione e' che le prese NON sono obbligatorie\n" );
(void)printf("\ n");
(void)printf("L e mosse vengono comunicate scrivendo riga e colonna\n");
(void)printf("d ella casella da cui si muove o su cui si arriva.\n");
(void)printf("U no 0 significa abbandono e/o mossa scorretta.\n");
(void)printf("\ n");
}


main()
{
help();
inizializza(s);
while(1)
{
stampa_scacchie ra(s);
if (leggi_mossa(s) )
break;
if (elabora_mossa( s))
break;
}
}

[Julián Albo]

Re: Future reuse of code

Dario escribió:
[color=blue]
> E.g. see the following C programs that play Draughts
> (Dama in italian) written on september 1989:[/color]

(snip)
[color=blue]
> help()
> {
> (void)printf("D ama (c) 1987 - Dario Dariol\n");[/color]

1989 or 1987?

Regards.

[jce]

Re: Future reuse of code

"Jacob" <jacob@yahoo.co m> wrote in message
news:3F2E7816.8 070301@yahoo.co m...[color=blue]
> Harley wrote:
> The fact that 15 years old Cobol (or C or PL/1 or UniFace)
> software is still out there is no *proof* that it has
> outlived time. Maybe it's is just written in a way that
> makes it impossible to move on.[/color]

Or that it works and has done what it was supposed to for 15 years.
That's like saying that everyone over 75 has outlived their time coz they're
not supposed to be that old.

JCE

[jce]

Re: Future reuse of code

"Dario" <dario@despamme d.com> wrote in message
news:bglt5q$o06 $1@fata.cs.inte rbusiness.it...[color=blue][color=green]
> > NOTHING will run 10 years from now![/color]
> I have a lot of C programs that run perfectly
> after more than 10 years![/color]
<code snipped>
I like the previous post that said to use english :-) I don't think I can
follow this very easily.
JCE

[jce]

Re: Future reuse of code

"Andy Fish" <ajfish@blueyon der.co.uk> wrote in message
news:nDpXa.1170 4$SQ1.11131@new s-binary.blueyond er.co.uk...[color=blue]
> I would have to put my vote for java, simply because it's less
> hardware-dependent than the others.
>
> It's quite possible that JVM's in 10-15 years will be able to execute java
> code you build now (in the same way that office XP can still open up a[/color]
word[color=blue]
> 2 document). If the source got lost you could even have a reasonable go at
> decompiling it, which I would definitely not fancy with any of the binary
> formats.
>
> Andy[/color]
Not likely.

http://java.sun.com/products/jdk/1.2/compatibility.html#incompatibilities1.2

If you link to 1.1 you get:

Products listed on this page have completed the Sun End of Life process.

None of the items listed though would send a development area into apoplexy
:-)

JCE

[Howard Brazee]

Re: Future reuse of code


On 4-Aug-2003, "Harley" <dennis.harleyN oSpam@worldnet. att.net> wrote:
[color=blue]
> | NOTHING will run 10 years from now!
>
> You might want to qualify this by language.
> (NOTHING written in ? will run 10 years from now!)
> Be careful, there are people out there with 10 year old software that is
> still running.[/color]

Correct - most of the software I work with is older than that.

But if we are talking about "reuseable" , I wonder what we should be looking for.
Do we worry about plugging in the algorithm used to determine depreciation so
we don't have to analyze it again?

Coding it is simple in any language, so I am guessing we are talking about
keeping analysis and testing down. Except we will still need to analyze to
make sure conditions are still correct.

And we test as much as we can afford. In stand alone programs, we can afford
to test everything. If we code a widely used object, we had better make sure
the design is such that we can live with less testing.

Designing for reusability is designing for what we think is a characteristic of
good coding. Which is not a primary goal at all.

[Dario]

Re: Future reuse of code

Julián Albo wrote:
[color=blue][color=green]
>> (void)printf("D ama (c) 1987 - Dario Dariol\n");[/color]
>
> 1989 or 1987?[/color]

In 1987 I written the program.
My last correction to the same program was made
at September 8, 1989 17:56 (Italian local time).

- Dario

[Harley]

Re: Future reuse of code


"Howard Brazee" <howard@brazee. net> wrote in message
news:bgm1dq$p8o $1@peabody.colo rado.edu...
|
| On 4-Aug-2003, "Harley" <dennis.harleyN oSpam@worldnet. att.net> wrote:
|
| > | NOTHING will run 10 years from now!
| >
| > You might want to qualify this by language.
| > (NOTHING written in ? will run 10 years from now!)
| > Be careful, there are people out there with 10 year old software that is
| > still running.
|
| Correct - most of the software I work with is older than that.
|
| But if we are talking about "reuseable" , I wonder what we should be
looking for.

My GUESS is inheritance, and polymorphism.

| Do we worry about plugging in the algorithm used to determine
depreciation so
| we don't have to analyze it again?
|
| Coding it is simple in any language, so I am guessing we are talking about
| keeping analysis and testing down. Except we will still need to analyze
to
| make sure conditions are still correct.
|
| And we test as much as we can afford. In stand alone programs, we can
afford
| to test everything. If we code a widely used object, we had better make
sure
| the design is such that we can live with less testing.

A business rule should be able to be tested outside the system
One of the suggestions in extreme programming is that you have a test driver
BEFORE you start coding.
System integration testing is still a requirement, but the test driver
should have uncovered any problems not associated with integration issues.
You still have an Oops issue, but the Opps should be associated with the
integration, not the functionality of the object.

| Designing for reusability is designing for what we think is a
characteristic of
| good coding. Which is not a primary goal at all.

I think this is a personal preference, like a style issue.

[Marco van de Voort]

Re: Future reuse of code

In article <45ab836a.03080 31802.2c9685eb@ posting.google. com>, James Cameron wrote:[color=blue]
> Hi I'm developing a program and the client is worried about future
> reuse of the code. Say 5, 10, 15 years down the road. This will be a
> major factor in selecting the development language. Any comments on
> past experience, research articles, comments on the matter would be
> much appreciated. I suspect something like C would be the best based
> on comments I received from the VB news group.[/color]

Mathlab? The only one I can think of being around over 15 years :-)

[pete kirkham]

Re: Future reuse of code

Marco van de Voort wrote:
[color=blue]
> In article <45ab836a.03080 31802.2c9685eb@ posting.google. com>, James Cameron wrote:
>[color=green]
>>Hi I'm developing a program and the client is worried about future
>>reuse of the code. Say 5, 10, 15 years down the road. This will be a
>>major factor in selecting the development language. Any comments on
>>past experience, research articles, comments on the matter would be
>>much appreciated. I suspect something like C would be the best based
>>on comments I received from the VB news group.[/color]
>
>
> Mathlab? The only one I can think of being around over 15 years :-)[/color]

FORTRAN. I've reused FORTRAN aerodynamics models that were 30+ years old
because they captured the domain model and the domain model hasn't changed.

LISP. I've reused LISP symbolic math processing models were 20 ish
years old because they captured the domain model and the domain model
hasn't changed.

Java was designed for portable GUIs, though is a lot more general
purpose now. Does your domain model map well to the constructs in Java?
Even if you can reuse a GUI in 20 years time, Java swing will look as
old to a user then as MSDOS 3 does to a OS X user now.

C models the architecture of a defunct hardware platform, and maps well
enough to other hardware platforms to give performance efficiencies.

The closer a language is to the language of your domain model, and the
better the the representation of the domain you produce, the longer your
software will by usefully reused.


Pete

[Alistair Maclean]

Re: Future reuse of code

In message <MPG.19983f85b9 3d676a98981e@ne ws.megapathdsl. net>, Randy
Howard <randy.howard@F OOmegapathdslBA R.net> writes[color=blue]
>What about ruby, perl, various assembly groups, applescript, delphi,
>ada, awk, dylan, eiffel, forth, fortran, icon, lsip, logo, modula2,
>oberon, php, scheme, smalltalk, prolog, etc.?
>
>A truly astute troll would have included at least the above.[/color]

A with-it truly astute troll would have mentioned Rebol.

--
Alistair Maclean

[Marco van de Voort]

Re: Future reuse of code

In article <3f2ea56a$0$184 92$cc9e4d1f@new s.dial.pipex.co m>, pete kirkham wrote:[color=blue]
> Marco van de Voort wrote:
>[color=green]
>> In article <45ab836a.03080 31802.2c9685eb@ posting.google. com>, James Cameron wrote:
>>[color=darkred]
>>>Hi I'm developing a program and the client is worried about future
>>>reuse of the code. Say 5, 10, 15 years down the road. This will be a
>>>major factor in selecting the development language. Any comments on
>>>past experience, research articles, comments on the matter would be
>>>much appreciated. I suspect something like C would be the best based
>>>on comments I received from the VB news group.[/color]
>>
>>
>> Mathlab? The only one I can think of being around over 15 years :-)[/color]
>
> FORTRAN. I've reused FORTRAN aerodynamics models that were 30+ years old
> because they captured the domain model and the domain model hasn't changed.[/color]
[color=blue]
> LISP. I've reused LISP symbolic math processing models were 20 ish
> years old because they captured the domain model and the domain model
> hasn't changed.[/color]

Don't be annecdotical. Reuse all code you rewrite now, and something
that will be in major use then (so that reusing makes sense at all)

I can only think of two possible candidates. TeX, and Mathlab, both in a
different realm. I wouldn't dare to bet on another one.

[JerryMouse]

Re: Future reuse of code

Jacob wrote:[color=blue]
> Harley wrote:
>
>[color=green][color=darkred]
>>> NOTHING will run 10 years from now![/color]
>>
>> You might want to qualify this by language.[/color]
>
> Just keep it as a rule of thumb. If something made today
> runs 10 years from now it is either pure luck or a dead
> slow organization. If you expect the world to go on, you
> oraganize your software so it can go along.
>
> The fact that 15 years old Cobol (or C or PL/1 or UniFace)
> software is still out there is no *proof* that it has
> outlived time. Maybe it's is just written in a way that
> makes it impossible to move on.[/color]

If you work for a large organization (more than 100,000 employees), I'll
wager dollars to donuts your paycheck was produced by a COBOL program that's
more than twenty years old (assuming your company has been around that
long).

A prudent company wants a piece of software - like a building - to just sit
there and do its job. While 'ancient' programs do have to have maintenance
from time to time, there's not a lot of maintenance to do on a General
Ledger program (whose basic rules have remined unchanged since the 16th
century).