The Life Cycle of Technology and COBOL

Ray Kurzweil in his book "The Age of Spiritual Machines":  pages 19-20
discusses the life cycle of a technology:

Technologies fight for survival, evolve, and ungergo their own
characteristic cycle.

1. Precusor stage: prerequistes of a technology exist, dreamers may
contemplate these elements coming together.

2. Invention: inventor blends curiosity, scientific skills, determination
and showmanship to combine methods in new way to bring new technology to
life.  This stage is usually very brief.

3. Development: the invention is protected and supported by its guardians.
Often this stage is more crucial than invention.

4. Maturity: although continuing to evolve, the technology now has a life of
its own, has become independent and established. It may become so interwoven
in the fabric of life that it may appear that it will last forever. This
creates an interesting drama when the next stage appears, the stage of the
pretenders.

5. Pretenders: Here an upstart threatens to eclipse the older technology.
Enthusiasts predict victory. While providing distinct benefits it is found
upon reflection to be missing some key element of functionality or quality.
When it fails to dislodge the established order the technology conservatives
take this as evidence that the original approach will indeed live forever.
This usually a short lived victory. Shortly there another new technology
that does suceed in rendering the original technology into the stage of
obsolescence.

6. Obsolescence: the technology lives out its senior years in a gradual
decline.  This stage may comprise 5 to 10 percent of the life cycle, finally
yields to antiquity.

7. Antiquity

Example: Phonograph record.

Mid 19th century there were several precursors including the phonautograph.
In 1877 Thomas Edison brought all the elements together. Further refinements
were necessary for the phonograph to become commercially viable.  It became
fully mature in 1948 when Columbia introduced the 33 rpm long play record.
The pretender was the cassette tape introduced in the 1960's and popularized
in the 1970's. But cassettes lack random access. In the late 1980's and
early 1990's the digitial compact disc(CD) did deliver the mortal blow.
Although still produced in samll quatities the phonograph is now approaching
antiquity.

It seems clear to me that COBOL is in stage 6, obsolescence. It is living
out it years in gradual decline. Not even its guardians are supporting it.
The lack of any implementation of the latest standard is evidence of
this.The rest of the world has voted and they are pursuing object oriented
technologies.

"Charles Hottel" <chottel@earthlink.net> wrote in message
news:cAsUh.21643$PL.10535@newsread4.news.pas.earthlink.net...
> Ray Kurzweil in his book "The Age of Spiritual Machines":  pages 19-20
> discusses the life cycle of a technology:
>
> Technologies fight for survival, evolve, and ungergo their own
> characteristic cycle.
>
> 1. Precusor stage: prerequistes of a technology exist, dreamers may
> contemplate these elements coming together.
>
> 2. Invention: inventor blends curiosity, scientific skills, determination
> and showmanship to combine methods in new way to bring new technology to
> life.  This stage is usually very brief.
>
> 3. Development: the invention is protected and supported by its guardians.
> Often this stage is more crucial than invention.
>
> 4. Maturity: although continuing to evolve, the technology now has a life
> of its own, has become independent and established. It may become so
> interwoven in the fabric of life that it may appear that it will last
> forever. This creates an interesting drama when the next stage appears,
> the stage of the pretenders.
>
> 5. Pretenders: Here an upstart threatens to eclipse the older technology.
> Enthusiasts predict victory. While providing distinct benefits it is found
> upon reflection to be missing some key element of functionality or
> quality. When it fails to dislodge the established order the technology
> conservatives take this as evidence that the original approach will indeed
> live forever. This usually a short lived victory. Shortly there another
> new technology that does suceed in rendering the original technology into
> the stage of obsolescence.
>
> 6. Obsolescence: the technology lives out its senior years in a gradual
> decline.  This stage may comprise 5 to 10 percent of the life cycle,
> finally yields to antiquity.
>
> 7. Antiquity
>
> Example: Phonograph record.
>
> Mid 19th century there were several precursors including the
> phonautograph. In 1877 Thomas Edison brought all the elements together.
> Further refinements were necessary for the phonograph to become
> commercially viable.  It became fully mature in 1948 when Columbia
> introduced the 33 rpm long play record. The pretender was the cassette
> tape introduced in the 1960's and popularized in the 1970's. But cassettes
> lack random access. In the late 1980's and early 1990's the digitial
> compact disc(CD) did deliver the mortal blow. Although still produced in
> samll quatities the phonograph is now approaching antiquity.
>
> It seems clear to me that COBOL is in stage 6, obsolescence. It is living
> out it years in gradual decline. Not even its guardians are supporting it.
> The lack of any implementation of the latest standard is evidence of
> this.The rest of the world has voted and they are pursuing object oriented
> technologies.
>
Hmmm... I think there is a very wrong implication in your last three
sentences, Charles. (Rest of the post was interesting and seems fairly
reasonable.)

