Future reuse of code

[Harley]

Re: Future reuse of code


"jce" <defaultuser@ho tmail.com> wrote in message
news:urvXa.1499 6$K4.689405@twi ster.tampabay.r r.com...
| "Harley" <dennis.harleyN oSpam@worldnet. att.net> wrote in message
| news:7qsXa.8403 8$3o3.5810177@b gtnsc05-news.ops.worldn et.att.net...
| >
| > "Malcolm" <malcolm@55bank .freeserve.co.u k> wrote in message
| > news:bgktdu$n07 $1@news8.svr.po l.co.uk...
| > |
| > | "James Cameron" <james.cameron@ bindereng.com.a u> 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....Probab ly 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]

Re: Future reuse of code


"Donald Tees" <Donald_Tees@sy mpatico.ca> wrote in message
news:muqXa.898$ _a4.182679@news 20.bellglobal.c om...[color=blue]
> "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
> news:3f2e2ad3_6 @news.athenanew s.com...[color=green]
> >
> >
> >
> > 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[/color][/color]
DO!!![color=blue][color=green]
> >
> > 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[/color]
> years.[color=green]
> >
> > Pete.
> >[/color]
>
> 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[/color]
the[color=blue]
> same for 30 years.
>[/color]

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...
[color=blue]
> Even in the last five years, the components I have used have evolved into
> different packaging, required updates for each OS, etc. etc.
>[/color]
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]

Re: Future reuse of code

On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
<Donald_Tees@sy mpatico.ca> wrote:
[color=blue]
>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.[/color]

I have product out there that's 30+ years old and still running. All in
assembly. Perfectly portable.


--
#include <standard.discl aimer>
_
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]

Re: Future reuse of code

Clearly the language of choice is MIX. Completely documented and free.
Reuse on new hardware would require only a small program whose inputs and
outputs are clearly and completely prescribed.


--
#include <standard.discl aimer>
_
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]

Re: Future reuse of code

And don't forget - a Real Programmer can write FORTRAN in any language.


--
#include <standard.discl aimer>
_
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

[JerryMouse]

Re: Future reuse of code

Peter E.C. Dashwood wrote:[color=blue][color=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.
>>[/color]
>
> There is no reason to believe that what has been true in the past
> will be true in the future.[/color]

Huh? Dogs won't bark in North Carolina? The speed of light becomes less? The
world DEPENDS on things remaining - mostly - the same.
[color=blue]
>
> On the contrary, the indications are that the future which is
> emerging for IT will be VERY DIFFERENT from the IT past...[/color]

Huh?
[color=blue]
>
> 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".[/color]

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]

Re: Future reuse of code

On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
<Donald_Tees@sy mpatico.ca> wrote or quoted :
[color=blue]
>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.[/color]

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]

Re: Future reuse of code

"Roedy Green" <roedy@mindprod .com> wrote in message
news:ue8uiv0oi4 vtd50r8of50rr2k ccf4tvncm@4ax.c om...[color=blue]
> On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
> <Donald_Tees@sy mpatico.ca> wrote or quoted :
>[color=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[/color][/color]
the[color=blue][color=green]
> >same for 30 years.[/color]
>
> 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.[/color]

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.
[color=blue]
> 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.[/color]
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...comparativ e
tests showed all was well. No problem.
[color=blue]
> 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.[/color]
Absolutely. But we want to have the annotated cliff notes that give the
summary of what it is doing it for.
[color=blue]
> Java Gui code is not readable, but non-gui code is fairly good. It
> should be considerably better with Java 1.5.[/color]
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 "boilerplat e" 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 "alternativ e" colleges....It' s
the grand picture that makes something important with value that will last
:-)

JCE

[Paul Hsieh]

Re: Future reuse of code

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

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]

Re: Future reuse of code

"jce" <defaultuser@ho tmail.com> wrote:
[color=blue]
> COBOL has had a resurgence recently - question is whether it will hold up
> for 15 more years....Probab ly 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?).[/color]

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

[Scott Condit]

Re: Future reuse of code

Peter E.C. Dashwood wrote:
[color=blue]
> 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.[/color]

Q: What OS environments do ActiveX controls run on?
A: Only Win32.

S

[Bent C Dalager]

Re: Future reuse of code

In article <bgnqh5$q8mem$1 @ID-189137.news.uni-berlin.de>,
Scott Condit <socode@socode. com> wrote:[color=blue]
>
>Q: What OS environments do ActiveX controls run on?
>A: Only Win32.[/color]

A more interesting question is: will they run on Win64? And they
probably will.

Cheers
Bent D
--
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
powered by emacs

[Harley]

Re: Future reuse of code


"Roedy Green" <roedy@mindprod .com> wrote in message
news:ue8uiv0oi4 vtd50r8of50rr2k ccf4tvncm@4ax.c om...
| On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
| <Donald_Tees@sy mpatico.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]

Re: Future reuse of code

"Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
news:3f2ee837_9 @news.athenanew s.com...[color=blue]
>
> "Donald Tees" <Donald_Tees@sy mpatico.ca> wrote in message
> news:muqXa.898$ _a4.182679@news 20.bellglobal.c om...[color=green]
> > "Peter E.C. Dashwood" <dashwood@enter net.co.nz> wrote in message
> > news:3f2e2ad3_6 @news.athenanew s.com...[color=darkred]
> > >
> > >
> > >
> > > The source language is irrelevant in terms of code re-use. (It is[/color][/color][/color]
OBJECT[color=blue][color=green][color=darkred]
> > > code that will be re-used...)
> > >
> > > You should select a source language SUITABLE FOR THE JOB YOU WANT TO[/color][/color]
> DO!!![color=green][color=darkred]
> > >
> > > 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[/color]
> > years.[color=darkred]
> > >
> > > Pete.
> > >[/color]
> >
> > 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[/color]
> the[color=green]
> > same for 30 years.
> >[/color]
>
> 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...
>[color=green]
> > Even in the last five years, the components I have used have evolved[/color][/color]
into[color=blue][color=green]
> > different packaging, required updates for each OS, etc. etc.
> >[/color]
> Then your definition of "component" differs from mine.
>
> If components (whether ActiveX or Java Beans) are properly wrapped (and[/color]
they[color=blue]
> 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[/color]
has[color=blue]
> nothing to do with the Language in use.
>
> I have components running on the Web, under Windows, and (in one case)[/color]
under[color=blue]
> Linux. They have never required any changes from the day they were[/color]
released.[color=blue]
>
> I believe that qualifies as a good definition of "re-use".
>
> Pete.
>
>[/color]

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]

Re: Future reuse of code

"Roedy Green" <roedy@mindprod .com> wrote in message
news:ue8uiv0oi4 vtd50r8of50rr2k ccf4tvncm@4ax.c om...[color=blue]
> On Mon, 4 Aug 2003 06:21:28 -0400, "Donald Tees"
> <Donald_Tees@sy mpatico.ca> wrote or quoted :
>[color=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[/color][/color]
the[color=blue][color=green]
> >same for 30 years.[/color]
>
> 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.
>[/color]

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


[color=blue]
> 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.[/color]