Why COBOL Isn't the Problem • Hacker News Board

Re: Why COBOL Isn't the Problem

#41

Post by hypermachine » Wed, Mar 17, 2021, 4:48 PM UTC

> Programming languages are easy to learn

From our experience with VBA users, this is only true for non-technical (as in STEM background) users when it comes to languages with a close-to-English syntax together with tightly integrated IDE/editor. Lua, Python (and occasionally Ruby) are two other languages that are quite "easy" to learn. The curly braces languages? Not so much. Java is especially bad due to its poor error messages and opaque package management/build tools. However being easy to learn for the users doesn't mean the users are capable of writing good code. We found that code written by amateur users tend to be rather unstructured and incoherent. On the other hand some of the cleanest codebases I have read (from those without formal instruction or experience in software engineering) are by mathematicians and electrical engineers.

In terms of tooling Glitch.com and Repl.it are best in for zero-config workflows.

Re: Why COBOL Isn't the Problem

#42

Post by fouric » Wed, Mar 17, 2021, 4:57 PM UTC

> programming languages are really easy to learn

> For evidence of how easy it is to learn programming languages, one of the authors of the current paper has, over the course of his life, learned 18 distinct programming languages. His father, a physics professor, claims to have used 20 and 30 programming languages. A quick poll of engineers at Lucid Software showed that this was not unique, with all of the engineers having used at least two programming languages, and the majority having used somewhere between 5 to 20.

I'm curious as to how different the languages that they're referring to are.

Python, Ruby, Perl, PHP, C, C++, D, and Java are all really similar to each other relative to the differences between them and Coq, Haskell, Lisp, Erlang, Prolog, Io, Spiral, FORTH, or Chapel.

Re: Why COBOL Isn't the Problem

#43

Post by maxharris » Wed, Mar 17, 2021, 5:32 PM UTC

dwheeler wrote: post #32

The article gets it: the problem isn't COBOL, the problem is lack of maintenance. The analogy is apt, too: if you never put oil in a car & it fails, the problem is not how the car the built. There are materials for learning COBOL. Here are some materials from the Linux Foundation's Open Mainframe project: https://www.openmainframeproject.org/projects/coboltrainingc... And when there was a call last year for COBOL pro…

> if you never put oil in a car & it fails, the problem is not how the car the built

No, the analogy is perfectly apt. Electric vehicles are rapidly replacing gasoline vehicles. There is no oil to change in an electric car! Better languages have long since surpassed COBOL.

Re: Why COBOL Isn't the Problem

#44

Post by ravi-delia » Wed, Mar 17, 2021, 5:35 PM UTC

fouric wrote: post #42

> programming languages are really easy to learn > For evidence of how easy it is to learn programming languages, one of the authors of the current paper has, over the course of his life, learned 18 distinct programming languages. His father, a physics professor, claims to have used 20 and 30 programming languages. A quick poll of engineers at Lucid Software showed that this was not unique, with all of the engineers…

I mean, the similarities between languages are a big part of why they're easy to learn. Obviously if you only learn within one cluster, you operate best in that cluster, but one or two archetypical languages in each are probably enough to use any of them.

   |Functional|Prodedural

Strict | Haskell, F# | Rust, Java, C

Loose | Elixir, Lisp? | Ruby, Python

No idea if that rendered right at all, such is life. Seems like Lisp-esq languages are kind of a category on their own, but what's an oversimplified taxonomy without some really forced placements?

Re: Why COBOL Isn't the Problem

#45

Post by kimi » Wed, Mar 17, 2021, 5:49 PM UTC

opsunit wrote: post #31

wtetzner wrote: post #24

Earlier quoted context omitted.

> COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. I wonder how different it would be if they had a good source control system (and used it). Would you be able to look at the history and understand why the changes were made, or would you just get a bunch of commit messages like "made update" or "reverted earlier change"?

