
The problem might not be COBOL - earthboundkid
https://adhoc.team/2020/07/10/problem-might-not-be-cobol/
======
Zenst
One of the real gotchas in old systems is the data limits. So systems working
fine, all working with say a name field that's locked in at 40 characters as
that when original designed was enough and storage wasn't cheap then. Or a
comments field, 250 characters felt generous back then, today - that's the
first sentence just about.

So you get old fine working do the job systems, then you get what I call bolt-
ons to those systems, web front-end and the like that all distill the input
into a format the old working system can take in. Which is fine, but the data
limits of the back-end really do start to stand out more and more then and
seen many a case of a front-end allowing more input only for it to get blindly
truncated before it is fed into the backend. Things like that can and do
create interesting issues. Though as true today as it was back when COBOL was
born - garbage in garbage out.

~~~
kqr
Isn't that a matter of abstraction? We have to consider the old backend a type
of "virtual machine" with a domain-specific instruction set. Of course, this
is a rather funny virtual machine with some odd technical limitations, but
it's not infeasible to consider writing a new back-end (middle end?
middle...ware?) that targets the old funny backend but abstracts over its
limitations e.g. by using two records to get additional name storage.

Depending on how complicated the business logic rules encoded in the old
backend are, could this be more efficient than modifying the old backend?

~~~
Zenst
Generally and for many things, augmenting the existing backend is the best way
over a rewrite which would take more than 5 years for many systems and with
that, get shot down by accountants and management bureaucracy. As for the VM
analogy, hmmmm from a data perspective, maybe.

But it all boils down to how the old system stores data, and some will enable
you to hold multiple records and for example a comments field. May have the
last character closed of from input as it is a continuation marker that means
there is another record and they are joined, as you say two records. Changes
like that will entail changes to the backend, though the impact can be more
manageable than alternatives.

Then you can use replication or data warehousing and from that, lots of
reports and other aspects that would hammer the backend become much more
pleasant.

Crux is the limitations, things like names, so entwined into a system that it
does not lend itself to the two records solution. So you use another solution.

You mention business rules and that is very much key and having somebody who
knows the business logic is way more valuable to understanding the a system
than knowing the language it is written in. So as an aside, if I had to employ
somebody to work on an old legacy system, I'd take the person who knew or
showed a grasp of the business logic and how that works over somebody who knew
COBOL. As it is easier to teach COBOL than an entire business. COBOL has many
books and resources, a business tends not to have such clear cut
documentation.

------
RcouF1uZ4gsC
> News flash: the C programming language is the most popular language in the
> world and it’s nearly as old as COBOL. SQL is the backbone of database
> programming, and it was invented in the 1970s. The age of a technology is no
> indicator of its viability or appropriateness for solving mission-critical
> problems.

The big issue with COBOL is developer availability. I can easily find a lot of
C programmers to fix and extend my complicated C code base. I can easily find
a lot of programmers familiar with SQL to help me fix and improve or change my
queries. Finding COBOL programmers is a much harder task and C and SQL
programmers.

And it is not about the age of the programming language. My guess is that it
would be harder finding PL/1 or Algol 60 programmers even though both of those
languages are newer than COBOL.

~~~
riquito
Train them. We do it all the time with new hires or old pals for any
mainstream or not language. I saw teams do marvels in a quarter in completely
new languages, no matter how far the paradigm. Not claiming COBOL is easy (no
idea) but can't be an impossible task. Is probably harder to keep people
engaged

~~~
smt88
From what I understand talking to someone who gets paid enormous amounts of
money to occasionally update COBOL systems in heavy industry, working on COBOL
is drudgery.

It might be difficult to find a substantial number of people who actually
_want_ to be trained in COBOL.

~~~
quantified
There are a lot of developers who would like to be paid enormous amounts of
money. I wonder if the public sector pays well enough to generate the desire
to learn, though.

I myself can handle a lot of drudgery for $350k a year.

~~~
agdtdudhegsjhs
100% the money is the issue.

------
sdfhininio
I don't think this article is fair. It is certainly the case that badmouthing
COBOL for its age would be irrational, but I don't think that's what anyone is
actually saying. People wouldn't react the same way in the system were written
in C or LISP. COBOL has a reputation for being clunky and inexpressive and
primitive for reasons other than its age.

Perhaps some popular articles dismissed COBOL for its age. No programmer worth
their salt would do so.

