
COBOL Leads Us Back to the Future (2015) - brudgers
http://www.informationweek.com/software/enterprise-applications/cobol-leads-us-back-to-the-future/d/d-id/1320963
======
jrapdx3
A discussion I've often had, that old technologies never disappear altogether,
there's always an interest, revivals inevitably occur especially among the
younger generations to whom the old stuff is new.

Not too long ago I overheard a conversation among a group of college-age
artists chattering about the merits of silver-based vs. digital photography.
Basically, in their eyes digital was old hat, the familiar way to make images
while film photography was intriguing, exotic by comparison.

Of course as a genuine old guy I found their view amusing but refreshing.
Having used film, and spending way too many hours in stuffy darkrooms I knew
all about the subject. It was fun to talk a bit with a few of the students,
but I understood they wouldn't hear it from me. No, they'll have to learn for
themselves about the merits and tradeoffs of the old ways vs. the
contemporary.

In programming as in all other arts, it's good once in a while to revisit the
trails our forbears traversed. We should all travel there as part of an
education, it gives us a greater appreciation of what we have now. And
sometimes even us old hands will have the urge to revisit the dusty past,
though likely choose not to linger there.

Once in a while we should touch ancestral ground, it's a worthy ritual to
honor our ancient heritage, lest we forget how far we've come.

~~~
vezzy-fnord
Computing actually has a very chaotic evolution compared to other fields.
Where most can be seen as linear progressions, computing is heavily prone to
stasis and regressions.

Revisiting ancestral ground in programming actually makes you think how little
we've come, not how far.

~~~
muraiki
Although my self-teaching of programming began in Python it ended up veering
through Racket and Smalltalk. I almost regret learning Smalltalk after
experiencing what a joy it is to program in. Writing a webapp in Seaside, with
all of its great features for live inspection and debugging, and then
experiencing Django and Node was an eye opener.

------
marktangotango
>> The next reason is readability. COBOL is known as a "verbose" language,
especially when it's compared to a very terse language like C++. From a
debugging standpoint, COBOL can be like reading a novel: In fact, I'd almost
bet that, with a few variables thrown in, you could get arbitrary chapters
from Game of Thrones to compile. Of course, all your favorite functions would
die depressing, lonely deaths, but still…

In a way, this verbosity of which he speaks is the antithesis to the current
'Learn to Code' fad. And COBOL is a perfect example of a language that was
intended to be so easy and intuitive to read and write, business people could
do it (as it was promoted in the early years). COBOL has sections, paragraphs,
and sentences, verbs and variables are nouns. Control flow is either via goto
or 'perform'ing paragraphs or sections.

Awesome in theory, for simple programs, the idea that anyone can write/read it
may even be true. But the devil has always been in the details. Logic in the
perform/goto world quickly spirals out of control/comprehension, and for any
non trivial COBOL application, there are multitudes of programs, flat files,
indexed files, etc.

Not to mention the complexity of batch cobol (if you haven't lived the horror
of mainframe JCL, I envy you) and wiring together green screens in the CICS
environment are all very involved, the definition of platform specific.

>>The first reason is employability. As noted, there are still plenty of
companies running applications built on COBOL. And not all of those
applications are archaic: Since 2002, COBOL has had an object-oriented
framework.

And most of them have off shored most or all of their development. One
prominent local employer of COBOL programmers has a skeleton crew of COBOL
developers after once employing thousands. Additionally, I'd have to see some
stats that anyone has upgraded to the 2002 standard to believe anyone is
actually using object oriented COBOL in production.

Having said all that, COBOL was designed in a time of scarce resources and
does make excellent use of system resources. COBOL is close to the metal in a
way that C is not; COBOL is more like verbose assembler than C. In COBOL all
storage is statically allocated (memory allocation is possible, but not
typical), and there is no call stack. This mean COBOL programs never
experience stack overflow exceptions, out of memory errors, buffer overflows.
Characteristics that make it 'safe' from a security and multi tenancy
perspective.

~~~
acheron
I was in college when the object-oriented COBOL standard was released -- my
software engineering professor at the time mentioned it in class one day and
made the (obvious) joke that it should have been called "ADD 1 TO COBOL."

~~~
Luyt
The next step is obviously 'functional COBOL'.

------
erikb
It's funny and actually quite important that the title actually says that this
is a current article!

------
tempodox
Oh my, there's even COBOL for iOS! I might have to erect a shrine for the
spirit of Grace Hopper after all.

I'm always looking out for an implementation of language X on iOS, and COBOL
is not what I expected to materialise there :) Still, it might be fun to play
around with — you can never know too much and I'm curious as to how compiler
output looks like (though I probably won't see that on iOS).

------
gjm11
Disappointingly fails to link to
[http://www.coboloncogs.org/INDEX.HTM](http://www.coboloncogs.org/INDEX.HTM)
which frankly is about as credible as the idea that COBOL might be "just
hitting its prime". Nothing in the article or anything it links to offers any
support for that.

------
DonHopkins
Not that I don't think it sucks but use it myself judiciously when necessary,
but where is PHP in IEEE's language popularity index? Is it really not in the
top 20, less popular that COBOL and Processing? Or does IEEE just not consider
PHP a programming language?

------
dmichulke
What's the daily consulting fee range for COBOL? Would there be a monetary
merit to learn it, relative to other "Enterprise Languages" such as Java or
C#?

~~~
jbarham
Most production COBOL programs run on IBM compatible mainframes so you'd also
need to get a handle on developing in MVS aka "z/OS" and how to hack JCL
config scripts--the horror! That's difficult to do without getting hands-on
experience.

As someone whose first job out of uni almost 20 years ago was in a mainframe
environment, I have no desire whatsoever to go back to it and would _strongly_
recommend against working in COBOL if you can make a living using tech that
was developed in the last 40 years.

~~~
twic
Also, nobody calls it the "mainframe". It's the "host environment". It took me
a couple of weeks on my current project to work out why my new colleagues were
so reluctant to modify the customer re-contact batch process - "oh, that's on
the host environment!".

------
drinknderive
1 of 7 pages am I reading this right?

~~~
tempodox
Yep. There is even a page turn button, no doubt programmed in COBOL.

~~~
panglott
Or at least CobolScript.
[https://github.com/ajlopez/CobolScript](https://github.com/ajlopez/CobolScript)