The "rest of the world" has not moved to OO technologies because they
perceived a lack of support for COBOL  or because no-one implemented the
latest standard.

OO is not an alternative to COBOL; it is a DIFFERENT paradigm. If COBOL
never existed, a strong case can still be made that the World would move to
OO technology; if COBOL HAD everything in the last standard, the World woud
still move to OO technologies, and would probably not use COBOL.

The reasons for the decline of COBOL are nowhere near as simple as it not
being implemented or supported by its "guardians", although that certaily
didn't help.

As normally happens with the evolution of species, it is being superseded by
strains that are much better suited to the modern environment. Despite it
trying to adapt, it has innate clumsiness that simply has no place in
today's environment. And when it did try to adapt and implement OO
programming facilities, the community who should have supported and embraced
it just didn't. (Interestingly, that same community is now being forced more
and more towards Java (a pure OO Language), when it could have been COBOL if
they had made enough noise and shown willing...). There's nothing wrong with
Java, but it is ironic that people who resisted it fiercely as "non-COBOL"
are now being forced to embrace it.

I see it as being a bit like the end of the Neanderthals... the new Homo
Sapiens are quicker and smarter and long term there isn't much hope for the
poor old species.

It really dens me, but I am enjoying C#... :-)

Pete.

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:58frsfF2ecehjU1@mid.individual.net...
>
> "Charles Hottel" <chottel@earthlink.net> wrote in message
> news:cAsUh.21643$PL.10535@newsread4.news.pas.earthlink.net... 
> Hmmm... I think there is a very wrong implication in your last three
> sentences, Charles. (Rest of the post was interesting and seems fairly
> reasonable.)
>
> The "rest of the world" has not moved to OO technologies because they
> perceived a lack of support for COBOL  or because no-one implemented the
> latest standard.
>
> OO is not an alternative to COBOL; it is a DIFFERENT paradigm. If COBOL
> never existed, a strong case can still be made that the World would move
> to OO technology; if COBOL HAD everything in the last standard, the World
> woud still move to OO technologies, and would probably not use COBOL.
>
> The reasons for the decline of COBOL are nowhere near as simple as it not
> being implemented or supported by its "guardians", although that certaily
> didn't help.
>
> As normally happens with the evolution of species, it is being superseded
> by strains that are much better suited to the modern environment. Despite
> it trying to adapt, it has innate clumsiness that simply has no place in
> today's environment. And when it did try to adapt and implement OO
> programming facilities, the community who should have supported and
> embraced it just didn't. (Interestingly, that same community is now being
> forced more and more towards Java (a pure OO Language), when it could have
> been COBOL if they had made enough noise and shown willing...). There's
> nothing wrong with Java, but it is ironic that people who resisted it
> fiercely as "non-COBOL" are now being forced to embrace it.
>
> I see it as being a bit like the end of the Neanderthals... the new Homo
> Sapiens are quicker and smarter and long term there isn't much hope for
> the poor old species.
>
> It really dens me, but I am enjoying C#... :-)
>
> Pete.
>
>
>

I do not disagree. What I put in those three sentences was not meant as the
reason why but was just meant as evidence of obsolescence for those who
might still be in denial.

On 16 Apr, 00:47, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Charles Hottel" <chot...@earthlink.net> wrote in message
>
> news:cAsUh.21643$PL.10535@newsread4.news.pas.earthlink.net...
>
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> Hmmm... I think there is a very wrong implication in your last three
> sentences, Charles. (Rest of the post was interesting and seems fairly
> reasonable.)
>
> The "rest of the world" has not moved to OO technologies because they
> perceived a lack of support for COBOL  or because no-one implemented the
> latest standard.
>
> OO is not an alternative to COBOL; it is a DIFFERENT paradigm. If COBOL
> never existed, a strong case can still be made that the World would move t
o
> OO technology; if COBOL HAD everything in the last standard, the World wou
d
> still move to OO technologies, and would probably not use COBOL.
>
> The reasons for the decline of COBOL are nowhere near as simple as it not
> being implemented or supported by its "guardians", although that certaily
> didn't help.
>
> As normally happens with the evolution of species, it is being superseded 
by
> strains that are much better suited to the modern environment. Despite it
> trying to adapt, it has innate clumsiness that simply has no place in
> today's environment. And when it did try to adapt and implement OO
> programming facilities, the community who should have supported and embrac
ed
> it just didn't. (Interestingly, that same community is now being forced mo
re
> and more towards Java (a pure OO Language), when it could have been COBOL 
if
> they had made enough noise and shown willing...). There's nothing wrong wi
th
> Java, but it is ironic that people who resisted it fiercely as "non-COBOL"
> are now being forced to embrace it.
>
> I see it as being a bit like the end of the Neanderthals... the new Homo
> Sapiens are quicker and smarter and long term there isn't much hope for th
e
> poor old species.
>
> It really dens me, but I am enjoying C#... :-)
>
> Pete.- Hide quoted text -
>
> - Show quoted text -