Having worked on the PL/1 and Assembler that formed the core accounting systems of a bank: yes. Not only did I have source control I had flow diagrams of the entire system for all points in the chain. My code reviews had me doing line-by-line justifications. I wrote tests. Just because the technology and practitioners are old it doesn't mean they don't know what they're doing. Generally they invented whatever "you" a…

COBOL was used for more mundane tasks - a lot of data loading, formatting, batches of all kinds. Not all of which seemed so important when they were written, but that ended up being a plug nobody wants to take the risk of disconnecting.....

Re: Why COBOL Isn't the Problem

#46

Post by [deleted] » Wed, Mar 17, 2021, 5:56 PM UTC

brogrammernot wrote: post #21

My father has been working in COBOL since the 80s, and his “reference” books are literally a couple of 4” 3 ring binders that he’s assembled over 40 years now of coding. Everytime the bank tries to switch away from COBOL they run into problems ranging from code latency to lack of support for certain features in the new language among other issues thus far. I really don’t know what the banks that run cobol mainframes…

[deleted]

Re: Why COBOL Isn't the Problem

#47

Post by crb002 » Wed, Mar 17, 2021, 6:16 PM UTC

Version control is COBOL's problem. Testing mainframe COBOL not in a modern version control is YOLO PITA.

Re: Why COBOL Isn't the Problem

#48

Post by Annatar » Wed, Mar 17, 2021, 6:41 PM UTC

goatinaboat wrote: post #19

Annatar wrote: post #7

To COBOL's defence, the compiler generates very fast machine code, so COBOL is all right in my book id est screwing around with the intricacies of that language is okay since the end result is a fast, small program. Based on these two criteria, I conclude that it's well worth the effort on the programmer's part.

it's well worth the effort on the programmer's part It's worth it if you have all the supporting pieces in place. For example if your OS provides record-oriented I/O and your hardware platform provides dedicated processors for accelerating I/O, then you can write a very small, efficient program to, say, calculate today's interest rate and apply it to millions of accounts. But if you don't have those things then you n…

COBOL I learned on ran under MS-DOS, which does not have record oriented I/O, and it was fast. Very fast.

Re: Why COBOL Isn't the Problem

#49

Post by 908B64B197 » Wed, Mar 17, 2021, 6:54 PM UTC

kimi wrote: post #17

There are a few things that the author forgot: - COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. - COBOL programs do what they do. They do not have specs, but if that's the way we have been computing account interests for the last 50 years, they are right. It's lawyers documenting them, not the other way around. - COBOL…

> COBOL programs do what they do. They do not have specs

And nothing around them is standard either. No database, no best practices, no comments in code. Combined with

> OBOL programmers were often meant to be "less" than real programmers.

you get programs that are completely unmaintainable. Contrast this with the first versions of UNIX or BSD (written around the same time) and you can still build and understand them pretty easily. That's the difference between programmers and software engineers.

> This said, the kind of things you could do on a IBM mainframe in the '70s (virtualization, data safety and efficiency, disaster recovery, even uptime) still run rings around the 90-core boxes with Linux that are in your datacenter racks.

All through obscure, proprietary APIs and along with a hefty support contract from IBM. Making sure nobody in academia or in SV could get within 500m of a mainframe sure helped them become more than a niche.

Re: Why COBOL Isn't the Problem

#50

Post by Pet_Ant » Wed, Mar 17, 2021, 6:58 PM UTC

watertom wrote: post #23

The problem is maintenance, it's a cost center, it doesn't directly generate revenue, so it's been eliminated. NOBODY is willing to spend money for maintenance on ANYTHING, look at our infrastructure. If it wasn't for the FAA making it illegal to not maintain planes, we'd be seeing the same thing with airlines and their planes. We are seeing this with the Air Force right now, where they are now trying to reverse engi…

> The problem is maintenance, it's a cost center, it doesn't directly generate revenue, so it's been eliminated.

It does (effectively), the problem is that it is on a long enough time span that the dividends don't appear until long after the decision makers are all long gone. Executives need to be compensated with annuities depending on the future performance of the company to disincentivise slash & burn profit farming.