Future reuse of code
James Cameron
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.
Thanks for the help in advance
James Cameron
Alf P. Steinbach
Crossposted (originally, not by me) to
comp.lang.cobol,
comp.lang.c,
comp.lang.c++,
comp.lang.java.programmer,
comp.lang.pascal.ansi-iso
]
On 3 Aug 2003 19:02:14 -0700, james....@bindereng.com.au (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.
First of all, if you've been given the impression of a perspective of
15 years for code reuse for something that was originally intended as
a VB application, then you've most probably been hoodwinked, or else
your client is taking a position based on incompetence.
Having said that, it's true that VB is not a language where you can
expect long-term code reuse: the last version of VB is not compatible
with the next-to-last version, and that's also been the case earlier.
But keep in mind that reusability is a question not only of having
an established language standard: it also depends on complexity (high
for low-level language, low for high-level language), the skills of
the reusers, the policies (not the least, the contracts) in use, and
so on; not the least, how much is the client prepared to pay up-front
for later potential reuse? In short, selecting a language is just a
small part of fostering reusability. So my advice is to select the
language(s) based on the problem to be solved and your and possibly
also the client's familiarity with the language(s).
Thomas Gagné
now? Why not consider what makes code from 15 years ago reusable?
Regardless of the language, the reusability of the code is significantly
dependent on how accessible it is. Not accessible in terms of getting to the
source, but in terms of how the code is accessible from other languages or
programs.
To make a long story short:
1) write the system so that it's available across the network
2) write the system so that it's transaction based
3) write the system so that it's transactions are not language dependent.
Make them text based, easily readible by humans and easily parsable by
software (XML is a good choice)
Roedy Green
> I suspect something like C would be the best based
>on comments
C is already disappearing. For longevity you want to pick something
that is popular, and that is rising in popularity.
Java is a pretty safe bet. Even if it dies the code is quite vanilla
and should be easy to port to whatever replaces it.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Harald Hein
> I'm developing a program and the client is worried about future
> reuse of the code. Say 5, 10, 15 years down the road.
Tell your customer a lie. No one can predict 5 years, let alone 15 into
the future in this business. If your client asks, he doesn't have much
clue and will be happy with any answer.
James J. Gavan
James Cameron wrote:
It's your choice but two points :-
1. There are COBOL programs which are being maintained by programmers
who are 'younger' than the programs they are maintaining ! That is also
likely to occur in the future.
2. Object Orientation is currently available in COBOL from IBM, Fujitsu
and Micro Focus - the last two having their own set of Base classes,
including lists(collections) and GUI classes. Plus - lots of other
packages that COBOL can use for GUIs, including invoking C, Java, VB, or
via MS .Net..
A Bag Of Memes
"James Cameron" <james....@bindereng.com.au> wrote in message
news:45ab836a.03080...@posting.google.com...
Why would language choice affect code reuse? You can reuse code written in
any language as long as you care to.
Malcolm
"James Cameron" <james....@bindereng.com.au> wrote in message
> 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.
>
Your best bet is conservative C89.
Why not C++? Because the standard template library is only a few years old.
Things might have changed out of recognition in 15 years time. You will
stillbe able to compile the code, probably, but it will be difficult to
maintain.
C99 may never be implemented.
Java COBOL and Visual Basic I know little about. VB is unstable, COBOL is
virtually obsolete. Java might be an OK choice but is rather tied to the
net. A C file, OTOH, will almost certainly be linkable in ten years time.
John D.
> 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.
The best language to ensure future reuse of the code is english.
Whatever programming language you chose always remember to document
your code.
Buster Copley
Hey, be careful! Not everyone's an anglophone. Other than that,
very well said.
Buster
Andy Fish
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 word
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
"James Cameron" <james....@bindereng.com.au> wrote in message
news:45ab836a.03080...@posting.google.com...
Peter E.C. Dashwood
"James Cameron" <james....@bindereng.com.au> wrote in message
news:45ab836a.03080...@posting.google.com...
> 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.
>
The source language is irrelevant in terms of code re-use. (It is OBJECT
code that will be re-used...)
You should select a source language SUITABLE FOR THE JOB YOU WANT TO DO!!!
Then make sure that an OO or modular approach is adopted, wrap your
functions as components, and you can reuse them FOR EVER not just 15 years.
Pete.
Donald Tees
news:3f2e2...@news.athenanews.com...
Aren't you talking about marriage or something? About the *only* code I
know that is still running after 15 years use is in Cobol. I could say the
same for 30 years.
Even in the last five years, the components I have used have evolved into
different packaging, required updates for each OS, etc. etc.
Donald
Paul Barnett
"Malcolm" <mal...@55bank.freeserve.co.uk> wrote in message
news:bgktdu$n07$1...@news8.svr.pol.co.uk...
> ... COBOL is
> virtually obsolete...
>
Hey! Cut that out!
Check out this site: www.microfocus.com
LX-i
^^^^^^^^^^^^^
You're a great filmmaker - why are you switching to programming? :)
(I'm a regular poster in comp.lang.cobol)
You really need to have them define what they mean by "code reuse". In
general, if the design of the system is done using components, this
really doesn't have to be an issue. A component could be written in any
number of languages, as long as it adheres to a standard interface (such
as COM).
And, 5 to 15 years down the road, what are they going to be "reusing"?
Seems to me, if they're interested in reuse, they'd use whatever
language you use on this project. At that point, the only decision you
need to make is, what language best supports the business logic you're
trying to automate?
Once you make this decision, structure the system in such a way that it
resembles a collection of building blocks (whether it's broken out by
component, by a collection of common subroutines, copybooks/macros,
whatever). Then, using your rationale for your language choice, and the
modularity design you've chosen, formulate a point paper for your client
detailing why the language you've chosen is the best for their needs,
and how you're posturing them for future code reuse.
Personally, I work on a large aircraft maintenance program for a major
military branch ;) . The system is written in COBOL, and we mostly use
copybooks (similar to macros in C) for our reuse. Each copybook has
comments that define the input parameters expected, and the output one
can expect from it. That way, if the process changes, we change the
copybook. The disadvantage to this technique is that it requires each
program that copies it to be recompiled (rebuilt).
I'm working on a few initiatives to convert this to common subroutines,
that can be modified and "switched out" without having to modify the
underlying programs. This is showing a lot of promise, and I know that
there are other regular posters here who have not only done this
successfully, but have also utilized C, VB, C++, even .NET classes and
components from within COBOL.
Of course, the bottom line - decide what language would be best, then
convince your client of your genius. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ AIM: LXi0007 ~
~ _____ / \ | ~ E-mail: LXi...@Netscape.net ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please post if you wish to be contacted privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LX-i
> Java COBOL and Visual Basic I know little about. VB is unstable, COBOL is
> virtually obsolete.
What? COBOL is obsolete? I guess OO and .NET are obsolete too... ;)
Josef Garvi
> I would have to put my vote for java, simply because it's less
> hardware-dependent than the others.
I second that. Writing for a specific OS truly blocks your options if that
OS becomes obsolete, or if their licensing policy becomes an obstacle in
the future.
--
Josef Garvi
"Reversing desertification through drough tolerant trees"
http://www.eden-foundation.org/
new income - better environment - more food - less poverty
Harley
"Malcolm" <mal...@55bank.freeserve.co.uk> wrote in message
news:bgktdu$n07$1...@news8.svr.pol.co.uk...
|
|
| > 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.
| >
| virtually obsolete.
COBOL ain't dead yet.
It has a history, and some code that surpasses the 15 year reusability
requirement.
Thomas Gagné
accessible behind CICS. I can connect to CICS from any platform using various
combinations of middleware, and avail my new system of the legacy of
COBOL-implemented functions as long as those function serve the customer's
purpose.
Donald Tees wrote:
> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
> news:3f2e2...@news.athenanews.com...
>
>>
<snip>
Duncan Smith
You seem to have forgotten to cross-post to comp.lang.python. :-)
Duncan
Thomas Gagné
Peter E.C. Dashwood wrote:
>
> The source language is irrelevant in terms of code re-use. (It is OBJECT
> code that will be re-used...)
>
Simply by virtue of being OO it is not guaranteed to be reusable. Paradigm is
no substitute for design.
> You should select a source language SUITABLE FOR THE JOB YOU WANT TO DO!!!
Well said.
>
> Then make sure that an OO or modular approach is adopted, wrap your
> functions as components, and you can reuse them FOR EVER not just 15 years.
Again, well said. Good advice.
jce
news:45ab836a.03080...@posting.google.com...
<---repeated from another post---->
In 5/10/15 years the questions come down to (a) Do we have time and money to
port (b) Can we survive with what we have or (c) is there a market product
that has what we want.
In general the argument seems to go straight to (b) and (c). No one wants
to pay for an upgrade.
<---repeated from another post---->
Java already has issues. The backward compatibility isn't the 100%
promised....you constantly need to upgrade to get the latest and greatest.
The API s have a lifecycle of a year or two so you are constantly faced with
question (a).
Seems to me that .NET would work best here because then you can pick the
source of your choice. I don't know much about this so I shouldn't really
comment.
You don't say what the application is which makes the response hard. Some
language are better for some things than others ;-)
It might be better for example as a plug-in to another application (say
eclipse) rather than you developing an entire framework.
I would always suggest a search on sourceforge to see if something is out
there that helps....
Personally I have four views - when you are talking of multiple programmers:
1. If you have COBOL programmers use COBOL. If you have C programmers use
C. This is built on the shaky assumption that they are good coders. I
would rather have competent programmers writing competent code that provides
higher stability than competent programmers writing immature code. Bear in
mind that COBOL has an underground "cool" factor now....no, really...
2. Java is the easiest answer to sell and as pointed out here...it's
pretty vanilla (which doesn't mean no gotchas) but should be relatively
readable. So if you're in competent programmer you can understand this
easily enough.
3. Does anyone really look to an application to last this long? Seems to
me that everything goes through a rewrite as part of natural evolution. I'd
rather go for quality than anything (which means I invested in Betamax over
VHS and Token Ring over Ethernet I suppose).
4. The MOST important question is ........does it matter if I can reuse it
in 5 years if I cannot get it out of the door quickly now? No point
architecting a 15 year plan if it takes 5 years to execute and you need it
in 3 months. I didn't get that priority from your original note.
If you are on your own then I only have one comment:
Narrow choices down to what you are comfortable with then add those
languages you are confident of handling. You have to deliver the quality
product NOW and not 15 years from now.
Here's the kicker:
Imagine......Sun goes belly up in 2006....Microsoft antes up with a few
billion to buy the Java licensing rights....woo hooo.....We'll all try
desperately to port to Inga's free open source virtual software layer Ingot
that runs on EyeBeeEmux to remove Microsoft dependencies....(remember they
once thought the earth was flat and that Senators were for the people).
In 2015 we no longer run processors as we know them. Electrons have been
isolated on switches that are built on self managed bio matter developed in
the Democratic People's China by po'd shepherds who refuse to divulge their
methods to the Communist States of America.
JCE
(Notice the lack of Pascal support here....why did we ignore ADA?)
jce
news:luiriv8e907s59abt...@4ax.com...
> On 3 Aug 2003 19:02:14 -0700, james....@bindereng.com.au (James
> Cameron) wrote or quoted :
>
> > I suspect something like C would be the best based
> >on comments
>
> C is already disappearing. For longevity you want to pick something
> that is popular, and that is rising in popularity.
This is like the car dealership argument. Buy this *new* Explorer...it
shares a common platform with the Truck and should last a few good
years......Those 99 Camry's are old already - and who wants a...car?!
> Java is a pretty safe bet. Even if it dies the code is quite vanilla
> and should be easy to port to whatever replaces it.
Portability is a reasonable argument; however, I have yet to find anywhere
that is really interested in "porting" a product.
Once you get to the older systems the question comes down to (a) Do we have
time and money to port (b) Can we survive with what we have or (c) is there
a market product that has what we want.
In general the argument seems to go straight to (b) and (c). No one wants
to pay for an upgrade.
This isn't to say that I don't agree with your choice...I think I would go
with Java over C in general.
JCE
Jacob
> 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!
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.
Harley
"Jacob" <ja...@yahoo.com> wrote in message
news:3F2E721E...@yahoo.com...
| 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.
Jacob
> | NOTHING will run 10 years from now!
>
> You might want to qualify this by language.
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
> 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!
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_scacchiera(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_partenza_giusta;
int r,c;
int fine;
fine = 0;
casella_partenza_giusta = 0;
do
{
linee_bianche;
(void)printf(" DA? ");
read_2n(&r,&c);
if (posizione_in_scacchiera(r,c))
{
if (s[r][c] > 0)
leggi_posizione_arrivo(s,r,c,&casella_partenza_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_partenza_giusta || fine));
return fine;
}
static
leggi_posizione_arrivo(s,r,c,mossa_giusta)
scacchiera s;
int r,c;
int *mossa_giusta;
{
int r1,c1;
(void)printf(" A? ");
read_2n(&r1,&c1);
if (posizione_in_scacchiera(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_prese(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_prese(s,r,c)
scacchiera s;
int r,c;
{
int r1,c1;
do
{
(void)printf(" +A? ");
read_2n(&r1,&c1);
if (posizione_in_scacchiera(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_scacchiera(r1,c1));
}
static
stampa_scacchiera(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("DN"); 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("DB"); 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.b1);
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_solamente)
scacchiera s;
int r,c;
struct mossa *m;
int mangia_solamente;
{
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_scacchiera(r1,c1))
{
if ((s[r1][c1] == 0) && ! mangia_solamente)
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_scacchiera(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_scacchiera(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_vuota;
int cas_dietro_occupata;
int avversario_temibile;
if (posizione_in_scacchiera(r1-dr,c1-dc))
{
cas_davanti_vuota = (s[r1-dr][c1-dc]==0) ||
(r1-dr==r) && (c1-dc==c) ||
(r1-2*dr==r) && (c1-2*dc==c);
avversario_temibile = s[r1+dr][c1+dc] >= -s[r][c];
cas_dietro_occupata = 1;
if (abs(r1-r)==2 && posizione_in_scacchiera(r1+2*dr,c1+2*dc))
cas_dietro_occupata = s[r1+2*dr][c1+2*dc] != 0;
return cas_davanti_vuota && cas_dietro_occupata &&
avversario_temibile;
}
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("Dama (c) 1987 - Dario Dariol\n");
(void)printf("\n");
(void)printf("Il computer (nero) gioca contro l'avversario (bianco)\n");
(void)printf("adottando le regole della Dama italiana.\n");
(void)printf("L'unica eccezione e' che le prese NON sono obbligatorie\n");
(void)printf("\n");
(void)printf("Le mosse vengono comunicate scrivendo riga e colonna\n");
(void)printf("della casella da cui si muove o su cui si arriva.\n");
(void)printf("Uno 0 significa abbandono e/o mossa scorretta.\n");
(void)printf("\n");
}
main()
{
help();
inizializza(s);
while(1)
{
stampa_scacchiera(s);
if (leggi_mossa(s))
break;
if (elabora_mossa(s))
break;
}
}
Julián Albo
> E.g. see the following C programs that play Draughts
> (Dama in italian) written on september 1989:
(snip)
> help()
> {
> (void)printf("Dama (c) 1987 - Dario Dariol\n");
1989 or 1987?
Regards.
jce
> 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.
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
news:bglt5q$o06$1...@fata.cs.interbusiness.it...
> > NOTHING will run 10 years from now!
> after more than 10 years!
I like the previous post that said to use english :-) I don't think I can
follow this very easily.
JCE
jce
news:7qsXa.84038$3o3.5...@bgtnsc05-news.ops.worldnet.att.net...
>
> "Malcolm" <mal...@55bank.freeserve.co.uk> wrote in message
> news:bgktdu$n07$1...@news8.svr.pol.co.uk...
> |
> | "James Cameron" <james....@bindereng.com.au> wrote in message
> It has a history, and some code that surpasses the 15 year reusability
> requirement.
If this was a requirement 15 years ago then it surpassed that requirement.
I don't think this requirement is effective retroactively.
Question isn't what code has been reusable for 15 years....but what WILL be
reusable IN 15 years.
COBOL has had a resurgence recently - question is whether it will hold up
for 15 more years....Probably will....but you have to hope that the
compilers/$$$ keep up or you'll just have something that works and isn't
bleeding edge (what's wrong with that?).
JCE
Randy Howard
buz...@urubu.freeserve.co.uk says...
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.
jce
news:nDpXa.11704$SQ1....@news-binary.blueyonder.co.uk...
> 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
word
> 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
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
On 4-Aug-2003, "Harley" <dennis.ha...@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.
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
>> (void)printf("Dama (c) 1987 - Dario Dariol\n");
>
> 1989 or 1987?
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
"Howard Brazee" <how...@brazee.net> wrote in message
news:bgm1dq$p8o$1...@peabody.colorado.edu...
|
| On 4-Aug-2003, "Harley" <dennis.ha...@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
> 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.
Mathlab? The only one I can think of being around over 15 years :-)
pete kirkham
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
Howard <randy....@FOOmegapathdslBAR.net> writes
>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.
A with-it truly astute troll would have mentioned Rebol.
--
Alistair Maclean
Marco van de Voort
> Marco van de Voort wrote:
>
>> In article <45ab836a.03080...@posting.google.com>, 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.
>>
>>
>> Mathlab? The only one I can think of being around over 15 years :-)
>
> 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.
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
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).
Harley
"jce" <defau...@hotmail.com> wrote in message
news:urvXa.14996$K4.6...@twister.tampabay.rr.com...
| "Harley" <dennis.ha...@worldnet.att.net> wrote in message
| news:7qsXa.84038$3o3.5...@bgtnsc05-news.ops.worldnet.att.net...
| >
| > "Malcolm" <mal...@55bank.freeserve.co.uk> wrote in message
| > news:bgktdu$n07$1...@news8.svr.pol.co.uk...
| > |
| > | "James Cameron" <james....@bindereng.com.au> wrote in message
| > COBOL ain't dead yet.
| > It has a history, and some code that surpasses the 15 year reusability
| > requirement.
|
| If this was a requirement 15 years ago then it surpassed that requirement.
|
| I don't think this requirement is effective retroactively.
No, but there are languages that should have similary stories.
C++, and VB have been around for more than 5 years, so they have a history.
C has a longer history.
Isn't VB platform dependent?
| Question isn't what code has been reusable for 15 years....but what WILL
be
| reusable IN 15 years.
Any language that has a large customer base that would holler like hell if
it were abandoned, will be around for at least 15 years.
| COBOL has had a resurgence recently - question is whether it will hold up
| for 15 more years....Probably will....but you have to hope that the
| compilers/$$$ keep up or you'll just have something that works and isn't
| bleeding edge (what's wrong with that?).
|
Have you seen any evidence that the compilers have become stagnant?
Peter E.C. Dashwood
"Donald Tees" <Donal...@sympatico.ca> wrote in message
news:muqXa.898$_a4.1...@news20.bellglobal.com...
> "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
> news:3f2e2...@news.athenanews.com...
> >
> >
> >
> > code that will be re-used...)
> >
DO!!!
> >
> > functions as components, and you can reuse them FOR EVER not just 15
> years.
> >
> >
>
> Aren't you talking about marriage or something? About the *only* code I
> know that is still running after 15 years use is in Cobol. I could say
the
> same for 30 years.
>
There is no reason to believe that what has been true in the past will be
true in the future.
On the contrary, the indications are that the future which is emerging for
IT will be VERY DIFFERENT from the IT past...
> Even in the last five years, the components I have used have evolved into
> different packaging, required updates for each OS, etc. etc.
>
Then your definition of "component" differs from mine.
If components (whether ActiveX or Java Beans) are properly wrapped (and they
have to be, to BE ActiveX or Java Beans) there will be NO NEED to make any
change to them whatsoever when running under a new OS or in a new
environment.
If you needed to change the functionality, that is a design issue which has
nothing to do with the Language in use.
I have components running on the Web, under Windows, and (in one case) under
Linux. They have never required any changes from the day they were released.
I believe that qualifies as a good definition of "re-use".
Pete.
Kevin D. Quitt
<Donal...@sympatico.ca> wrote:
>Aren't you talking about marriage or something? About the *only* code I
>know that is still running after 15 years use is in Cobol. I could say the
>same for 30 years.
I have product out there that's 30+ years old and still running. All in
assembly. Perfectly portable.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
Kevin D. Quitt
Reuse on new hardware would require only a small program whose inputs and
outputs are clearly and completely prescribed.
Kevin D. Quitt
JerryMouse
>>
>> Aren't you talking about marriage or something? About the *only*
>> code I know that is still running after 15 years use is in Cobol. I
>> could say the same for 30 years.
>>
>
> There is no reason to believe that what has been true in the past
> will be true in the future.
Huh? Dogs won't bark in North Carolina? The speed of light becomes less? The
world DEPENDS on things remaining - mostly - the same.
>
> On the contrary, the indications are that the future which is
> emerging for IT will be VERY DIFFERENT from the IT past...
Huh?
>
> If components (whether ActiveX or Java Beans) are properly wrapped
> (and they have to be, to BE ActiveX or Java Beans) there will be NO
> NEED to make any change to them whatsoever when running under a new
> OS or in a new environment.
>
> If you needed to change the functionality, that is a design issue
> which has nothing to do with the Language in use.
>
> I have components running on the Web, under Windows, and (in one
> case) under Linux. They have never required any changes from the day
> they were released.
>
> I believe that qualifies as a good definition of "re-use".
Nah, a better definition is 'continued use.' You know, like it functioned in
the past, it functions now, and we have every reason it will continue to
function in the future.
Roedy Green
>Aren't you talking about marriage or something? About the *only* code I
>know that is still running after 15 years use is in Cobol. I could say the
>same for 30 years.
If the code is running unmodified in 20 years, most likely that code
is so obscure nobody knows how to change it, so it locks a business
rule into place, that really should be flexible.
In real life I have seen people emulating code for hardware that has
not existed for a decade mainly because they long ago lost the source
code.
Consider how many times that code will have to be read by maintenance
programmers, even if not changed, over that 20 years. You want to go
for something that is READABLE.
Java Gui code is not readable, but non-gui code is fairly good. It
should be considerably better with Java 1.5.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
jce
news:ue8uiv0oi4vtd50r8...@4ax.com...
> On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
> <Donal...@sympatico.ca> wrote or quoted :
>
> >Aren't you talking about marriage or something? About the *only* code I
> >know that is still running after 15 years use is in Cobol. I could say
the
> >same for 30 years.
>
> If the code is running unmodified in 20 years, most likely that code
> is so obscure nobody knows how to change it, so it locks a business
> rule into place, that really should be flexible.
Typically it is not the code that is obscure. Code in PL/I, COBOL etc etc
is generally easy to read.
What locks a business rule in place is the Parent of ALL business rules:
"Business rules cannot change, after all, they are business rules".
I've seen code 15 years old that is perfectly understandable - we just
cannot find anyone to explain the "why".
I've seen code 15 years old that is perfectly understandable and continues
to do what it was supposed to and no one actually has asked for it to be
changed (outside of additional auditing information that was added in early
90's and again in the 00's).
So, to summarize, the "why" is often more important than the "how".
Flexibility is important if (a) It really is needed and (b) It doesn't
become bigger than the problem. KIS.
> In real life I have seen people emulating code for hardware that has
> not existed for a decade mainly because they long ago lost the source
> code.
The problem here is that they don't know what the old source was doing and
nothing more. An old employee of ours actually managed to lose some 5 year
old source code once. We knew what it did and we rewrote it...comparative
tests showed all was well. No problem.
> Consider how many times that code will have to be read by maintenance
> programmers, even if not changed, over that 20 years. You want to go
> for something that is READABLE.
Absolutely. But we want to have the annotated cliff notes that give the
summary of what it is doing it for.
> Java Gui code is not readable, but non-gui code is fairly good. It
> should be considerably better with Java 1.5.
All the things I see are definite improvements for readability, the enhanced
for loop and autoboxing. I'm not sure on the metadata front because most of
that "boilerplate" code is generated anyhow - it's just more hidden.
All these things though are just details. Nothing substitutes a good design
and it will be just as easy to write crap 1.5 as it was to write crap 1.1.
It's kind of like literature. We can remove grammatical constructs, reduce
words and make things nice and simple like Harry Potter....but 100 years
from now people will still be figuring out Shakespeare and it's
quirks...whilst Harry Potter gets studied at "alternative" colleges....It's
the grand picture that makes something important with value that will last
:-)
JCE
Paul Hsieh
> 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.
Well, C will be around in 15 years in the same sense that COBOL is
still with us today. But probably something that should be pointed
out is that there are very few C compilers out there that don't also
support C++. There are very few if any universities teaching computer
science that teach C but not C++. So you could easily make a
strategic decision between C and C++ according to what makes sense for
you today, and certainly both will still exist in some way shape or
form 15 years from now.
That said, Java certainly has enough momentum today to suggest it will
probably exist in 15 years. Though whether or not it will supplant
C++ or other alternatives is too hard to see. The problem with Java
is that if it fails to continue to gain momentum, it might very
quickly be relegated to that of a niche market. I won't make a call
as to which way I think it will go, but I think its fair to say that
both (dominance over C++, or relegation to a niche) are possible. I
think its very unlikely that it will completely disappear in 15 years.
COBOL and Pascal (the other groups you crossposted this message to)
will decrease in usage over time, not increase. There is absolutely
no new serious development being done in either language. In 15
years, Pascal will probably be completely dead, and the COBOL
community will be reduced even from the size of today's community
(human mortality alone will guarantee this.)
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Richard Bos
> COBOL has had a resurgence recently - question is whether it will hold up
> for 15 more years....Probably will....but you have to hope that the
> compilers/$$$ keep up or you'll just have something that works and isn't
> bleeding edge (what's wrong with that?).
I don't know what's wrong with not being bleeding-edge (apart form Not
Being Cool In The Eyes Of The Press, to which I say: Pfffrrrrttt...),
but I can tell you exactly what's wrong with being bleeding-edge: the
blood tends to be yours.
Anybody remember 4GL? Prolog? Jav... oops <g>.
Richard
Richard Bos
Richard Bos
> 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!
Come and tell that to this program my colleagues in administration
use... it's been extended over the last 10 years, last time by me, but
its core code hasn't been changed. And that's because by and large, ten
years ago we sold ad space in newspapers; and today, we sell ad space in
newspapers. The way we _make_ those ads has been revolutionised in the
mean time. The way we calculate the price hasn't. Ten years ago, number
of millimeters by number of columns by tariff was the same calculation
as number of millimeters by number of columns as tariff is now,
surprisingly enough, and the original programmer was fore-seeing enough
to know that tariffs change.
Perhaps most amazing, this program was, and still is, written in...
Clipper. I have plans to change _that_, but it isn't a short-term
project, simply because it still does its job perfectly well.
Richard
Scott Condit
> If components (whether ActiveX or Java Beans) are properly wrapped (and they
> have to be, to BE ActiveX or Java Beans) there will be NO NEED to make any
> change to them whatsoever when running under a new OS or in a new
> environment.
Q: What OS environments do ActiveX controls run on?
A: Only Win32.
S
Bent C Dalager
Scott Condit <soc...@socode.com> wrote:
>
>Q: What OS environments do ActiveX controls run on?
>A: Only Win32.
A more interesting question is: will they run on Win64? And they
probably will.
Cheers
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Real Gagnon
COBOL = Considered Obsolete By Other Languages :^)
Bye.
--
Real Gagnon from Quebec, Canada
* Looking for Java or PB snippets ? Visit Real's How-to
* http://www.rgagnon.com/howto.html
Harley
| <Donal...@sympatico.ca> wrote or quoted :
|
| >Aren't you talking about marriage or something? About the *only* code I
| >know that is still running after 15 years use is in Cobol. I could say
the
| >same for 30 years.
|
| If the code is running unmodified in 20 years, most likely that code
| is so obscure nobody knows how to change it, so it locks a business
| rule into place, that really should be flexible.
There is no such thing as "so obscure nobody knows how to change it".
It may be a challenge to follow a process, but it's never impossible.
Running the process, and checking the output, gives you an idea of what is
going on in the module.
Even if the source code is long gone, the testing process can give you
enough information to construct a replacement.
You have two of the three: Input, Process, Output.
Original programs may go back 20 years or more, but for the most part
enhancements have been made. There may be programs that have run untouched
for 20 years, but they the exception, not the rule.
I think that program enhancement falls under the reuse umbrella.
| In real life I have seen people emulating code for hardware that has
| not existed for a decade mainly because they long ago lost the source
| code.
AND the process still satisfies a business need.
|
| Consider how many times that code will have to be read by maintenance
| programmers, even if not changed, over that 20 years. You want to go
| for something that is READABLE.
Agree.
|
| Java Gui code is not readable, but non-gui code is fairly good. It
| should be considerably better with Java 1.5.
I sometimes take monstrous code, copy it, and edit my copy to improve
readability, and get a handle on what's going on.
Reformatting the structure, and changing data names may help make the code a
bit more readable.
Since you're not modifying the actual source code, your changes don't have
to conform to language restrictions.
You can write unreadable code in any language.
Donald Tees
So what you are telling me is that if I take my GL system(written in Cobol),
and properly wrap it in an OCX wrapper, then suddenly all the code becomes
perfect, and it will not need maintenance ever again?
Perhaps we should all do that, and then trade OCX's. It would be a lot
easier than maintaining the stuff.
Donald
Donald Tees
> <Donal...@sympatico.ca> wrote or quoted :
>
> >Aren't you talking about marriage or something? About the *only* code I
> >know that is still running after 15 years use is in Cobol. I could say
the
> >same for 30 years.
>
> If the code is running unmodified in 20 years, most likely that code
> is so obscure nobody knows how to change it, so it locks a business
> rule into place, that really should be flexible.
>
That simply is not true. The general ledger rules have not changed an ioto.
What has changed is operating system interfaces, and most of those have been
cosmetic ... screen I/O and formating of reports. The rules of accounting
are identical, the account number scheme is identical, etc. etc. Being able
to re-use has a lot more to do with breaking the rules of bussness out from
the fluff than it does about technology.
Donald
Harley
"Paul Hsieh" <q...@pobox.com> wrote in message
news:796f488f.03080...@posting.google.com...
| james....@bindereng.com.au (James Cameron) wrote:
|
| COBOL and Pascal (the other groups you crossposted this message to)
| will decrease in usage over time, not increase. There is absolutely
| no new serious development being done in either language.
Sorry, but there is one place I know of that is rolling out a new industrial
strength application written in COBOL.
What is "serious development"?
JerryMouse
>
> That simply is not true. The general ledger rules have not changed
> an ioto. What has changed is operating system interfaces, and most of
> those have been cosmetic ... screen I/O and formating of reports.
> The rules of accounting are identical, the account number scheme is
> identical, etc. etc. Being able to re-use has a lot more to do with
> breaking the rules of bussness out from the fluff than it does about
> technology.
>
> Donald
>
Bless you! What I'm seeing on this thread is the premise: "Old code is bad
code." Then a search is undertaken to determine why it's bad!
That's a start with a false assumption. The 'business rules' of a general
ledger haven't changed since a mad monk invented them in the 1500's. The
basic rules of inventory control haven't changed since the start of an
agrarian society (you've got some, you take some away, you add some to the
pile).
As much as business leaders don't want a pig in a wig, they, in the main,
don't care about portability ten years down the road. And they properly
don't care for two overwhelming reasons: 1) The added expense right now, and
2) When the future gets here, everything will be cheaper anyway.
Marco van de Voort
> james....@bindereng.com.au (James Cameron) wrote:
>> 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.
>
> Well, C will be around in 15 years in the same sense that COBOL is
> still with us today. But probably something that should be pointed
> out is that there are very few C compilers out there that don't also
> support C++.
Sure, but that doesn't guarantee that will remain the case for 15 years
to come.
> There are very few if any universities teaching computer science that
> teach C but not C++.
Most actually don't. Mine teaches Java for general programming, and
C for embedded courses. No C++ at all.
> That said, Java certainly has enough momentum today to suggest it will
> probably exist in 15 years.
Yes, but my doubts with Java (and any languages mentioned here), isn't if it
exists, but if a common production compiler, 15 years from now can compile
code you make now. I doubt it, despite all idealistic portability cliche's
surrounding Java. (or C# or, or)
There only has to come some major new fashionable paradigm that promises
managers to shave off 1 percent of development cost, and the total direction
and focus of the programming community can change.
> COBOL and Pascal (the other groups you crossposted this message to)
> will decrease in usage over time, not increase. There is absolutely
> no new serious development being done in either language.
Which is nonsense. Delphi is still a big seller. I also think Pascal can
hold on to some niches like education and some scientific niches, the
same way Cobol did in banking and Fortran did in numerical analysis,
and C probably will in OS development and the smaller devices in the embedded
world.
> In 15 years, Pascal will probably be completely dead, and the COBOL
> community will be reduced even from the size of today's community (human
> mortality alone will guarantee this.)
Pascal has been declared dead several times, even Brian Kernigan tried to
marginalise it once. Yet Pascal still lives, while C/C++ is being replaced
by Java and C#.
Howard Brazee
On 4-Aug-2003, "Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote:
> There is no reason to believe that what has been true in the past will be
> true in the future.
>
> On the contrary, the indications are that the future which is emerging for
> IT will be VERY DIFFERENT from the IT past...
True enough. But one thing will likely remain the same - our ability to
predict how the future will be different.
Howard Brazee
On 5-Aug-2003, q...@pobox.com (Paul Hsieh) wrote:
> COBOL and Pascal (the other groups you crossposted this message to)
> will decrease in usage over time, not increase. There is absolutely
> no new serious development being done in either language.
Absolutely? I infer that the new development I see and do in CoBOL is all
jocular.
Harley
"Marco van de Voort" <mar...@toad.stack.nl> wrote in message
news:slrnbivdbd...@toad.stack.nl...
|
| There only has to come some major new fashionable paradigm that promises
| managers to shave off 1 percent of development cost, and the total
direction
| and focus of the programming community can change.
What I THINK will happen is that we will abandon coding altogether.
We will have system modeling tools that generate the program coding for us.
Once the model is developed, the system could be generated for a variety of
environments. You want a Windows version, no problem. You want a Unix
version, no problem. You want a mainframe version, no problem.
The only tricky thing will be the reverse engineering of existing systems
into the model.
I've seen this done, but the reverse engineered model didn't address the
system from a business perspective.
lvi...@yahoo.com
According to Roedy Green <ro...@mindprod.com>:
:On 3 Aug 2003 19:02:14 -0700, james....@bindereng.com.au (James
:Cameron) wrote or quoted :
:
:> I suspect something like C would be the best based
:>on comments
:
:C is already disappearing. For longevity you want to pick something
:that is popular, and that is rising in popularity.
Hmm - then what, operating systems are being rewritten in Java? And
the Java JVM's in Java?
It seems unlikely that C is going to disappear, until there's a suitable
low level language compilable into machine code that can be used as the
basis to write the other languages and operating system drivers, etc.
--
<URL: http://wiki.tcl.tk/ > <URL: http://www.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
lvi...@yahoo.com
According to Richard Bos <r...@hoekstra-uitgeverij.nl>:
:"jce" <defau...@hotmail.com> wrote:
:
:> COBOL has had a resurgence recently - question is whether it will hold up
:> for 15 more years....Probably will....but you have to hope that the
:> compilers/$$$ keep up or you'll just have something that works and isn't
:> bleeding edge (what's wrong with that?).
:
:I don't know what's wrong with not being bleeding-edge (apart form Not
:Being Cool In The Eyes Of The Press, to which I say: Pfffrrrrttt...),
Well, another thing is finding adequately trained staff, training materials,
etc.
Trying to find resources to get things done in the 'stable' languages
becomes harder (and more costly) as time goes on.
lvi...@yahoo.com
:The source language is irrelevant in terms of code re-use. (It is OBJECT
:code that will be re-used...)
:
:You should select a source language SUITABLE FOR THE JOB YOU WANT TO DO!!!
However, if the job being done is to develop a system which needs to continue
to be supported, and developed, for a long period of time, then the
language becomes at least a topic to be addressed.
One shouldn't _ignore_ the issue. One should consider it, build a business
case, then proceed.
If, for instance, one is deploying an application across a wide geographic
area, in a domain where applications need to run for long periods of time
with little down time, reliability issues, and little chance for replacements
(but possibilities for upgrades) etc., then one would hate to be saddled
with a language that in 5, 10, or 15 years few people will know. How many
developers can today develop, maintain, and debug in snobol, algol, rpg,
...
lvi...@yahoo.com
According to Thomas Gagné <tga...@wide-open-west.com>:
:That's an interesting criterion. How reusable will the code be 15 years from
:now? Why not consider what makes code from 15 years ago reusable?
That's a great question - what are some libraries which were written
15 years ago still in use?
First, what is the criteria we are going to use - the code was written
15 years (or more) ago and never touched? Written 15 years ago and
continues to be maintained for portability? Written 15 years ago and
has undergone rewrites over time?
There's probably code in the first category on frozen systems - systems
where the only things being written are new reports, etc. but no new
applications written.
I'm trying to think what open source projects might fall into this category
- what about pbmplus ? The official release was
http://www.acme.com/software/pbmplus/pbmplus_10dec1991.tar.gz
so that software is 12 years ago. I suspect that people still use that
distribution.
lvi...@yahoo.com
According to Donald Tees <Donal...@sympatico.ca>:
: About the *only* code I
:know that is still running after 15 years use is in Cobol.
15 years isn't that long guys (1988!) - where I work , I don't know if there
_is_ any cobol. But they have C, IBM assembler, PL/1, and code in
a variety of other languages that has been running that long.
Mark Gordon
"jce" <defau...@hotmail.com> wrote:
<snip>
> You don't say what the application is which makes the response hard.
> Some language are better for some things than others ;-)
Definitely. After all, one option to keep code reusable for 15 years is
to keep the HW and tools required to build & use it for 15 years.
<snip>
> 3. Does anyone really look to an application to last this long?
Yes. I know of SW written pre 1980 that was scheduled for further work
some time in 2000. This is code embedded in an avionics system which is
expected to be flying for another 15 years.
<snip>
> 4. The MOST important question is ........does it matter if I can
> reuse it in 5 years if I cannot get it out of the door quickly now? No
> point architecting a 15 year plan if it takes 5 years to execute and
> you need it in 3 months. I didn't get that priority from your
> original note.
>
> If you are on your own then I only have one comment:
> Narrow choices down to what you are comfortable with then add those
> languages you are confident of handling. You have to deliver the
> quality product NOW and not 15 years from now.
It might need to be delivered in 2 (or more) years time.
> Here's the kicker:
> Imagine......Sun goes belly up in 2006....Microsoft antes up with a
> few billion to buy the Java licensing rights....woo hooo.....We'll all
> try desperately to port to Inga's free open source virtual software
> layer Ingot that runs on EyeBeeEmux to remove Microsoft
> dependencies....(remember they once thought the earth was flat and
> that Senators were for the people). In 2015 we no longer run
> processors as we know them. Electrons have been isolated on switches
> that are built on self managed bio matter developed in the Democratic
> People's China by po'd shepherds who refuse to divulge their methods
> to the Communist States of America.
None of which is necessarily a problem. An acceptable solution might
involve keeping a stockpile of the HW to develop and run the
application. Of course, that might not be the case.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Mark Gordon
"Harley" <dennis.ha...@worldnet.att.net> wrote:
> "jce" <defau...@hotmail.com> wrote in message
> news:urvXa.14996$K4.6...@twister.tampabay.rr.com...
> | "Harley" <dennis.ha...@worldnet.att.net> wrote in message
> | news:7qsXa.84038$3o3.5...@bgtnsc05-news.ops.worldnet.att.net...
> | >
> | > "Malcolm" <mal...@55bank.freeserve.co.uk> wrote in message
> | > news:bgktdu$n07$1...@news8.svr.pol.co.uk...
> | > |
> | > | "James Cameron" <james....@bindereng.com.au> wrote in
> | > | message
> | > COBOL ain't dead yet.
> | > It has a history, and some code that surpasses the 15 year
> | > reusability requirement.
> |
> | If this was a requirement 15 years ago then it surpassed that
> | requirement.
> |
> | I don't think this requirement is effective retroactively.
>
> No, but there are languages that should have similary stories.
> C++, and VB have been around for more than 5 years, so they have a
> history. C has a longer history.
>
> Isn't VB platform dependent?
Yes it is, it also has a history of changing.
> | Question isn't what code has been reusable for 15 years....but what
> | WILL
> be
> | reusable IN 15 years.
>
> Any language that has a large customer base that would holler like
> hell if it were abandoned, will be around for at least 15 years.
So Z80 assembler will be around for another 15 year. Actually, I know of
one product which has 15 years of support already signed up where the
software is a mix of Z80 assembler, PLM and an obsolete Pascal variant.
> | COBOL has had a resurgence recently - question is whether it will
> | hold up for 15 more years....Probably will....but you have to hope
> | that the compilers/$$$ keep up or you'll just have something that
> | works and isn't bleeding edge (what's wrong with that?).
> |
>
> Have you seen any evidence that the compilers have become stagnant?
Yes, and I know of one VAX that continues to run VMS4.x so that people
can continue to use the tools. Some time in the next 15 years my old
employer may have to port the code, but they will have problems with
availability of various chips as well so the hardware may need
redesigning as well.
Alistair Maclean
<nos...@bisusa.com> writes
>Huh? Dogs won't bark in North Carolina? The speed of light becomes less? The
>world DEPENDS on things remaining - mostly - the same.
>
But the speed of light varies with the medium through which it travels.
--
Alistair Maclean
jce
news:20030805192555.6...@flash-gordon.me.uk...
> On Mon, 04 Aug 2003 14:28:23 GMT
> "jce" <defau...@hotmail.com> wrote:
> > 3. Does anyone really look to an application to last this long?
> Yes. I know of SW written pre 1980 that was scheduled for further work
> some time in 2000. This is code embedded in an avionics system which is
> expected to be flying for another 15 years.
<snip>
I guess it was a shortsighted question. I guess I missed an entire genre of
software development.
With communication links, nuclear reactors, and even Hubble it would be
ridiculous to assume that the application is "short" lived. I am sure there
are many areas primarily looking at safety or stability (the IRS for example
I am sure wants their multi million dollar rewrites to last through some
more tax cuts and tax hikes).
Your comment made me think about my car electronics system. I'm cheap and
hope it will still be running in a few more years !
I'm of the...'they've got coffee that's instantaneous....Good Technology'
generation :-)
<snip>
> None of which is necessarily a problem. An acceptable solution might
> involve keeping a stockpile of the HW to develop and run the
> application. Of course, that might not be the case.
<snip>
I guess that there are those companies reading 30 year old tapes for
customers so the hardware will always be there - but this also shows that
some people should have stockpiled their own hardware. Never seen a room
full of Apple 200 or 286's but it's certainly an angle that I hadn't thought
of. I guess at the end of the day there are many ways to skin a cat
including hardware solution.
Thanks for making me look at a slightly bigger picture.
JCE
John C. Bollinger
> According to Thomas Gagné <tga...@wide-open-west.com>:
> :That's an interesting criterion. How reusable will the code be 15 years from
> :now? Why not consider what makes code from 15 years ago reusable?
>
> That's a great question - what are some libraries which were written
> 15 years ago still in use?
BLAS. The earliest recorded literature reference to BLAS is from 1979,
which makes it 24 years old this year. Based on that single data point,
then, the criterion must be that the library is written in Fortran. :-)
> First, what is the criteria we are going to use - the code was written
> 15 years (or more) ago and never touched? Written 15 years ago and
> continues to be maintained for portability? Written 15 years ago and
> has undergone rewrites over time?
>
>
> There's probably code in the first category on frozen systems - systems
> where the only things being written are new reports, etc. but no new
> applications written.
I'm not sure whether that should count, because the question is about
reuse, not longtime continuing use. We could argue about exactly what
we mean by "reuse".
> I'm trying to think what open source projects might fall into this category
> - what about pbmplus ? The official release was
> http://www.acme.com/software/pbmplus/pbmplus_10dec1991.tar.gz
> so that software is 12 years ago. I suspect that people still use that
> distribution.
We have a software suite currently use in our lab whose original version
dates back to the late 1950s. That makes it about 45 years old,
although it has seen quite a bit of maintenance over the years and
probably not much of the original code remains. It is written in
Fortran. The version I first worked on was pretty much gobbledygook --
working gobbledygook, mind -- that had been, at that time, maintained
for over thirty years and gone through at least three ports to new
systems. The deciding factor there was not accessibility of the code in
any sense, nor any secret or arcane technology. It was just that the
software was at least as useful as any alternative, likely aided by the
fact that the field is sufficiently specialized that the were only a few
alternatives.
Perhaps that kind of story can't happen any more.
John Bollinger
jobo...@indiana.edu
Harley
<lvi...@yahoo.com> wrote in message news:bgonmn$s99$4...@srv38.cas.org...
|
| According to Richard Bos <r...@hoekstra-uitgeverij.nl>:
| :"jce" <defau...@hotmail.com> wrote:
| :
| :> COBOL has had a resurgence recently - question is whether it will hold
up
| :> for 15 more years....Probably will....but you have to hope that the
| :> compilers/$$$ keep up or you'll just have something that works and
isn't
| :> bleeding edge (what's wrong with that?).
| :
| :I don't know what's wrong with not being bleeding-edge (apart form Not
| :Being Cool In The Eyes Of The Press, to which I say: Pfffrrrrttt...),
|
| Well, another thing is finding adequately trained staff, training
materials,
| etc.
|
| Trying to find resources to get things done in the 'stable' languages
| becomes harder (and more costly) as time goes on.
| --
Some places train people to become COBOL programmers.
Even if some leave, they are still ahead because you need a few years
experience to move to another position.
Peter E.C. Dashwood
<lvi...@yahoo.com> wrote in message news:bgonug$s99$5...@srv38.cas.org...
>
> :The source language is irrelevant in terms of code re-use. (It is OBJECT
> :code that will be re-used...)
> :
> :You should select a source language SUITABLE FOR THE JOB YOU WANT TO
DO!!!
>
> However, if the job being done is to develop a system which needs to
continue
> to be supported, and developed, for a long period of time, then the
> language becomes at least a topic to be addressed.
>
Nope. Disagree strongly. The days of procedural code and the necessity to
maintain it are nearly over. It is very wrong NOW to design systems around a
particular language.
The days of the "Waterfall" and "One Language Wonder" system development
are, thankfully, in rapid decline.
Instead you should be concentrating on the functionality of your proposed
system and breaking it into object classes or modules. (Functional
decomposition, if you like...). Then the individual functions can be written
in whatever is best suited for them; you might even decide to buy some third
party components and throw those in the mix as well. "Maintenance" is NOT
about taking large integrated programs and changing them; it is about
replacing reusable components or extending the classes they are developed
from. This is a "building block" approach to system development. As such you
don't start "tailoring " the bricks. You simply replace them.
There is far too much involved in component based design and development to
go into here, but it DOES give the best chance of function reuse, and that
is what we're supposed to be talking about <G>.
For decades we used COBOL and PL/1 for commercial application development
and they were "the only game in town". That is no longer the case. There are
different (and better) ways to develop systems emerging. A component based
design can use components developed in whatever language is most suitable
for that particular function.
>
> One shouldn't _ignore_ the issue. One should consider it, build a busines
s
> case, then proceed.
>
> If, for instance, one is deploying an application across a wide geographic
> area, in a domain where applications need to run for long periods of time
> with little down time, reliability issues, and little chance for
replacements
> (but possibilities for upgrades) etc., then one would hate to be saddled
> with a language that in 5, 10, or 15 years few people will know. How many
> developers can today develop, maintain, and debug in snobol, algol, rpg,
> ...
>
(Algol and RPG are far from dead...but that's another story...<G>)
You're right, but your argument is predicated on continuing to develop
systems the way we have done, traditionally. I contest that, on the basis of
what is emerging in the Market Place (better and quicker "build tools"), new
technologies in programming aimed specifically at re-use of code (OOP),
higher levels of user computer literacy (expecting more, and capable of
building their own information systems with standard tools like spreadsheets
and databases - all they need from IT is the benefit of exerience and some
guidance and support. That's another reason why decomposed modular design is
better; it can more easily incorporate user developed solutions and provide
components that use standard algorithms for placing on Web Pages and the
desktop.)
You might like to see some of the background to my position at:
http://www.aboutlegacycoding.com/archives/v3/v30201.asp
Pete.
Roedy Green
>That's a great question - what are some libraries which were written
>15 years ago still in use?
Some code like a math library the handle matrices need not change. It
has no user interface. The more a piece of software interacts with the
user and the OS, the more tweaking it will need just to keep it alive.
The more self-contained a piece of code is the safer it is. Otherwise
it has to change to match changes in any pieces it depends on. If one
of those pieces fails, a substitute must be found or created.
Peter E.C. Dashwood
> Snipped much of post.
>
> "Marco van de Voort" <mar...@toad.stack.nl> wrote in message
> news:slrnbivdbd...@toad.stack.nl...
> |
> | There only has to come some major new fashionable paradigm that promises
> | managers to shave off 1 percent of development cost, and the total
> direction
> | and focus of the programming community can change.
This is a very astute and accurate observation. However, I tend to agree
with Dennis' position below, that the whole business of coding will become
automated, and SOURCE code re-use is therefore irrelevant.
>
> What I THINK will happen is that we will abandon coding altogether.
> We will have system modeling tools that generate the program coding for
us.
> Once the model is developed, the system could be generated for a variety
of
> environments. You want a Windows version, no problem. You want a Unix
> version, no problem. You want a mainframe version, no problem.
>
Yes, I agree strongly with this. I believe that by INTERACTION and ITERATION
with a Workshop of Users and IT people, the system will write itself. We can
ALMOST do this today, and I have managed projects where all the
functionality was derived from Joint Development Workshops, code was cut,
then the process iterated. It is a logical progression to have the code
generated instantly by a smart system. The best thing about this approach is
not the technology, but the fact that the Users get exactly what they
need/want right NOW, not what they needed/wanted six months ago when the
"Requirements Gathering" phase was signed off...
The whole debate about "future re-use of code", insofar as it applies to
SOURCE code, is irrelevant.
Pete.
James J. Gavan
"Peter E.C. Dashwood" wrote:
> Nope. Disagree strongly. The days of procedural code and the necessity to
> maintain it are nearly over. It is very wrong NOW to design systems around a
> particular language.
>
> The days of the "Waterfall" and "One Language Wonder" system development
> are, thankfully, in rapid decline.
Now don't shilly shally - your new 'audience' might find it enlightening.
"Design systems around a particular language" and "One Language Wonder".
Spell it out simply as percentages :-
- Languages you use on a daily basis - x%
- Languages & Tools you use to produce your Components on a daily basis - x%
Jimmy
Roedy Green
<Donal...@sympatico.ca> wrote or quoted :
>That simply is not true. The general ledger rules have not changed an ioto.
>What has changed is operating system interfaces, and most of those have been
>cosmetic ... screen I/O and formating of reports. The rules of accounting
>are identical, the account number scheme is identical, etc. etc. Being able
>to re-use has a lot more to do with breaking the rules of bussness out from
>the fluff than it does about technology.
When I lived on Quadra Island the guy down the road made a living
writing custom Accpac modifications. This was done in a sort of
assembler for a very DOS-like model. There is a ton of this stuff
running Canadian businesses. Very few people understand it anymore.
Companies have paid high amounts to have these mods done, and they are
not portable. The whole scheme is frozen circa 1985.
Roedy Green
wrote or quoted :
>
>That's a start with a false assumption. The 'business rules' of a general
>ledger haven't changed since a mad monk invented them in the 1500's. The
>basic rules of inventory control haven't changed since the start of an
>agrarian society (you've got some, you take some away, you add some to the
>pile).
I am using code for NEW applications I wrote back in 1979, so I have
no compunctions about using code just because it is old. What you want
though is for the code to be understandable and changeable IF YOU
WANTED TO. You should not be using code just because nobody knows how
to change it.
In the simplest case, somebody asks that a program collect some
information, then gradually you find the game is not worth the candle.
So you might as well remove that code, rather than forcing people to
make up data to keep the program happy.
Roedy Green
Bos) wrote or quoted :
>Perhaps most amazing, this program was, and still is, written in...
>Clipper.
This suggests another general principle. If you are interested in
longevity, write in a language supported by as many vendors as
possible. We have seen the demise of dBase, as the ball was passed and
fumbled with the decline of Ashton Tate.
Wirth might suggest always using a language simple enough that you
could fund your own compiler if necessary.
Roedy Green
<dennis.ha...@worldnet.att.net> wrote or quoted :
>What I THINK will happen is that we will abandon coding altogether.
>We will have system modeling tools that generate the program coding for us.
At some point you are going to have to interact with the robot
programmer by giving examples of the input and output, with iteration
till it gets the general pattern you had in mind. This will probably
generate better code than you would by hand, because it will force you
to think about the pathological conditions as well.
Ordinary users are extremely good at telling you what they want AFTER
you have given them something approximating what they want. It is
like pulling teeth beforehand. We may find that ordinary users can
interact with robots quite well, especially in some canned universe,
such as accounting programs, or name/address/minifact databases.
Think how you might do this with Regexes. You give it sample patterns
you want it to match, and ones you want it not to match, and you keep
iterating till it gives the results you want. Clever folk can then
look at the REGEX, and fine tune it with a few more examples, rather
than by directly coding it.
The other thing is I think we are going to have to be less
perfectionistic. People want to control every last pixel on the
screen. This is a waste of valuable time and largely an exercise in
egotism. Instead, robot programmers should do layouts given only the
field names. You could handle much of it for example by coding an
international name, address and phone number class and for all in a
class library rather than hand coding it for every app. Just use it.
Stop being so picky about imposing your own personal preferences.
We should once and for all create class libraries to validate all the
common business objects like phone numbers, websites, email addresses,
zip codes, states, provinces, money. These should autoupdate with web
updates as needed.
Joona I Palaste
on comp.lang.c:
> John D. wrote:
>> james....@bindereng.com.au (James Cameron) wrote in message news:<45ab836a.03080...@posting.google.com>...
>>>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.
>>
>> Whatever programming language you chose always remember to document
>> your code.
> Hey, be careful! Not everyone's an anglophone. Other than that,
> very well said.
I, for one, learned BASIC before I learned English. I remember being
pleased that "if... then" meant the same thing as English as it did in
BASIC.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"As we all know, the hardware for the PC is great, but the software sucks."
- Petro Tyschtschenko
Joona I Palaste
on comp.lang.c:
> James Cameron wrote:
> ^^^^^^^^^^^^^
> You're a great filmmaker - why are you switching to programming? :)
Is this the same James Cameron who created the pptpclient SourceForge
project?
Richard Bos
>
> According to Richard Bos <r...@hoekstra-uitgeverij.nl>:
> :"jce" <defau...@hotmail.com> wrote:
> :
> :> COBOL has had a resurgence recently - question is whether it will hold up
> :> for 15 more years....Probably will....but you have to hope that the
> :> compilers/$$$ keep up or you'll just have something that works and isn't
> :> bleeding edge (what's wrong with that?).
> :
> :I don't know what's wrong with not being bleeding-edge (apart form Not
> :Being Cool In The Eyes Of The Press, to which I say: Pfffrrrrttt...),
>
> Well, another thing is finding adequately trained staff, training materials,
> etc.
Yes, that's another good point against being bleeding edge. You cannot
possibly have _adequately_ trained staff for a language that's less than
five years old, unless your definition of adequate is "just about good
enough to battle through the project", rather than, as it should be,
"quite good enough to get things done the right way".
> Trying to find resources to get things done in the 'stable' languages
> becomes harder (and more costly) as time goes on.
Snigger.
Richard
Richard Bos
> On Tue, 05 Aug 2003 06:12:10 GMT, r...@hoekstra-uitgeverij.nl (Richard
> Bos) wrote or quoted :
>
> >Perhaps most amazing, this program was, and still is, written in...
> >Clipper.
>
> This suggests another general principle. If you are interested in
> longevity, write in a language supported by as many vendors as
> possible. We have seen the demise of dBase, as the ball was passed and
> fumbled with the decline of Ashton Tate.
Yes. And yet, people are not only using, but writing XBase applications
on a daily basis...
> Wirth might suggest always using a language simple enough that you
> could fund your own compiler if necessary.
...and an open source project to create a free Clipper clone is well
under way - enough, in fact, that IIRC it's already being used to create
serious programs.
Richard
Jim Morcombe
How much time will be spect maintaining the code?
If the code willbe stable and not maintained too often, then development
time will be more important than maintenance time.
However, if it will be maintained quite frequently and you don't mind a
longer development time, just go with "C" or Cobol, depending on the type of
application.
If development cost is critical, then just choose any development language
that is not undergoing a lot of chnge at the moment. Probably one that you
have skills to use already.
Jim
James Cameron <james....@bindereng.com.au> wrote in message
news:45ab836a.03080...@posting.google.com...
> 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.
>
> Thanks for the help in advance
>
> James Cameron
Peter E.C. Dashwood
"James J. Gavan" <jjg...@shaw.ca> wrote in message
news:3F30533D...@shaw.ca...
Sorry Jimmy,
I'd like to respond but I have no idea what you are talking about.
Percentages based on what I do personally are of no consequence. Percentages
based on the last commercial installation I managed are of little
consequence either. Today's percentages could vary wildly tomorrow, and
there is no guarantee that a percentage of development true today will
continue to be true indefinitely.
I can say that the results from both above would involve SQL Server, VB,
Perl, Java and COBOL. But so what?
I don't see any "shilly-shally" in my post.
My point was that it is wrong (today) to design systems around the
capabilities of a given procedural language (irrespective of what that
language is...). As for "One Language wonder"... well, that is just an
extension of the same idea. In the past it was possible to get by on one
language. It isn't anymore, yet there are still people who, rather than
simply expand their skill set, cling frantically to the notion that THEIR
language is wonderful and can do ANYTHING better than any other language.
(hence, "One Language Wonder"...)
We SHOULD be designing systems based on Business Functionality, rather than
computer programming languages.
I contend that Component Based Development is a really good way to do this,
and it happens to be the best way to ensure re-use of code (in my opinion)
which is what the topic is about.
Maybe you read more into it than I intended or maybe I just don't understand
what you are driving at.
Pete.
LX-i
> LX-i <LXi...@netscape.net> scribbled the following
> on comp.lang.c:
>
>>James Cameron wrote:
>>^^^^^^^^^^^^^
>>You're a great filmmaker - why are you switching to programming? :)
>
>
> Is this the same James Cameron who created the pptpclient SourceForge
> project?
I have no idea. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ AIM: LXi0007 ~
~ _____ / \ | ~ E-mail: LXi...@Netscape.net ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please post if you wish to be contacted privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Brazee
On 6-Aug-2003, Joona I Palaste <pal...@cc.helsinki.fi> wrote:
> I, for one, learned BASIC before I learned English. I remember being
> pleased that "if... then" meant the same thing as English as it did in
> BASIC.
I'm glad you shared that. I have wondered how often this is true.
I have heard of pilots who know how to speak all the English that they need to
talk to Air Traffic Controllers and other aspects of their job (every
international airport except for Montreal's speaks English) - but don't know
English hardly at all for non-business purposes.
Harley
Pete,
I read about the concept quite some time ago.
Sent me down to the basement to find the book.
"System Design from Provably Correct Constructs"
By James Martin, copyright 1985.
ISBN: 0-13-88143-X.
You might try a Google search for "Higher-Order Software".
In any event, such a modeling system may, or may not use OO concepts, as the
underlying structure may be hidden by the modeling tool.
(The decision will be made by the tool builders.)
A natural language based Metadata repository is probably a requirement,
especially since you would want to express the system in business terms, and
a well structured repository is probably a good base for expert system type
processing.
i.e (Delinquent Account contains Last payment past due, Last payment under
minimum due, Last 2 Payments past due, Last 3 payments past due, etc.)
The user may ask for Delinquent Accounts, and the expert system would ask:
"Which of these conditions are you requesting?".
We may not be as far away from this type of "programming" as we think.
THAT'S ALL FOLKS!!
"Peter E.C. Dashwood" <dash...@enternet.co.nz> wrote in message
news:3f304...@news.athenanews.com...
Aleksi Kallio
>>pleased that "if... then" meant the same thing as English as it did in
>>BASIC.
> I'm glad you shared that. I have wondered how often this is true.
Sounds familiar. When we started to learn English at school we had
competitions where you had to come up with word that begins with the
letter that the previous word ended with. My team won always because I
knew so many BASIC commands and C64 related terms - but I had no idea
what was the meaning of those words outside the context of C64. :)
Bob Wolfe
>james....@bindereng.com.au (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.
>
>Well, C will be around in 15 years in the same sense that COBOL is
>still with us today. But probably something that should be pointed
>out is that there are very few C compilers out there that don't also
>support C++. There are very few if any universities teaching computer
>science that teach C but not C++. So you could easily make a
>strategic decision between C and C++ according to what makes sense for
>you today, and certainly both will still exist in some way shape or
>form 15 years from now.
>
>That said, Java certainly has enough momentum today to suggest it will
>probably exist in 15 years. Though whether or not it will supplant
>C++ or other alternatives is too hard to see. The problem with Java
>is that if it fails to continue to gain momentum, it might very
>quickly be relegated to that of a niche market. I won't make a call
>as to which way I think it will go, but I think its fair to say that
>both (dominance over C++, or relegation to a niche) are possible. I
>think its very unlikely that it will completely disappear in 15 years.
>
>COBOL and Pascal (the other groups you crossposted this message to)
>will decrease in usage over time, not increase. There is absolutely
>no new serious development being done in either language.
Paul:
I'm curious......can you provide me with a reference to the source of
the above comment?
Did you read that in a magazine article or was it a reference from a
Gartner Group study?
I am indeed curious.
> In 15
>years, Pascal will probably be completely dead, and the COBOL
>community will be reduced even from the size of today's community
>(human mortality alone will guarantee this.)
Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com
Danny Maijer
"James Cameron" <james....@bindereng.com.au> schreef in bericht
news:45ab836a.03080...@posting.google.com...
> 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.
How about even 20 years down the road ? One of my former colleagues had a
crush on date handling. Up to now I am still using his code (with no changes
made ever since) in new applications and when maintaining other apps. His
coding even supports the gregorian date change in 1560......I never needed
that however.
That code was written for a NCR IMOS system. In plain ANSII cobol. As you
will read in the other replies on this thread there are some standards such
piece of code needs to meet. Like no user interface (only parameter
handling) and plain standard coding (no proprietry routines should be used).
I have put lots of this kind of routines in Fujitsu Cobol DLL's which makes
them accessable for other languages too....To be frankly honest, I never
looked at the source code of these routines. I dont need to, they work !
(Thanks to Robert Veldwijk).
Regards, Danny.
BTW, When I started programming in COBOL I was warned to upgrade my skills
to other languages (which I did) because COBOL would be dead and gone within
5 years of that moment. That was 1984......The main part of my business is
still COBOL today :)
Wolfgang Riedel
>
> "James J. Gavan" <jjg...@shaw.ca> wrote in message
> news:3F30533D...@shaw.ca...
<snip>
> We SHOULD be designing systems based on Business Functionality, rather than
> computer programming languages.
not all programming is Business
>
> I contend that Component Based Development is a really good way to do this,
> and it happens to be the best way to ensure re-use of code (in my opinion)
> which is what the topic is about.
<snip>
> Pete.
You're aware, this is there some 10 (?) years?
Remember SOM, OpenDoc, OS400 to just cite IBM?
Most were language-independent.
All but one gone.
Make it better next time?
Sure!
XML!
(hah!)
Wolfgang
docd...@panix.com
Danny Maijer <in...@liveartists.com> wrote:
[snip]
>BTW, When I started programming in COBOL I was warned to upgrade my skills
>to other languages (which I did) because COBOL would be dead and gone within
>5 years of that moment. That was 1984......The main part of my business is
>still COBOL today :)
Oh, I *cannot* resist... I don't remember where I first read it or to whom
I should attribute it but the statement was something along the lines of
'I was told to learn new stuff because COBOL was a dying language and
would soon be replaced. The next week I was told that Neil Armstrong had
walked on the moon.'
DD
Danny Maijer
<docd...@panix.com> schreef in bericht
news:bgrjdu$e7o$1...@panix1.panix.com...
> Oh, I *cannot* resist... I don't remember where I first read it or to whom
> I should attribute it but the statement was something along the lines of
> 'I was told to learn new stuff because COBOL was a dying language and
> would soon be replaced. The next week I was told that Neil Armstrong had
> walked on the moon.'
>
> DD
>
Heh :)
Soon after that NASA migrated to Fortran.......After Apollo 13 they reverted
to COBOL.....
Peter E.C. Dashwood
"Wolfgang Riedel" <wolfgan...@development.retarus.de> wrote in message
news:3F313DDE...@development.retarus.de...