
Don't hate COBOL until you've tried it - wslh
https://opensource.com/article/17/8/what-about-cobol
======
hodgesrm
I have not used COBOL for 30 years but the language deserves respect. The
transition from assembler to COBOL was one of the biggest productivity
improvements in the history of programming, comparable to the introduction of
Java and VM-based programs in the 1990s.

COBOL is still pretty efficient for tasks like scanning data on magnetic tapes
--not that most of us do that any more. In fact it was pretty good for any
problem that involved reading from or writing to storage devices because you
could control the data layouts very precisely. It was great on reports for the
same reason. I even wrote a simple doc markdown processor in COBOL because the
place I worked didn't have usable word processors and we needed something to
do pagination and formatting of docs.

I don't miss the verbosity or the lack of modularity but on the other hand
COBOL was an effective tool that you could use to solve problems more quickly
than other tools available at the time.

~~~
colejohnson66
> because you could control the data layouts very precisely

You can do that in assembly too

~~~
colejohnson66
Ah. I’ve been downvoted... Guess I should’ve been more clear. I was
referencing how the OP said COBOL was easier for data layouts. So, not really
knowing COBOL, I was asking why. Poor wording.

~~~
unoti
The feature we’re talking about here is an easy to use version of doing memory
layouts like you’d do with C structs and unions. And combined in with that is
automatic number formatting. And all of it uses a clean concise layout that’s
self documenting.

~~~
waltman
COBOL structures are better for fixed-length strings than C structs are
because C really prefers strings do be null terminated. In C you've got to
specify the length of each string, whereas in COBOL the compiler takes care of
that for you.

~~~
kazinator
I can even do that better in Lisp _over_ C structs. In my own home-grown
dialect. Suppose we have

    
    
      struct foo {
        int count;
        char name[16]; /* not null terminated! */
      };
    

REPL: define an alias name _foo_ for the type with _typedef_ :

    
    
      1> (typedef foo (struct foo (count int) (name (array 16 char))))
      #<ffi-type (struct foo (count int) (name (array 16 char)))>
    

