
The Beauty of COBOL (2018) - fortran77
https://devops.com/the-beauty-of-the-cobol-programming-language-v2/
======
kerng
Have not dealt too much with COBOL but learnt it a while ago. It was one of
the easier languages to comprehend quickly. I thought it was well suited for
input and data processing focused applications.

I do remember thinking it's odd that a line has exactly 80 characters and
putting an asterisk in the 7th or 8th row means the line is a comment.

This is probably not true these days with modern COBOL. But when I saw Python
the first time, and that it enforces similar restrictions with intendation and
then Golang following suite, I had to smile that such old concepts of
enforcing style still are seen as useful today.

Often we just have to go back and see what others have done decades ago to get
new ideas!

~~~
YeGoblynQueenne
>> This is probably not true these days with modern COBOL

It still is. Which column (not row) a statement starts in matters and it's a
syntax error to start the wrong statement in the wrong column. Sorry I don't
remember any specific examples because it's been a few years since I last used
COBOL.

I remember hearing that this had something to do with how the early COBOL
programs were encoded on punched cards. Anyway there was some practical aspect
to it that is now not an issue anymore with the changes to hardware.

~~~
wycy
This was the case with Fortran 77 too, and for the same reason (punch cards).
But modern Fortran (F90 through F2018) no longer requires formatting by
column.

~~~
YeGoblynQueenne
Good point. I think maybe one reason is that COBOL is valued for its
consistency, with the same code often running on modern machines that was
written 50 years ago or so (at least that was the received wisdom when I was
working at a COBOL shop). Perhaps the same is not the case with FORTRAN?

------
pgtan
For me, COBOL is so over-presented in the media among the old (mainframe)
lagnuages, but I recently was surprised to see a production mainframe LPAR
offering an APL2 interface,and it seems the language is still maintained on
zOS[1]. But I never heard of business application written in APL.