(I can't say whether or not COBOL deserves its reputation, and given how many
reliable systems are written in COBOL I doubt it is fair to blame it for the
failures of this website.)

~~~
jhallenworld
A traditional criticism of COBOL is that it's wordy, but with modern editors,
probably not such a big deal.

The one really crazy COBOLism is "Alter":

[https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/...](https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlpsalte.htm)

But all languages have parts which are not recommended to use.. just think of
PHP.

~~~
DrScump
In the COBOL shop I worked at in the 80s, GOTOs existed in some legacy code,
but ALTER was avoided like the plague.

------
kevml
> The problem is often that they’re using code that wasn’t designed to meet
> the needs of people who use it.

There is an important word left out here. It wasn’t designed to meet the needs
of people who currently need it.

------
Spooky23
100% agree. The problems with these systems are usually the crap built around
them. The IBM, Univac, Grumman, etc or state people who built this stuff 40
years ago knew their stuff. The operational processes are mature and don’t
break.

Usually in a government agency is a layer of VB, J2EE from circa 2003,
powerbuilder or some other array of old junk that is responsible for some
business processes and is a make work program for hundreds of developers. That
is the problem.

Whatever CIO is whining to the governor about COBOL need to be gone, now, and
New Jersey needs to find somebody who can get the stuff around the COBOL
reengineered and implemented quickly. Then start hacking the COBOL bits apart.

------
mxcrossb
I don’t really understand this article. When the New Jersey government came
out asking for Cobol programmers, all I remember was them talking about the
strain on their system due to a demand spike. But this article spends its
whole time talking about the UI? Unless I’m missing some context, this reads
more like an ad.

~~~
eru
The article links to [https://www.wired.com/story/cant-file-unemployment-dont-
blam...](https://www.wired.com/story/cant-file-unemployment-dont-blame-cobol/)
which has more background.

~~~
mxcrossb
This is the same info as I was aware of. The problem was crashing servers. But
my complaint is that this article instead spends a lot of time complaining
about the input forms

~~~
eru
Yes. As so often, the link for background information actually is the better
text than the article under discussion.

------
sradman
The problem might not be bad web form UX either. The general problem is one of
a new code change requirement in a legacy system. Perhaps we should think
about creating an On-Boarding document for new developers before dismantling
the original development team, ready to bootstrap a new development team. It
could be part of the regular business continuity plans that many companies
actively maintain.

This has the feel of a corollary to Fred Brook’s _The Mythical Man-Month_ ;
_The Mythical Effective New Man After Many Inactive Months_.

------
westDev12
Interviewed at adHoc and while it's good they are fighting for pay parity and
equality ... it was a turn off that not any one person could not negotiate
their own worth.

Negotiation your salary I guess is something learned and those who work at
this company are fairly new in their careers(i think). Personally, I am not,
so and again I applaud this company's mission of equality and pay parity. Yet
for someone seasoned it led to find other places to work.. places where
negotiating ones worth is allowed.

------
peacefulhat
What really pissed me off about this whole fiasco was when Ted Lieu chimed in
to say he wish he learned COBOL instead of Lisp:
[https://twitter.com/tedlieu/status/1246651654373437442](https://twitter.com/tedlieu/status/1246651654373437442)

Also this poor explainer video that conflates several unrelated design
decisions with limitations of COBOL:
[https://youtu.be/Ox_Wm6XQnxI](https://youtu.be/Ox_Wm6XQnxI)

~~~
hawkice
There's something fascinating about a politician calling a bunch of people
stupid for no reason. Like, he admits he's not good at coding, it's not like
I'd take his word on tech decisions. This whole thing is so weird. You'd
imagine he'd either have good taste, or try and pander to the most people.
He's taken a third path, which I can't really place.

------
dwd
None of this really seems to be just COBOL's fault.

COBOL is a compiled language, so once compiled into machine language it
doesn't matter as long as it runs.

I would be looking more at what hardware its on which is probably some Big
Iron running system/360 that has a 2 week turnaround to add some extra memory.
The code probably runs just fine, it's the hardware support cost and
turnaround time that will be the constraint.

------
jlnthws
So, COBOL is lindy. Not because it's more efficient but because a complete
rewrite is still more expensive and risky. Though I hear now and then that
parts of those systems are being rewritten gradually (usually in C# as COBOL
runs on the .NET framework). It's just a matter of time.

------
eru
All around sensible, though I guess nothing that would deter the people who
sneer at Cobol on Twitter?

