Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Historical Perspective on COBOL (2020)

logicmag.io

Post reply on HN
Print view View original

11–20 of 39 posts

Re: A Historical Perspective on COBOL (2020)

#11

Post by bigbillheck »

js8 wrote: post #2

(I work in mainframes, but not directly COBOL.) COBOL could certainly be done better today, but its strength comes from the fact that it limits what programmers can do with it. In the past, there was a divide between systems and application programmers. Roughly, the systems programmers took care about the details of the infrastructure and resource access, while the application programmers worried about the "business…

If that divide was ever absent, it wasn't absent for long. 'Application programmers' had BASIC in the 80s, Visual BASIC (and delphi hypercard and tcl/tk) in the 90s, then the 00s hit and with it ruby and python and the biggest application language of them all, javascript.

Re: A Historical Perspective on COBOL (2020)

#12

Post by veltas »

Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder. A programming language with simple and more orthogonal syntax like C is much easier to learn and reason about, than a language where you learn so many different verbs/constructs like COBOL or Ada.

And I think that -- depending on the problem -- you want a more succinct language to express the problem in. Maths is a good example: maths would be far harder if we described everything in plain English without ever resorting to symbolic maths. Formulaic maths allows us to focus more on the structure and meaning rather than the encoding.

Re: A Historical Perspective on COBOL (2020)

#13

Post by hyperman1 »

mech422 wrote: post #8
hyperman1 wrote: post #5

This article's opinion of COBOL is too positive, even if I agree that COBOL is sometimes treated too harsh. The failings of COBOL are the failings of slow, bureaucratic entities. It works, but needs constant manual handholding to keep it on the rails. It assumes plenty of butts in seats with plenty of time. It assumes nobody complains if results are a week late and the first version is wrong. It assumes end users wil…

I haven't written cobol since late 90s-early 2k... But my experiences were just the opposite. If you need to write accounting software, COBOL is a pretty painless way to do it. Add in something like automatic copybooks from DDL in file metadata (like the OS/400 supported) and it was great never having to worry about people forgetting to update record layouts. the result was you could knock out your typical accounting…

Lets chalk it up to different corporate cultures then. Copybooks around here have so much redefines that the smallest mistake causes data corruption. Also, theres not a week going by without someone running out of numbers.

Re: A Historical Perspective on COBOL (2020)

#14

Post by PedroBatista »

pjmlp wrote: post #7
js8 wrote: post #2

(I work in mainframes, but not directly COBOL.) COBOL could certainly be done better today, but its strength comes from the fact that it limits what programmers can do with it. In the past, there was a divide between systems and application programmers. Roughly, the systems programmers took care about the details of the infrastructure and resource access, while the application programmers worried about the "business…

Actually I think this divide still exists, just at another level. For example when I write Java code, I don't care if the VM is implemented in C, C++, Assembly, hardware or whatever. Just like when I upload the jar file into a cloud instance app engine, usually I don't care if the JVM is running on top of some OS, bare metal or whatever it making it run. Yet, there is a group of developers that is making that illusio…

But you have to care about FileInputStreams, bytes and CompletableFutures.

The "best" we have to offer today as "pure" business logic programing is some BPMN framework/platform.. and that is mostly hell of Earth..

COBOL is not coming back because that time has passed, however something with the basic essence and principals of COBOL is desperately needed. Don't ask me what and how because I don't know either.

Re: A Historical Perspective on COBOL (2020)

#15

Post by pjmlp »

PedroBatista wrote: post #14
pjmlp wrote: post #7

Earlier quoted context omitted.

Actually I think this divide still exists, just at another level. For example when I write Java code, I don't care if the VM is implemented in C, C++, Assembly, hardware or whatever. Just like when I upload the jar file into a cloud instance app engine, usually I don't care if the JVM is running on top of some OS, bare metal or whatever it making it run. Yet, there is a group of developers that is making that illusio…

But you have to care about FileInputStreams, bytes and CompletableFutures. The "best" we have to offer today as "pure" business logic programing is some BPMN framework/platform.. and that is mostly hell of Earth.. COBOL is not coming back because that time has passed, however something with the basic essence and principals of COBOL is desperately needed. Don't ask me what and how because I don't know either.

