Post by HansJPost by Pete DashwoodPost by HansJPost by d***@panix.comPost by Howard BrazeeOn Wed, 31 Aug 2011 18:45:24 +1200, "Pete Dashwood"
[snip]
Post by Howard BrazeePost by Pete DashwoodThe others I thought were generally lame or have been done before.
[snip]
Post by Howard BrazeeMe too, but I will note that this joke isn't exactly new.
Are there COBOL jokes that are exactly new?
DD
... well I don't know any new COBOL jokes, but should we make jokes
about someone lying in his deathbed???
:-)
I have been saying for some time now that COBOL should be allowed to
go with dignity. However, I don't think he's quite ready to go just
yet.
'Nother three years, I reckon... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
... Pete, ok, I think its going to take a bit longer, if you're right,
I'll buy you a good meal.
I'm not sure whether that was a lucky guess or whether you have inferred my
delight in dining, Hans. :-)
If there's good food going, I'm there... :-)
Food is something very dear to my heart (I love cooking it, eating it and
sharing it with others). But I wasn't aware that I had consciously indicated
that here. This particular indulgence means I have to watch my weight and I
learned many years ago that eating delicious food doesn't mean you have to
become obese. I am 1.83 metres (around 6 feet) tall and never weigh over 100
KG (220 pounds). As an ex-Rugby player I have a large enough frame to carry
this and I'm not afraid to get into a swimsuit. It is achieved by eating
sensibly and going for healthy foods. I don't get as much exercise as I
should (although now the Summer is coming here I hope to address that) but
it is fitness levels that suffer rather than general health.
Anyway, I will gladly accept your offer, but let's be sure it is fair.
Sometime back in the '90s I stated that COBOL would no longer be the
development language of choice by the year 2015.
This was at a time when Gartner were saying that astronomical numbers of
lines of COBOL could never be converted or thrown away and the implication
was that COBOL was still a good career choice and it's future was not in
doubt. (Gartner have since backtracked on those claims but there are vested
COBOL interests who have not given the same publicity to the recant which
they did to the original.)
(Many people, particularly in this forum, were pleased to hear it and lapped
it up...)
I made my statement because I realised that the paradigm had changed, that
the new one was "better" (in terms of where IT was going, which was to
Networked solutions), and that COBOL was no longer cost effective. (This
last is the REAL major factor for the decline of COBOL). For many years
there was no choice; you HAD to maintain thousands (millions?) of lines of
COBOL. It was tricky and demanding. A one line change can have impacts in
programs way downline and the effects can require considerable time,
application, and skill to run down and fix. The fix causes more problems and
the whole cycle repeats itself. Not only that, but the tools provided for
working with COBOL were woefully inadequate, yet people just accepted them
because they hadn't seen anything better.
Object orientation allowed the building of components that could encapsulate
functionality and be re-used. They were visible only through an interface
and they could have multiple interfaces. If the logic in a component was
found to be flawed you could fix it, secure in the knowledge that NOTHING
outside that component would be affected. In fact, components were usually
small enough that you could rewrite the entire component in less time than
it took to fix standard COBOL... It went even further as people realised
that you could buy packaged functionality and plug it into your
applications. If it didn't do what it said on the box the vendor would
replace it. (In the 25 years I have been using component based development
with a mix of third party components as well as my own, I only ever had one
occasion to contact a component vendor. They rectified the problem within 24
hours. It probably would have taken more than that to locate and fix it in
COBOL source...) There was no longer any need to enshrine Source Code;
FUNCTIONALITY was everything.
COBOL people just sniffed and said "We've been writing modular code for
years...". The other implications of OO programming (and they are legion)
were never discovered by them. Meanwhile, outside COBOL a new IT world,
based on the new paradigm was being constructed. A new generation of more
"computer literate" IT users was arriving in the workplace (with higher
expectations than their predecessors who had simply had to accept whatever
the COBOL guys gave them...) and a new generation of programmers was coming
out of Acadaemia. They simply didn't need COBOL any more.
If you were to compare the role of COBOL in the IT world of the l970s
through to perhaps the mid 1990s, with the role of COBOL in the IT world of
today, I think I could claim that my statement is already vindicated. COBOL
is no longer the development language of choice for just about anybody. (Can
we agree that less than 2% of the world's development constitutes
"nobody"?). COBOL is now around the 30th most popular development language
(and falling), when it was in the top five for over 30 years.
On that basis I could already claim my meal with you :-).
However, when I said "'Nother three years I reckon..." it was a
light-hearted allusion to my previous 2015 date. (yes, it should have been
"four years" but I was tired when I wrote it... :-))
Having said all of the above, there IS a place for COBOL legacy and it will
be with us for a little while yet. COBOL is excellent at batch processing
and there are still many systems around that require batch processing.
Similarly, there are many mainframe systems using CICS for their transaction
processing and it will be some time before all of that is replaced. (But,
you can be certain it WILL be replaced. The question is WHEN not IF)
Modern systems avoid batch processing. The idea is that you design a data
warehouse/repository/database that can model the real world and use
distributed processors to update it in real time, and derive information
from it. At any given moment, the data store reflects reality so there is no
need to update it overnight. "period boundaries" (delimited by dates) are
processed on the basis that every piece of information in the store has a
timestamp derivable for it, if not explicity placed in a DB row. Instead of
just monthly intervals being reported, you can set start and end dates for
ANY period you like and the information can be presented to you on a screen
instantly or on a printed report (derived from the screen display, or built
with tools like stimulsoft and Crystal (no specifc coding for reports) .
High frequency or key reports may be built in real time line by line as the
transactions which would generate them occur. This is made possible by
parallel processing using distributed processors. It is a far cry from the
centralized processor of the COBOL world.
Maybe you would like to define what you see as being fair for me to claim my
meal (or not), Hans. :-)
Pete.
--
"I used to write COBOL...now I can do anything."