1 [https://www.ibm.com/support/pages/apl2-whats-
new](https://www.ibm.com/support/pages/apl2-whats-new)

~~~
nickpeterson
APL was strongly supported by IBM early on, and was used for verification of
early IBM systems. When you look at APL in context, it was extremely ahead of
its time.

------
ainar-g
Oh man, I always wanted to learn more about COBOL. People like to crap on the
language, but this article makes it seem like it's not that bad, actually. I
could see myself programming that, for a large sum of money of course.

With that said, the real COBOL code is probably much more horrifying, when you
consider, just how much uglier real-world code is compared to small tutorials
and review articles. I would really like to read a series of “COBOL War-Time
Stories”.

~~~
DrScump

      how much uglier real-world code is 
    

One of my first projects in COBOL was to complete a rewrite, using structured
programming, of a report writer that dated back into the 1960s. If you think
COBOL is hard to follow, imagine COBOL code _laden with gotos_ and older than
the 1968 standard.

~~~
Starwatcher2001
Yeah, that sounds fun. Did that have the evil "alter" statement, which caused
even more spaghetti with gotos?

~~~
DrScump
I think ALTER usage was formally disallowed.

------
Starwatcher2001
I wouldn't call it beautiful, but COBOL is a fairly capable language. I used
Microsoft COBOL on the original IBM PC (twin floppy) in 1985 to produce a
realtime multiuser data collection system in a factory. This interfaced to
various machines and devices using a custom TSR* routine written in x86
assembler.

COBOL was chosen by the customer as they were running an IBM System 36, and
the implementation was capable of calling the assembly code almost directly.

Each compile would take around 20 minutes, which teaches you to be careful
with the syntax! When the source code got beyond 64k, we had to build the app
in sections as that's all IBM Edit at the time could handle at one time. As
the article shows, COBOL is quite verbose, so 64k isn't that large!

In later years we updated to Microfocus COBOL which was much better than the
Microsoft version.

I can't imagine any modern programmer having any problems learning COBOL
sufficiently well in a few days. It was my third language after BASIC and
assembler.

[*] TSR = Terminate and Stay Resident program, which you loaded into MSDOS
first, prior to running the main (COBOL) program. A very poor-man's "multi-
tasking".

------
cable2600
OpenCOBOL is now GNUCOBOL. [https://sourceforge.net/projects/open-
cobol/](https://sourceforge.net/projects/open-cobol/)

------
jimws
> Well-written code is a work of art. Always has been, always will be.

The same thing was thought of assembler programming a few decades ago. Now it
is rather a lost art. I fear that a day would come when machine learning
algorithms can write code on their own and coding itself would become a lost
art like assembler has become now.

~~~
deelowe
Assembler isn't lost? It's still very common in hardware development.

------
zerr
To clarify, COBOL (similarly to SQL) was intended as a UI - it was created for
business people, non-programmers.

~~~
DrScump
No, it wasn't. Non-programmers didn't program in COBOL. Non-programmers
generally lacked access to IDEs (even basic TSO workflows), compilers, and
computer time, let alone JCL and data sets.

COBOL was intended for business cases for which FORTRAN was ill-suited, and
COBOL shops generally didn't need science/math implementations.

Even PL/1 and RPG required a degree of programming skill.

~~~
jacquesm
Actually, yes it was, in a way. COBOL was intended to do away with programmers
and to allow their managers to interact with the computer directly.
Programmers of the day worked with machine language and generally took forever
to deliver bits and pieces of functionality due to the low level nature of
their tools. The idea behind COBOL was that the compiler would take a high
level specification (the 'source code') which any competent person should be
able to put together rather than that this specification had to be handed to
the programmers.

Of course, the end result was that we ended up with just one layer of
abstraction and programmers were in more demand than ever before because of
their increased productivity, and the 'managers' ended up being programmers
themselves.

This then led to the schism between 'systems' programmers (those that
understood assembly) and 'applications' programmers, those that only worked in
high level languages.

When I started working professionally in IT this division was still quite
visible.

~~~
K0SM0S
_“When I started working professionally in IT this division [the schism
between 'systems' programmers and 'applications' programmers] was still quite
visible.”_

I think you nailed a rather fundamental trait (spectrum) in programmers that
carries on, morphing along with times.

From systems to business logic, or from the 'container' (pun not intended) to
the 'content', and dare I generalize: from a strictly technical eye to a
strictly goal/business mindset (again, this is a spectrum, everything in-
between exists, all flavors contribute to make a world).

The cliche would be your low-level C/Rust guy versus some frontend Flash/Js
person; but this is oversimplifyling (C person might be very goal-driven with
a business approach; Js person might be a performance expert). Reality speaks
more of an engineer's world view so to speak: from "bottom -> up" (those that
assemble elementary pieces, that need to crack the puzzle by understanding
each component, like Lego) to "top -> down" (those that rather manipulate
large abstract/complex entities as 'black boxes' and rather work on their
structure, the graph, dimensions, and shift behavior thusly with surgical
cost-effective changes).

Oh just my 2cts I'm probably rambling. I just know that these two extremes on
the spectrum are what we battle with for every decision we make, if we are
aware _enough_ of _both_ sides. _(Is that a blessing or a curse?.. you tell
me!)_

I think it's why, deep down, we still (and might always) search for 'the next
C' (cue Rust, Go, D, depends on use-cases I suppose), or why some people are
almost principled advocates of the WebAssembly paradigm in complement or
replacement of the Js ecosystem. These are the technical people of the
spectrum. The high-level engineers are more about pushing for
interoperability, available skill pool, maintainability.

It's just that 'programming' as a skill now pertains to three dozen very
different jobs so the general line is much fuzzier than in the 1950-60-70's;
but I think it's a product of human intelligence, whether how we think or how
we build our tools, our machines. _Historical parallels, yadi yada._

The mainframe situation, I think, is even more telling. Every programmer under
the Sun has thought of ways to replace COBOL, and there are decent candidates.
But the business side of us, of above, of reality, has mainframes still
running on COBOL. Because as a 'black box', it works; the benefits of a
rewrite have not yet justified their cost.

I know a solid team usually requires at least 1 of each 'sides' of the
spectrum, keeps everyone else honest (as engineers in a problem space).

~~~
thanatropism
Then there are mathematicians and quants, like me: breastfed on Matlab, weaned
on Python, claim a much deeper understanding of algorithms and code factoring
techniques than front-end jockeys, but still shudders at memory management
(other than by preallocating matrices/numpy arrays), devops and other
practices that are all in a day's work for "man's man programmers".

Granted, we're precisely what PL authors had in mind from time to time (eg
with SQL): nonprogrammers who can write domain code. But because our training
goes into proving big-O complexity, etc. front-end jockeys look at us as if
we're capital-P programmers.