Depends, in the context of COBOL that would be some ORM library.

Re: A Historical Perspective on COBOL (2020)

#16

Post by YeGoblynQueenne »

>> A global pandemic in which more people than ever before are applying for unemployment is a situation that COBOL systems were never designed to handle, because a global catastrophe on this scale was never supposed to happen. And yet, even in the midst of this crisis, COBOL systems didn’t actually break down. Although New Jersey’s governor issued his desperate plea for COBOL programmers, later investigations revealed that it was the website through which people filed claims, written in the comparatively much newer programming language Java, that was responsible for the errors, breakdowns, and slowdowns. The backend system that processed those claims—the one written in COBOL—hadn’t been to blame at all.

One can bet good money on the expectation that the mainframes will be the last component of a system to crash and burn. Though to be fair that's not to do with COBOL, per se, it's just that mainframes are rock solid.

Re: A Historical Perspective on COBOL (2020)

#17

Post by hosh »

I remember growing up in the 80s and picking up disdain for COBOL because it was verbose. But then,

1. I recently found out that COBOL can calculate numerics to a degree of precision greater than most languages and libraries. It was a PITA to do monetary calculations right and it is built into the core of COBOL.

2. Reading the sample COBOL code, I realized though I can’t scan it fast, it is structured in a way that is not much different than reading or writing SQL.

3. Having written Ruby for 10 years, and spending a lot of time with DSLs and business domain languages, the aims of COBOL is really not that much different.

4. Having taken the long path through learning the design philosophy of Smalltalk, Christopher Alexander, sandstorm.io, Free Software, as well as my evolving thoughts on “regenerative technologies”, I am coming to the conclusion that it is important for end users to be able modify their computing environment for use in their local community. As such, COBOL may be a good case study for designing pattern languages.

Re: A Historical Perspective on COBOL (2020)

#18

Post by hosh »

veltas wrote: post #12

Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder. A programming language with simple and more orthogonal syntax like C is much easier to learn and reason about, than a language where you learn so many different verbs/constructs like COBOL or Ada. And I think that -- depending on the problem -- you wan…

What do you think about SQL?

Re: A Historical Perspective on COBOL (2020)

#19

Post by anthk »

pjmlp wrote: post #9
js8 wrote: post #6

Earlier quoted context omitted.

C has roots of its usage in academia, the same way Unix does. I suspect, compared to other OSes of the era (Multics, MVS..), Unix doesn't require too much centralized control of (timeshared) operating system resources; for example the security model is extremely simple. So it was readily adopted in academia, because of this perceived user freedom (you just need a shell and you're good to go), and from there it spread…

Academia was crucial in the adoption of UNIX and C, because in the early days UNIX was free beer (AT&T tried to fix that afterwards), so a juicy alternative to paying for Multics, MVS... That also made UNIX an ideal teaching device for OS programming classes versus the toy OSes developed by students. Well, until AT&T forbade the circulation of UNIX V6 commented book. https://en.wikipedia.org/wiki/Lions%27_Commentary_…

What's your opinion on ITS?

Re: A Historical Perspective on COBOL (2020)

#20

Post by kps »

veltas wrote: post #12

Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder. A programming language with simple and more orthogonal syntax like C is much easier to learn and reason about, than a language where you learn so many different verbs/constructs like COBOL or Ada. And I think that -- depending on the problem -- you wan…

> Article acts like having a 'richer' language approximating English makes it easier or more approachable, but whenever I've tried such languages I've found them harder.

You're not the target audience. Grace Hopper explained it:

“I used to be a mathematics professor. At that time I found there were a certain number of students who could not learn mathematics. I then was charged with the job of making it easy for businessmen to use our computers. I found it was not a question of whether they could learn mathematics or not, but whether they would. […] They said, ‘Throw those symbols out — I do not know what they mean, I have not time to learn symbols.’ I suggest a reply to those who would like data processing people to use mathematical symbols that they make the first attempt to teach those symbols to vice-presidents or a colonel or admiral. I assure you that I tried it.”

The goal was to give senior management the illusion of understanding what their hirelings were doing.

Post reply on HN