Home > Archive > Cobol > April 2007 > The Life Cycle of Technology and COBOL
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
The Life Cycle of Technology and COBOL
|
|
| Charles Hottel 2007-04-15, 6:55 pm |
| 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.
| |
| Pete Dashwood 2007-04-15, 6:55 pm |
|
"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.
| |
| Charles Hottel 2007-04-15, 9:55 pm |
|
"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.
| |
| Alistair 2007-04-16, 6:55 pm |
| 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 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.- 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>
| |
| Howard Brazee 2007-04-16, 6:55 pm |
| 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...
| |
| Howard Brazee 2007-04-16, 6:55 pm |
| 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.
| |
| Alistair 2007-04-16, 6:55 pm |
| 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?
| |
| Howard Brazee 2007-04-16, 6:55 pm |
| 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?
| |
| Pete Dashwood 2007-04-17, 3:55 am |
|
"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.
| |
| Pete Dashwood 2007-04-17, 3:55 am |
|
"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.
| |
| Charles Hottel 2007-04-17, 3:55 am |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1176752384.649698.130160@b75g2000hsg.googlegroups.com...
> On 16 Apr, 18:56, Howard Brazee <how...@brazee.net> 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?
>
That is part of the reason that the decline is gradual.
<WAXING-NOSTALGIC>
I still think COBOL is better at lots of business programming tasks. COBOL
EVALUATE is better than Java the switch statement. Formatting of data is
often more cumbersome in Java. The default rounding for float and double is
not what business applications want., so you either have to do your own or
use BigDecimal. In general float and double are less than ideal for monetary
calculations. Java classes and objects have many positive features but the
relationships among them can get complicated. There are entire books
devoted to design patterns.
You don't see any obfuscated coding contest for COBOL but you do for C from
which Java inherited a lot. C can be hard to read and C++ can be even worse.
"Effective C++" and "More Effective C++" and "Java Pitfalls" and "More Java
Pitfalls" and "Java Puzzles: Traps, Pitfalls and Corner Cases" are just a
few of the many books which seem to indicate increased difficulty of use for
OO languages. Of couse advocates of those languages will say they are no
more difficult than other languages of "comparable power". They would
probably say COBOL is easier because it is less powerful.
The people that want client/server apps and distributed app over the web and
fancy GUI apps on the laptop/desktop, for whatever reason do not see COBOL
as the way to go.
| |
| Alistair 2007-04-18, 7:55 am |
| On 16 Apr, 21:08, Howard Brazee <how...@brazee.net> wrote:
> On 16 Apr 2007 12:39:44 -0700, "Alistair"
>
> <alist...@ld50macca.demon.co.uk> wrote:
>
> 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?
Do you count the traffic lights as one instance of written code or as
a million instances?
| |
| Alistair 2007-04-18, 6:55 pm |
| On 17 Apr, 01:15, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Alistair" <alist...@ld50macca.demon.co.uk> wrote in message
>
> news:1176728642.724045.277200@p77g2000hsh.googlegroups.com...
> <snip>>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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 interes=
ted
> 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....)
Not being into OO I can not comment on the kludge factor of Cobol OO.
I do believe that in the shops where I worked we missed OO Cobol
because of a number of factors: we had CICS and we had Natural for
online stuff; our compilers were only updated when the old one was no
longer supported; we did not do any research into the newer standards
(despite having a director of the NCC working for us) and we had no
obvious and immediate call for OO.
>
> 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 simp=
ly
> 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 rejec=
ted
> it, they had no choice but to drop COBOL. Java was being disseminated fre=
ely
> and without cost, was totally OO based, perfect choice.
I think I forgot the rant about run-time licence fees which has
plagued Cobol. Certainly a business model which discourages
application development.
>
> 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 decli=
ne
> of COBOL). That rise was inevitable anyway. If it hadn't been Java it wou=
ld
> have been something else; Object technology is necessary to deal with
> today's processing requirements. Many Mainframers shake their heads and s=
ay:
> "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.
In the absence of an OO Cobol standard then Java/C++ etc., were bound
to benefit.
I miss the olden dayes, the incense, incantations, chalk
pentagrams....
>
> Why are people trying to migrate from their ISAM base to RDB? It isn't j=
ust
> 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 peop=
le
> 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: "W=
hy
> 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 ma=
de
> 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 f=
or
> them.
I'm sure many of us have attended parties where the conversation went
something like:
"What do you do?"
"I work with computers..."
"My son has a Sinclair Spectrum and is having problems with....."
or
"My son programs games on his Sinclair Spectrum and I wonder if you
could give him some advice about how to...." to which the reply
indicates that what the kid does on his toy computer is harder than
what one does on the mainframe.
>
> I think your tuppence worth is actually a penny ha'penny, Alistair... :-)
4 cents worth in the US with the =A3 hitting the magic $2.
>
> Pete.- Hide quoted text -
>
> - Show quoted text -
| |
| Alistair 2007-04-18, 6:55 pm |
| On 17 Apr, 02:48, "Charles Hottel" <chot...@earthlink.net> wrote:
> "Alistair" <alist...@ld50macca.demon.co.uk> wrote in message
>
> news:1176752384.649698.130160@b75g2000hsg.googlegroups.com...
>
>
>
>
>
> That is part of the reason that the decline is gradual.
>
> <WAXING-NOSTALGIC>
>
> I still think COBOL is better at lots of business programming tasks. COBOL
> EVALUATE is better than Java the switch statement. Formatting of data is
> often more cumbersome in Java. The default rounding for float and double is
> not what business applications want., so you either have to do your own or
> use BigDecimal. In general float and double are less than ideal for monetary
> calculations. Java classes and objects have many positive features but the
> relationships among them can get complicated. There are entire books
> devoted to design patterns.
>
> You don't see any obfuscated coding contest for COBOL but you do for C from
> which Java inherited a lot. C can be hard to read and C++ can be even worse.
> "Effective C++" and "More Effective C++" and "Java Pitfalls" and "More Java
> Pitfalls" and "Java Puzzles: Traps, Pitfalls and Corner Cases" are just a
> few of the many books which seem to indicate increased difficulty of use for
> OO languages. Of couse advocates of those languages will say they are no
> more difficult than other languages of "comparable power". They would
> probably say COBOL is easier because it is less powerful.
I once got told off at a Unix shop for using obscure code in a script
which would be difficult to maintain at 3 am but I had only cloned it
from an existing and approved script. I found that after a few w s
of working their, as a Unix newbie, I had more knowledge than the old
hands did.
>
> The people that want client/server apps and distributed app over the web and
> fancy GUI apps on the laptop/desktop, for whatever reason do not see COBOL
> as the way to go.
I presume that you are still in waxing nostalgic mode as their is no
end tag?
| |
| Charles Hottel 2007-04-18, 6:55 pm |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1176901229.723969.324700@p77g2000hsh.googlegroups.com...
> On 17 Apr, 02:48, "Charles Hottel" <chot...@earthlink.net> wrote:
>
> I once got told off at a Unix shop for using obscure code in a script
> which would be difficult to maintain at 3 am but I had only cloned it
> from an existing and approved script. I found that after a few ws
> of working their, as a Unix newbie, I had more knowledge than the old
> hands did.
>
>
> I presume that you are still in waxing nostalgic mode as their is no
> end tag?
>
Yeah I waxed off into the sunset
| |
|
| In article <4oxVh.6199$3P3.1158@newsread3.news.pas.earthlink.net>,
Charles Hottel <chottel@earthlink.net> wrote:
>
>"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
>news:1176901229.723969.324700@p77g2000hsh.googlegroups.com...
[snip]
>
>Yeah I waxed off into the sunset
Hey... don'cha know that'll make your eyes weak?
DD
| |
|
|
|
|
|