Now put an instance of the Lisp struct into a binary buffer using this FFI
type:

    
    
      2> (ffi-put #S(foo count 42 name "ABCDABCDABCDABCD") (ffi foo))
      #b'2a00000041424344 4142434441424344 41424344'
    

Now, recover a new Lisp struct instance from this binary struct:

    
    
      3> (ffi-get *2 (ffi foo))
      #S(foo count 42 name "ABCDABCDABCDABCD")
    

No problem; the FFI type system knows that an "array of char" is different
from a null terminated string, and can make it correspond to a Lisp string in
both directions.

Now, for fun, let's poke a zero byte into that buffer:

    
    
      4> (set [*2 8] 0)
      0
      5> *2
      #b'2a00000041424344 0042434441424344 41424344'
    

There it is. Now decode:

    
    
      6> (ffi-get *2 (ffi foo))
      #S(foo count 42 name "ABCD\xDC00;BCDABCDABCD")
    

What's that? My UTF-8 decoder treats the 00 as an invalid byte, and maps it
into the surrogate pair range U+DCXX. The otherwise optional semicolon was
output because the next character in the string is a hex digit.

If that U+DC00 is encoded back, it will reproduce the null byte:

    
    
      7> (ffi-put *6 (ffi foo))
      #b'2a00000041424344 0042434441424344 41424344'

------
lokedhs
Once in a while I decide I want to play with COBOL, so I install GNU COBOL,
dig out my old test code and try to use it to do something interesting.

So, most recently I wanted to simply read a file, do some simple processing
and then write an output file. Very basic, right?

Not so much with COBOL.

First you have to statically declare the files you want to use. Let's say you
want to read from "foo.txt":

    
    
      environment division.
      input-output section.
      file-control.
          select foo0 assign to "foo.txt"
          organization is sequential
          access mode is sequential
          file status is fs0.
    

You then need to declare (statically again, of course) the structure of the
records in the file. You can think of this as global variables that gets
filled in when reading from the file:

    
    
      data division.
      file section.
      fd foo0.
      01 foo0-rec.
          02 foo-name     pic x(40).
          02 foo-value    pic x(20).
    

You also need to declare the "fs0" variable:

    
    
      working-storage section.
      01 fs0              pic 99.
    

Then, you need to open the file. That's not too hard:

    
    
      open input foo0.
    

Then you want to read from it. You can do that using the command:

    
    
      read foo0.
    

After the read, the variable "fs0" will be 0 when you've reached the end of
the file, so you need a loop that, I presume (I never got this part to work
right), would look something like:

    
    
      perform with test before until fs0 = 0
        read foo0
        * foo-name and foo-value now contains data from the file
      end-perform
    

After all of this, I decided I wanted to do something different. I wanted to
call a web service to load some information over HTTP. I dropped that project
really quickly once I realised that the only way to do that was to use libcurl
and directly access it using FFI. The FFI that is provided by GNU COBOL isn't
really easy to work with, as evidenced by this discussion:
[https://stackoverflow.com/questions/26367026/how-to-make-
htt...](https://stackoverflow.com/questions/26367026/how-to-make-http-
requests-from-cobol)

If you look at the code that is linked from that page, you'll rather quickly
realise why COBOL is not such a great idea for general purpose computing.

~~~
waltman
It's certainly true that there's a lot of boilerplate verbosity involved in
reading files in COBOL. But once you've done that, parsing out the fields will
likely be much simpler than in most modern languages. Records like this are
still produced at government agencies such as the US Census Bureau. I've often
wondered if it might be simpler to do the parsing in COBOL and then pipe it to
another language to do the rest of the processing.

~~~
tolle
On IBM i all files are are also databases, so you could just define the length
of all the fields in the file, then it's a SQL database ready for use. No need
for a program to parse it. Just define a file, copy the incoming file to that
file. Ready to be handled with SQL. Fixed length records are trivial on the
platform.

------
wiz21c
I have regualr talks with people who were using COBOL a while ago. There are
things were cobol is good :

1/ COBOL run in closed environments. This allows these to be rock solid. (no
such thing as a dependency nightmare). You don’t have such a thing as
different version of Java on your testing and production environment.

2/ COBOL forces you to mix concerns : DB access, file I/O, business logic.
This is sometimes useful to get a complete picture of what’s going on in a
program. In Java, you have to wander through your DAO, data model, business
logic, etc. which are spread everywhere.

3/ Code resue is hard to acheve so there is some copy/paste. That is sometimes
good in the sense that if you fix a program, you won’t accidentally introduce
a bug in a copy of that program. (many of us will scream at reading this, but
consider it).

4/ Of course COBOL programmers are good too and they use these old practices
in a sensible way

5/ COBOL technologies don’t change often. So there’s no discussion about
changing your framework. When you write software that must last for at least
10 years, this makes choices easier.

~~~
planetjones
I don’t think COBOL does force you to mix concerns. You could create sub
modules / services which you call from a main program to do things like file
writing or database reading.

Java doesn’t also say you have to separate concerns. You could easily write a
single method which mixes business logic and IO (file and DB)

When writing a batch program you need a balance between understanding it,
making it efficient and reliable and promoting re-use (e.g. if many batch
programs want the same behaviour break it into a reusable module). COBOL still
has dependencies too, so each program is rarely written in isolation and you
have to co-ordinate with other teams to ensure their module versions are in
sync with yours.

The thing that has always let COBOL down for me is the lack of automated
testing.

~~~
wiz21c
>>> Java doesn’t also say you have to separate concerns.

Sure, I was talking from inside my own enterprise-context where Java actually
means Java + Spring + a few other things that force you to separate concerns
(for the better imho, although it doesn't help with code navigation)

>>> The thing that has always let COBOL down for me is the lack of automated
testing.

True.

~~~
deong
I don't think most of those things are pluses for COBOL really, but if the
alternative was what the Enterprise Java world has been doing for the past 10
or 15 years, bring on the COBOL.

------
DonHopkins
There was this really great COBOL programmer back in the 1990's who was making
piles of money hand over fist, but was overworked and getting really tired of
working on Y2K fixes, and becoming extremely worried that civilization was
going to collapse due to Y2K bugs. She never wanted to look at another line of
COBOL ever again, she was so sick of it.

So she signed up with Alcor, and had herself cryonically frozen in 1999,
leaving behind explicit instructions that she was to be revived after
civilization had finally put itself back together again.

Finally she woke up, in a clean futuristic hospital room, surrounded by
inscrutable machines that go "ping" and strangely dressed doctors with funny
accents and weird hairdoos.

She was so happy to be alive that she proclaimed "Thank you so much for
bringing me back to life! I am eternally grateful, and in your debt! Is there
anything I can do to repay you? And by the way, what year is it?"

One of the doctors smiled at her and said, "Yes, actually. It's the year 9999,
and the records indicate that you're a COBOL programmer..."

~~~
YeGoblynQueenne
It's no joke. People are dragged out of retirement to maintain Cobol
codebases.

"Dragged" as in it rains money on them until they stop saying "no".

------
alexchro93
So, I graduated college this past June and have since started working as a
software engineer for a large financial institution. For now, I've been placed
on a team of developers where the majority of work is done on mainframes and
where most software is written in COBOL.

Today is the last of a 7 week-long "Mainframe Bootcamp" during which I've been
introduced to COBOL as well as TSO, JCL, DB2, CICS and MQ. Thus far, I'd say
the class has picked up the language fairly quickly, however we've yet to
fully grasp the intricacies of development using our company's heavily
customized mainframe tools. Generally mundane processes, such as compilation
and promotion between environments have been, IMO, rendered tantalizingly
complex. It's all really quite tedious and boring. IBM's documentation
monopoly hasn't helped, either.

To the point - I question whether COBOL's seemingly polarizing reputation can
be somewhat attributed to the environment in which it's usually
developed/deployed more-so than the semantic's of the language itself.

~~~
waltman
My experience with COBOL was on Stratus computers running the VOS operating
system. This was a better environment than mainframes, but I'm still
ambivalent about the language.

------
maxharris
I am bitter (see my other comment in this thread), but this is the first
article I've seen in years on COBOL that isn't just Micro Focus astroturfing.
+1 on that!

------
toolslive
I once had to port COBOL to Java. It presented some interesting problems
because of EBCDIC, nibbles, non IEEE arithmetic, and alien data formats. A
long story short: there are problems where COBOL is better suited than Java.

~~~
camiller
Were you also moving from a mainframe to a server? I would have thought that
Java on a mainframe would handle EBCDIC just fine, but I have never tried it.

~~~
toolslive
the 'mainframe' (a prehistoric Siemens BS2000) no longer really existed as
Siemens no longer gave hardware support. Instead, it was virtualised and
emulated on a desktop x86.

------
ibizaman
I worked for one of those companies using COBOL. This strikes me: > Once I
discovered what the problem was, the fix was easy: I deleted one character of
white space from the beginning of line 19, which put the period at column 72.
Although I'd never encountered it before, this was such a common bug that many
mainframe COBOL programmers would tape a piece of thread between columns 72
and 73 on their terminals. Why would you want a compiler/language that allows
you to shoot yourself in the foot for 1 misplaced character in the source
file, without raising an error instead of blindly executing the code? Like you
said, it can change completely the logic of the code so it could be disastrous
and go unseen, especially in business transactions? I know things changed
recently. But I would be very surprised if the company I worked updated their
COBOL version.

~~~
waltman
That 72-character limit came about because the most popular IBM punch card
reader at the time COBOL was being written could only read 72 of the 80
characters on a card. Once you know that anything after column 72 will be
ignored, you can repurpose those columns for other things. At my shop we used
them to denote revision numbers. And once practices like that get set, you're
pretty much stuck with the older formatting rules.

~~~
dodders
Yup. When I used RPG400 we'd use the first 4 columns for revision numbers as
they were originally reserved on the punched cards but not used on the
editor...

------
cm2187
One thing I don’t understand with these very old languages is that I thought
the reason they are still around is because of some programs written in the
70s to early 90s are still around and needs to be maintained.

But how complex can these programs be? Surely anything written before 1992-ish
can’t involve that much code just because of the limitation of the machines
they were designed to run on. What makes it that expensive that no one wants
to rewrite them in a modern language?

~~~
shakna
> But how complex can these programs be? Surely anything written before
> 1992-ish can’t involve that much code just because of the limitation of the
> machines they were designed to run on. What makes it that expensive that no
> one wants to rewrite them in a modern language?

You would be utterly shocked.

I did some COBOL work for a bank.

Most of the new code they write is in C++.

However, COBOL was still a huge part of their stack, and they still had
several heavy duty mainframes that it ran on, and maintaining that was part of
my job.

For an example of how much COBOL was written back then, and how huge the
technical debt to replace it would be:

* The interbank transfer system alone was ~750,000 lines of COBOL.

* It handled around 1.2million transactions every three seconds. That's not capacity, that's real world data.

* They had less than five minutes of downtime in the last twelve months, and that was considered poor.

It's a mammoth task to replace the system, and getting transactions from the
old to the new without incurring a huge overhead is nigh impossible. And yes,
dropped transactions can mean dropped customers, and big customers.

It's far cheaper to hire and train programmers in COBOL, than to rewrite
everything. COBOL and Fortran have millions of lines of code in use, and such
frequent use that replacing them may cost more than the lifetime of returns
would give.

~~~
fork1
Cobol programmers are starting to get few nowadays, and finding people that
actually want to be trained in it is not that easy. Plus you dont just need
programmers, but z/OS engineers, DB2 DBAs, MQ specialists, etc. And that's
before you even start talking about the nice cheque you're writing for IBM
every month. It does add up.

~~~
yourapostasy
Most if not all such _managers_ (I always look for explanations in these cases
that are not ascribed to an abstract business entity, but to individual
people) have no stomach for porting. A typical manager's tenure over an
organization that might have the scope to perform the port is shorter than the
porting project itself. No manager wants to have such a large, expensive,
risky project on their accomplishments list as "started, but not finished",
especially if a successor gets to claim all the credit later if it does finish
successfully: that successor then becomes direct competition on the corporate
ladder climb.

Also, I've yet to see such businesses opt for the safest porting approach.
Build a transaction replication system, then a component of the ported system.
Inbound transactions are replicated and dispatched to the legacy and the
component of the ported system simultaneously. Build scaffolding to monitor
key transaction metrics. Compare output and performance results. Let that
"bake" for a year or two. Rinse and repeat with the next component (many such
ported components can be developed in parallel, _etc._ ), and so on, until the
ported system reaches feature parity with the legacy system, then let the
completed version "burn in" for 2-3 of the longest periodic process
lifecycles. For example, if the the longest periodic process the application
supports is once every 7 years, then you burn in for up to 21 years, comparing
during the entire duration.

By the time you "throw the switch" to the ported system, you have a very high
certainty that it will work just as well if not better than the legacy system.
Extremely low-risk, but extremely expensive, and considered extremely
impractical. And with how business-critical some of these systems are, pretty
much any risk mitigation short of this will get nixed by senior management.

This doesn't even begin to get into other factors, like changing regulatory
and business environment as you are porting (so you're porting and modifying
for new requirements simultaneously), such a project can easily be targeted
for the cutting block for just the cost savings to make someone in Finance
look good, internal political issues, developer churn over such a long period,
developers on the legacy system withholding key implementation or even
business requirements information, that information simply not being
available, binary-only parts of legacy, _etc._

~~~
fork1
As i've made clear in my other posts in this thread, i dont believe in
rewrites. I've seen lots of very painful ones though, and never quite
finished, nor iso-functional. However, there are other ways to unplug the
mainframe.

I would disagree with the assessment that management is too dysfunctional, it
depends. But if they all were like you described, i would be out of work. And
it just happens that we turned off a mainframe just 2 weeks ago.

~~~
yourapostasy
How does your sales team address your customers' concerns that they are
trading one vendor lock-in (IBM) with another (your company's)?

From seeing how the risk is assessed in some of my customers, the kind of
emulation approach you described (I've seen one for the old HP 3000, and it
worked great) sells easily when the legacy vendor is so sclerotic and
rapacious that the customer's management is practically pushed out of the
relationship, and the economics don't have to completely pencil out to close
the sale.

The customer is tied down to a smaller (usually) vendor's emulation, and trust
the fidelity of that emulation over time, and furthermore, over new versions.
The customer must maintain a skill inventory that isn't "current" (though some
people might consider that a plus).

I can think of a couple ways to address those sales objections (lock-in isn't
real: can always switch back to legacy vendor if all else fails, no need to
revamp staff with crucial business/domain knowledge, _etc._ ). But I'd be
really interested in how your sales team deflects them, because I anticipate
this legacy software issue will only get worse in our industry over time, and
not just on mainframes. I'd like to try to figure out how to bring down the
friction of such sales in the future.

Thanks for your feedback, really appreciated.

------
wyldfire
I've tried it, so I can say authoritatively: no thank you. Yes, Admiral Hopper
should be revered for her work but we have successors now that are superior.

I'm happy not to work with JCL, COBOL, EBCDIC, and mainframes in general. I
realize just how much awesomeness in my OSs that I was taking for granted.

------
maxharris
Oh my God. I wasted a year of my life on a COBOL project. It is easily the
worst language I have _ever_ used. There is a reason that COBOL is a
linguistic dead-end! Functions? Sensible limited variable scope? A decent
approach to handling whitespace so that complex, nested branches make sense?
COBOL doesn't even have these basics.

Want to declare a variable? You're gonna have to type weird stuff like this:
`07 GreatVariableName PIC X(10).`

Oh yeah, and the compiler cost me $3k (great job, Micro Focus), on top of the
Solaris machine I had to buy to run it. (This project happened to use `mmap()`
via FFI, so it had to run on a Unix machine...)

Maybe I'm a bit bitter, but I will never touch another line of COBOL again.

~~~
djsumdog
The last time I touched it was in undergrad. I remember a professor in my
assembly class was showing us old punch cards. They were made with the fancier
machines where it printed the line of code on the bottom of the card. I look
at the lines in the stack and was like, "Wait, is this ... is this COBOL?"

I have to agree. Even back in 2001, I found COBOL awful. I recently moved to a
new city after having worked Scala jobs for several years. All I can find here
is Java work and I dread going back to the god awful word of Spring
Boot+MVN+Java after having worked with a considerably better language (usually
:-P).

We have better tools today, but the world is left in legacy. So few things
have unit/automated tests and without a good crew of engineers, it's very
difficult to move things quickly and smoothly to new systems and platforms.
Just because COBOL is still in use in so many systems doesn't make it good. It
just got popular at the right time, everyone embraced it, and now people who
still do it are paid insane amounts of money just to maintain it.

Here's one of my old COBOL programs from University. It was written 15 years
ago. I converted from CVS to Git, so the history dates are literally older
than github, which is kinda funny:

[https://github.com/sumdog/assignments/blob/master/csc3620-pr...](https://github.com/sumdog/assignments/blob/master/csc3620-program3/prog3.cob)

~~~
chris_wot
That’s actually quite readable

~~~
the_af
Readability is relative, of course. It's more readable than assembly language,
compared to which COBOL is a win (for its intended use, of course). Compared
to GW Basic (or any Basic with line numbers) it's probably about the same,
though more verbose. Compared to a modern language, it's less readable and
full of bizarre boilerplate.

The question is, if you are not forced by a customer (such as a bank) or by
the need to maintain a legacy system, why would you willingly choose COBOL?

~~~
chris_wot
Sure, if the money was right. I actually know a bit of COBOL, most of it
forgotten. After a while I would move on if they didn’t give me other
projects, but I’d even be willing to do it in parallel.

~~~
the_af
Not sure if I understand you. Isn't "if the money was right" another way of
saying "if forced by the customer/platform"? In other words, if the customer
told you "pick the language you want" and the platform wasn't a mainframe, why
would you choose COBOL?

~~~
chris_wot
Well, I wouldn't. The language has a lot of shortcomings. All I was saying was
that it was fairly readable.

------
oweiler
I've started my programming career in Cobol and it was nearly the reason I've
quit.

------
icebraining
I never tried it, but a friend of mine who wrote COBOL for a bank was offered
a huge bonus for postponing his retirement for a year, and he refused because
he was so sick of the language (he still likes programming, by the way).

So I don't hate COBOL, but I'm not particularly interested in trying it
either.

~~~
camiller
I got a nice stock offer to stay with a company doing COBOL for 3 years around
Y2K. Of course I took it. By the time the three years had elapsed the stock
price had more than doubled. I only eventually got out of COBOL because it was
boring.

Years later I was between gigs and interviewed with a company that wanted me
to go back to COBOL. I would have, but they lo-balled the salary, like I was
going to take a $20K pay cut to go back to COBOL! Ended up staying in the Java
world

------
oldandtired
There have been some very interesting comments made in these comments. Having
used COBOL to write communications and networking programs, I found the
version we used to be useful in the context of the work being done. I know of
people who so hate the language that you could offer them $1,000,000 an hour
to work on a project and they would refuse. Others would just as happily take
up the offer.

What I do find interesting is the attitude of some who classify COBOL as
ancient (etc) and have not yet realised that there are a number of major
modern languages that are the spiritual descendants of COBOL. These being ADA,
Java, C#, C++ and the rest of their ilk.

They each have a place to play in the computing world, but they each are the
wrong language for many purposes. Too oft I find, many programmers know one or
two languages and they are the worse off for that. Different languages give
different insights into specific problem domains. Every language allows some
things to be done easily and other things to be done hard.

Decades ago now, as CompSci undergraduates, we were expected to learn (or at
least use) every available language, from Fortran to COBOL, Algol 60 to Lisp,
assembler to Simula, Snobol to Pascal, Basic to Algol 68, etc., etc., etc.

These days, undergraduates seem to be taught one or two languages and that's
it. It shows up in their later inability to solve certain kinds of problems in
a problem space specific way.

------
magoghm
I had to program in COBOL for one year when I was in college (in the 70's), I
hated it. After that I had to program for one semester in IBM 360 assembly
language, which turned out to be a far more interesting and enjoyable
programming language.

------
flavio81
I give credit where it's due: In 1959 this was a breaktrough; made easy for
non-technical people to support business operations using code that was easy
to write, easy to understand, massively better than assembly in this regard.
Also, record definition and manipulation was an innovation in itself (in an
era without RDBMS), not to mention the builtin support for "accounting"
decimal arithmetic. It was really "Batteries-Included".

But programming evolved and Cobol did not evolve at the speed of the times. In
1968 (Cobol-68) it was already outdated compared to IBM PL/1 (a big monster of
a language, similar but much more powerful).

And in 2017, "Try COBOL"? You mean, try a language where I need to deal with
record access as if I were rolling my own DBMS system, with almost no module
support, and copious need for copy/paste of code at every file (little chance
of code reuse)? Where separation of concerns is almost zero?

No, i think writing in INTERCAL-72, Brainf_ck or LOLCODE would be more fun.

------
epx
Don't like COBOL but the way it specifies data formats was practical. 9(5) = 5
digits, X(20) = 20 characters, etc. From time to time I catch myself using
these while drafting a table or data structure.

~~~
msla
The way it specifies data formats encouraged TRUNCAT, or, for those of us who
speak English, truncation.

That gets to be a little old.

Sincerely, CHRISTOPHE (or, as I'm usually known, Christopher)

------
Mister_Snuggles
I've never written any COBOL, but I have debugged COBOL and determined the
source of errors by reading it.

My overall impression is that it's verbose (obviously), but it's also fairly
straight-forward and easy to read even if you don't know COBOL.

The most interesting part of it, for me anyway, are the 88-level
declarations[0]. Basically it's like a logic test encapsulated in a variable.
You can say something like "IF STAFF-MEMBER" where STAFF-MEMBER actually means
that some field has a certain value. It makes it easy to understand in some
respects, but also adds a layer of obfuscation.

[0]
[http://www.mainframestechhelp.com/tutorials/cobol/cobol-88-l...](http://www.mainframestechhelp.com/tutorials/cobol/cobol-88-level-
number.htm)

------
bitwize
I've tried COBOL; that's how I know I hate it.

------
erikb
I think COBOL is not a question of hate vs not hate. To hate something you
need to consider it, you need to have requirements. If nobody shares an
article like this one nobody is actually THINKING about COBOL. If someone
starts a new project COBOL is not on the list of possible programming
languages to implement it in. If you want to make it more popular don't fight
hate, fight ignorance.

But to be honest I'm one of these people who up till now doesn't even consider
it a choice. So don't expect too much support or understanding from my side.

~~~
the_af
> _If you want to make it more popular_

I don't think that's a desirable goal. COBOL is not a very good programming
language: it's verbose, clunky, cumbersome and outdated. It still exists
because of tons of legacy systems and (understandably) conservative businesses
like banks. But if you start a new project, please DON'T consider COBOL. To be
honest, even my recommendation is irrelevant: you wouldn't start a new COBOL
project just as you wouldn't start a new GW Basic project -- it'd be
unnatural.

Disclaimer: worked with COBOL for a bank. It wasn't pretty.

~~~
erikb
It was just an assumption, based on someone writing an article called "Don't
hate COBOL until you've tried it". As said, I personally wouldn't even
consider it, so there is zero chance to hate it as well.

~~~
the_af
Yes, it wasn't a criticism of your post! Just a clarification, namely, that I
think COBOL evangelism is misplaced, because you're either _forced_ to use it
by your customer (often, a bank or similar institution) or you are not, in
which case there are plenty of better, modern languages you should use
instead. In either case, you don't need someone convincing you to use COBOL.
If you're unaware of this language, you don't need it :)

------
shedside
I'm curious about something. Why this:

    
    
      if shipping-method <> 'FX'
          move normal-ship-date-yyyymmdd to expected-shipping-date
      else
          move nextday-ship-date-yyyymmdd to expected-shipping-date.
    

And not the following?

    
    
      if shipping-method = 'FX'
          move nextday-ship-date-yyyymmdd to expected-shipping-date
      else
          move normal-ship-date-yyyymmdd to expected-shipping-date.
    

The latter seems clearer to me, and the line below (regarding the cust-type
variable) suggests the syntax would be okay. It would also have the advantage
of avoiding the column-length issue described in the post. What am I missing
here?

~~~
HelloNurse
Probably taste: normal case first, special case last, regardless of what the
respective comparison clauses look like.

~~~
camiller
Also efficiency, you want the most often true thing first. Although it is more
important in nested if's. Had a colleague write a If else nested 104 levels
deep (pre COBOL II so no case structure available). We halved the run time of
the program simply by making the four most common conditions the first four.

------
GnarfGnarf
COBOL was a great improvement over Assembler. I once wrote a typesetting
program in COBOL.

You want horrible? Check out RPG (Report Program Generator).

~~~
52-6F-62
I looked. You weren't kidding.

[https://en.wikipedia.org/wiki/IBM_RPG#Example_code](https://en.wikipedia.org/wiki/IBM_RPG#Example_code)

------
zwerdlds
Not having worked with COBOL in about 10 years, the critiques I have of it
(from memory) are virtually identical to some modern languages I still have to
work with daily.

It's \- Too structured. \- Poor tooling. \- Whitespace sensitivity. \- No
first-class functions.

But the article is right - if these same standards were applied to today's
languages, things would be a lot louder.

------
DonHopkins
Is there a version of COBOL that support's FORTRAN's feature of changing the
value of a constant?

It would be so cool if you could go "ADD ONE TO FIVE".

[https://everything2.com/title/Changing+the+value+of+5+in+FOR...](https://everything2.com/title/Changing+the+value+of+5+in+FORTRAN)

~~~
Crespyl
That is a truly remarkable feature! Does it come with the ability to change
the definition of "constant"?

~~~
DonHopkins
I hate it when variables won't and constants aren't.

------
kazinator
Dates fixed in a YYYYMMDD representation. Seems like very ad-hoc
representation. If you need "sixty days before such and such a date", ouch.

Shipping price conforms to a "pic 99v99". So what happens if a really big
shipment needs to be made for which $100.47 needs to be charged?

~~~
waltman
When I wrote the article I didn't have access to code I worked on 2 decades
ago, and if I did I couldn't have used it in the article anyway. This was
indented to illustrate the problem with problem with column 73, not to handle
all possible cases.

Having said that, situations like would come up sometimes. You really did have
to decide ahead of time how big field could be. You could leave extra filler
bytes in your tables (literally named "filler") but it was still a big hassle
to deal with.

------
kwhitefoot
> 5 billion lines of new COBOL code are written every year.

Are you sure about that? Sounds like rather a lot.

~~~
dcminter
It doesn't sound too off to me - I can believe that there are a million legacy
COBOL users around and that each writes on average a thousand lines of
maintenance code each year. Or maybe fewer users and more lines - COBOL is a
notoriously verbose language.

~~~
waltman
I'm the author of the article, and I linked to the source of those numbers.
The numbers seem reasonable to me too for the same reasons dcminter gave. One
other reason is COBOL is a language that lends itself to copying and pasting
old code instead of writing subroutines, so that leads to a lot of lines of
code.

------
Bromskloss
What about money? Is there great money in learning COBOL? I mean, I could do
that, I suppose.

------
Illniyar
I could try it and then hate it, but that seems like a bit of waste of time.

~~~
igotskills
try

    
    
       display "am I having fun yet?"
    

catch e as type Exception

    
    
       display e::Message
    

end-try

------
wglb
I didn’t like it until I had to program a system 34 in RPG III. Certainly
better. When I left the 34, I didn’t like cobol all over again. I could go on
at length but I won’t.

------
mannykannot
My impression was that COBOL has only a global data space, and that there is
no way to write functions - rather like the original BASIC?

~~~
tolle
One way of solving it would be to just put the code you would otherwise put
into a function into another application and call that. Not super pretty, but
it works. It's preferable over ending up with a massive program with hundreds
of sections.

------
CyberDildonics
Shouldn't it be possible to convert COBOL to C C++ LLVM IR or even WebASM?

~~~
waltman
It’s certainly possible; after all, the GnuCOBOL compiler is written in C. A
large part of every COBOL program tends to be simple move and arithmetic
statements that seem like they should be easy to port. The difficulty comes
with the data declarations. COBOL’s pic statements don’t just define length
and whether or not they’re numeric. They also come with complex behaviors that
are enforced at run time. For example, anything that’s a pic 9 is stored as a
sequence of 0-padded text digits, but you can also do arithmetic on them. They
work like a car odometer in that if you add 1 to a variable that’s all 9’s,
the result is all 0’s. They also allow you to do arithmetic on currency
amounts (like I do in the article) exactly, without having to worry about IEEE
floating point round off errors. That’s another reason the banking industry
likes COBOL.

~~~
CyberDildonics
Wouldn't that just mean using functions to have the same results?

~~~
waltman
Sure. My point was just that it's more difficult than it seems. Also this
would mean that lines like

add x to y giving z

become something like

cobol_add_giving(&a, &b, &c);

which is a lot less readable.

------
santoshalper
Try it first, then hate it.

------
moonbug22
It's surprisingly well adapted to web development too

[http://www.coboloncogs.org/](http://www.coboloncogs.org/)

~~~
kagamine
If you have an existing COBOL app you can convert it to a web app and develop
using a simpler syntax with more features through SystemZ from Zortec Intl.
I've worked with them personally and they were super-duper.

COBOL isn't so bad when you use a modern variant that purposefully deals with
many of the complaints surrounding it.

~~~
moonbug22
Yes, thanks for missing the joke.

~~~
kagamine
No problem and glad to be of [di]service. I was familiar with the URL you
posted, and probably should not have commented as a reply to you, but there
you have it. :)