------
the_af
I still have nightmares about COBOL. "Beauty" and "COBOL" do not mix in the
same sentence. Forget this article, it's not a nice language at all. I'm not
going to crap all over the language -- I understand the requirements of its
time -- but now you'd have to be crazy to _want_ to use it.

It's not even true that COBOL programmers earn a lot of money because it's a
niche and there are few programmers still writing it and banks are in a hurry
to hire them. That's not my experience: all the COBOL programmers I know are
mostly old guys earning average/below average salaries. And dealing with banks
and similar institutions, which is a hell of its own.

If you like writing software and enjoy nice programming languages, COBOL is
not for you. If you want to earn a lot of money or work on interesting
projects, COBOL is not for you. If you're a bank manager, maybe COBOL is for
you.

~~~
commandlinefan
> "Beauty" and "COBOL" do not mix in the same sentence.

The author is falling into the trap of assuming that “easy to learn” =
“optimal”. COBOL is extremely easy to learn; you can learn it in a few days.
That simplicity comes at a price: you outgrow it _really fast_. You can’t even
write a generic sort routine or a linked list data structure in COBOL; the
language just doesn’t allow that sort of reuse. I thought it was almost
comical that the author had so little experience with COBOL that he wrote that
it allowed you to not repeat yourself: the painful experience of rewriting
things like sort routines every time you had a different comparison condition
or rewriting linked list traversal code when you had a structure with a
different schema than the structure that you last wrote linked list traversal
code for was the reason everybody started abandoning COBOL for more flexible
languages like C (even Pascal was better).

~~~
vajrabum
I won't argue the merits of COBOL. I stopped doing it for a living 35 years
ago for a reason, but sort is not a good example. COBOL has generic SORT and
MERGE facilities built in as verbs. In an IBM environment (i.e. writing real
applications) you'd be hard pressed to build something that has better
performance than what's provided out of the box.

~~~
marktangotango
Those were good for working with flat files and nothing else!

~~~
vajrabum
You don't need sorting for VSAM or DB2 or their non-IBM equivalents.

------
ngcc_hk
Interesting. The problem of cobol is that is verbose, like java. Type type and
then type. Copy and find all the time. Good luck to understand any as it takes
a lot of time to read it.

Do not like cobol or java.

~~~
kerng
Curious what language you would prefer? Just to trying to understand you
argument better. Assembly?

~~~
eru
Python is relatively low on the kind of boilerplate Java has.

(Or if you want to go more extreme, Haskell can really give you some terse
programs.)

I'm not the OP.

~~~
SmellyGeekBoy
As someone who has worked with both in a professional setting, Python has a
lot of similarities with COBOL, IMO.

~~~
ASalazarMX
As someone who has also done that, the most important thing in common is that
they're programming languages. COBOL is a rigid and "square" language, I'm
tempted to call its style "COBOLic".

Any language where the dots at the end of statements are crucial part of the
logic flow can't be that similar to Python.

------
ncmncm
I wonder when it will dawn on the COBOL tool vendors that a big chunk of what
makes COBOL unpleasant is the all-upper-case presentation. The program is
SHOUTING ALL THE TIME.

------
earthboundkid
Has anyone made a syntax converter for COBOL to make it read like C-style
language? At the very least, it would be trivial to make a macro to get rid of
the magic column numbers.

------
AdieuToLogic
COBOL was the original “self documenting language.” And that is why many
others followed it.