My tuppence worth:

<rant>

Cobol is in decline because it was not the major language on the newer
smaller machines that are replacing the mainframes.

Mainframes first faced competition from pcs when client departments
took up pc technology as a way of facilitating their work without the
inordinate delays and expenses of mainframe development and without
being subjected to the arrogance of the mainframe developers (I find
it incredible that only as recently as 2000 I met a mainframe
developer who said that he knew better than the clients what they
wanted and that they should be grateful for what her gave them!).

The way in which we treated our clients in the 80s - 00s was
contemptible and the incoming managers of the client departments
remembered that when they had the opportunity to push for
redevelopments and chose to take the machinery in-department. That
means a move away from the traditional big-box solution to the upstart
Unix/Linux and Wintel platforms, languages and software.

Java quickly established itself on the newer boxes probably in part as
a result of not being Microsoft and through being taught in
Universities.

I suspect that the slowness with which the standards groups have
updated the Cobol standard has not helped but has probably contributed
to the rise of OO technologies and the patchy way in which
manufacturers choose which parts of the standards to follow. I also
suspect that CICS in the IBM world may have been like a ball and chain
to the move to OO Cobol but I am out-of-date with regard to CICS so I
may be wrong about that.

</rant>

On Mon, 16 Apr 2007 11:47:27 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Hmmm... I think there is a very wrong implication in your last three
>sentences, Charles. (Rest of the post was interesting and seems fairly
>reasonable.)
>
>The "rest of the world" has not moved to OO technologies because they
>perceived a lack of support for COBOL  or because no-one implemented the
>latest standard.
>
>OO is not an alternative to COBOL; it is a DIFFERENT paradigm. If COBOL
>never existed, a strong case can still be made that the World would move to
>OO technology; if COBOL HAD everything in the last standard, the World woud
>still move to OO technologies, and would probably not use COBOL.

It could be like comparing CDs with vinyl records - in the era of
iTunes downloads.

Cars replaced horses - but horses are still around.   But they are no
longer a significant part of our transportation system.

Or maybe CoBOL is classical music...

On 16 Apr 2007 06:04:02 -0700, "Alistair"
<alistair@ld50macca.demon.co.uk> wrote:

>Cobol is in decline because it was not the major language on the newer
>smaller machines that are replacing the mainframes.

I bet mainframes handle as much data as ever.   But we have lots more
data needs nowadays.

On 16 Apr, 18:56, Howard Brazee <how...@brazee.net> wrote:
> On 16 Apr 2007 06:04:02 -0700, "Alistair"
>
> <alist...@ld50macca.demon.co.uk> wrote: 
>
> I bet mainframes handle as much data as ever.   But we have lots more
> data needs nowadays.

And there are (reputedly but I don't know what the proof is) more
lines of Cobol in existence than all other coding languages combined.
Any one care to comment?

On 16 Apr 2007 12:39:44 -0700, "Alistair"
<alistair@ld50macca.demon.co.uk> wrote:

>And there are (reputedly but I don't know what the proof is) more
>lines of Cobol in existence than all other coding languages combined.
>Any one care to comment?

I doubt very much if that is still true.

Of course, the concept of "line of code" is obsolete.   More and more
programming uses components that were once written as lines of code.
In the old days, we copied punched cards from programs to programs.
Dragging an object module in a GUI programming environment isn't
easily comparable.

And Excel macros consist of code.     Whatever program is in the
nearest traffic light or carburetor control is replicated all over the
world.   Do they count?

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1176728642.724045.277200@p77g2000hsh.googlegroups.com...
<snip>>
> My tuppence worth:
>
> <rant>
>
> Cobol is in decline because it was not the major language on the newer
> smaller machines that are replacing the mainframes.
>
> Mainframes first faced competition from pcs when client departments
> took up pc technology as a way of facilitating their work without the
> inordinate delays and expenses of mainframe development and without
> being subjected to the arrogance of the mainframe developers (I find
> it incredible that only as recently as 2000 I met a mainframe
> developer who said that he knew better than the clients what they
> wanted and that they should be grateful for what her gave them!).
>
> The way in which we treated our clients in the 80s - 00s was
> contemptible and the incoming managers of the client departments
> remembered that when they had the opportunity to push for
> redevelopments and chose to take the machinery in-department. That
> means a move away from the traditional big-box solution to the upstart
> Unix/Linux and Wintel platforms, languages and software.
>
> Java quickly established itself on the newer boxes probably in part as
> a result of not being Microsoft and through being taught in
> Universities.
>
> I suspect that the slowness with which the standards groups have
> updated the Cobol standard has not helped but has probably contributed
> to the rise of OO technologies and the patchy way in which
> manufacturers choose which parts of the standards to follow. I also
> suspect that CICS in the IBM world may have been like a ball and chain
> to the move to OO Cobol but I am out-of-date with regard to CICS so I
> may be wrong about that.
>
> </rant>
>

There are elements of truth in all of the above, but you have missed the
real point; COBOL is unsuited to dealing with objects, locally, or across a
network. (Actually, it CAN do so quite effectively but nobody was interested
in learning the extensions that enable it to do so. This was a combination
of lack of imagination, blinkered vision, laziness and the arrogance you
mention. Despite my utmost respect for the people who implemented OO into
COBOL, it is still less seamless than OO in an OO language...Jake the Peg,
with his extra leg....)

It can be argued that, if the entire COBOL community had thrown itself
behind OO we would have a very different situation today. OO COBOL would be
perceived as a very useful commercial OO language and IBM would probably not
be encouraging Java on their platforms. For them it was a no-brainer:
"Invest into OO COBOL support, which our user base have rejected, or simply
pick up an existing OO language that the new crops of graduates are going to
be already familiar with..."   Why Java? For years Acadaemia DID provide
COBOL courses (it was the only game in town for commercial applications).
When they realised the future was in OO and the COBOL community had rejected
it, they had no choice but to drop COBOL. Java was being disseminated freely
and without cost, was totally OO based, perfect choice.

The last paragraph is just plain wrong. Lack of a COBOL standard has not
contributed to the rise of OO. (It has certainly contributed to the decline
of COBOL). That rise was inevitable anyway. If it hadn't been Java it would
have been something else; Object technology is necessary to deal with
today's processing requirements. Many Mainframers shake their heads and say:
"No it isn't. We got by perfectly well for decades without it." But they are
wrong. Locked inside Fortress COBOL, resisting fiercely all changes to the
status quo, they just never saw what was happening outside. The evolution of
the Internet, the availability of open software on PCs that empowered
ordinary people to process data with spreadsheets and databases that could
be passed around organizations and the World instantly, meant that the old
days of shrines and temples and mystic incantations to the gods of COBOL
would have to pass into history.

Why are people trying to migrate from their ISAM base to RDB?  It isn't just
because RDB offers more. It is because every time they want a report they
have to write a COBOL program, and the costs of doing that are just not
viable any more. RDB opens up the data resource and makes it easily
transportable across platforms.  (It may take a few years, but they will
eventually realise that embedded SQL is just as bad... by then other people
in the organization will be accessing the data using standard tools (like
Crystal reports, SQL Query, the Query facilities offered by their RDB...),
pulling it into spreadsheets, and processing it anyway. Once they have the
data on the Network they can do anything they like with it, and no COBOL is
required.

I think the moment of catharsis for me was when a senior manager said: "Why
is it that we have a multi-million dollar mainframe that can't put
signatures on letters, when my kid can do it with his $1000 Amiga." It made
me think. It wasn't about hardware, it was about people being able to do
what they want with data, without having to beg a COBOL priest to do it for
them.

I think your tuppence worth is actually a penny ha'penny, Alistair... :-)

Pete.

"Howard Brazee" <howard@brazee.net> wrote in message
 news:brd723dgh4js43p6bghdn0hf680051trin@
4ax.com...
> On Mon, 16 Apr 2007 11:47:27 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
> 
>
> It could be like comparing CDs with vinyl records - in the era of
> iTunes downloads.

Lol! Excellent comparison... :-)
>
> Cars replaced horses - but horses are still around.   But they are no
> longer a significant part of our transportation system.
>
> Or maybe CoBOL is classical music...

I wish... for me, at least, classical music still has relevance in today's
world :-)

Pete.