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

31–39 of 39 posts

Re: A Historical Perspective on COBOL (2020)

#31

Post by ASalazarMX »

DoomHotel wrote: post #23
denton-scratch wrote: post #21

COBOL was my first professional programming language. We wrote the code with a pencil, on coding sheets. The team leader checked it, and once it was deemed OK, we could type it in on a terminal. It was a horrible language. The article speaks of code that "reads like a novel"; I swear I never read COBOL code that was easy to read. The problem was that COBOL doesn't lend itself to expressing structure. Combined with th…

IBM mainframes also do/did hardware BCD arithmetic, starting with System/360. And as for COBOL not lending itself to structure, how did Structured COBOL exist, then? I wrote lots of COBOL without a single GO TO anywhere in the code.

I'd wager the version of COBOL GP used was older. I learned COBOL in the 90s on a personal PC, and it allowed structured programs then. No spaghetti code needed, just PERFORMs and strategically placed periods. Even a program with GOTOs could be made be structured.

Re: A Historical Perspective on COBOL (2020)

#32

Post by ASalazarMX »

DoomHotel wrote: post #24
le-mark wrote: post #4

Earlier quoted context omitted.

> 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 logic" of the applications. I would add that in the era cobol was designed and rose to prominence, assembler was used for both. Cobol enshrined the application assembler pract…

We used PERFORM to implement calls. Whether or not implemented with a stack, it acts the same as any call/return. So to implement a simple loop to count records in a file: PERFORM COUNT-ROWS VARYING COUNT FROM 1 BY 1 UNTIL EOF. And the callee did: READ INPUT-FILE AT END MOVE 1 TO EOF-FLAG.

Ah, the joys of forgetting to put a period at the end of the COUNT-ROWS paragraph.

Re: A Historical Perspective on COBOL (2020)

#33

Post by AnimalMuppet »

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…

Let me guess: You're a professional programmer.

I am, too. I (and, I assume, other professional programmers) want sharply-defined primitives/keywords/operators. Vagueness really gets in our way. And the problem is that English words don't have the kind of precise definitions that we need.

But COBOL wasn't built for us. The design goal of COBOL was to make professional programmers obsolete - to make it so anyone could program. (Epic fail on that design goal - COBOL was once the most common language used by professional programmers.) For the intended users, the "using ordinary words" was a feature, not a bug. But the actual users and the intended users are different people, and the English-like syntax doesn't work for the actual users.

Re: A Historical Perspective on COBOL (2020)

#34

Post by DoomHotel »

ASalazarMX wrote: post #31
DoomHotel wrote: post #23

Earlier quoted context omitted.

IBM mainframes also do/did hardware BCD arithmetic, starting with System/360. And as for COBOL not lending itself to structure, how did Structured COBOL exist, then? I wrote lots of COBOL without a single GO TO anywhere in the code.

I'd wager the version of COBOL GP used was older. I learned COBOL in the 90s on a personal PC, and it allowed structured programs then. No spaghetti code needed, just PERFORMs and strategically placed periods. Even a program with GOTOs could be made be structured.

I learned structured programming using COBOL in the 1970s on a Xerox Sigma 6 and went on to use it on Burroughs Medium Systems (B3500/B4800).

Re: A Historical Perspective on COBOL (2020)

#35

Post by vincent-manis »

zozbot234 wrote: post #3

The article broadly claims that COBOL is viewed dismissively compared to other languages of similar vintage like C or FORTRAN, because unlike those latter it did not come out of a "research-oriented context". However, as a matter of fact, neither C nor FORTRAN came out of academia; much like COBOL, they were developed for practical use as opposed to "research". ISTM that the perceived issues with COBOL must be explai…

The Bell Labs of the 1960s/70s was not a research institution???

Re: A Historical Perspective on COBOL (2020)

#36

Post by DoomHotel »

ASalazarMX wrote: post #32
DoomHotel wrote: post #24

Earlier quoted context omitted.

We used PERFORM to implement calls. Whether or not implemented with a stack, it acts the same as any call/return. So to implement a simple loop to count records in a file: PERFORM COUNT-ROWS VARYING COUNT FROM 1 BY 1 UNTIL EOF. And the callee did: READ INPUT-FILE AT END MOVE 1 TO EOF-FLAG.

Ah, the joys of forgetting to put a period at the end of the COUNT-ROWS paragraph.

We had some coding rules to help prevent that:

1. No unnecessary periods in the code

2. Required periods (ending paragraphs and if/then/else) go on a line by themselves

Re: A Historical Perspective on COBOL (2020)

#37

Post by pjmlp »

Zababa wrote: post #30
PedroBatista wrote: post #14

Earlier quoted context omitted.

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.

> The "best" we have to offer today as "pure" business logic programing is some BPMN framework/platform.. and that is mostly hell of Earth.. Do cloud plateforms fall under BPMN frameworks/plateforms? From what I understand, it's possible to build applications today using cloud plateforms (AWS and Azure mostly, I don't know about the others) for auth, persistance, etc; while only writing your business logic, especiall…

For me the "cloud" just feels like back to UNIX proper days, just that instead of using telnet on a green phosphor terminal or an IBM X Windows terminal, I use the browser alongside a cloud shell.

Re: A Historical Perspective on COBOL (2020)

#38

Post by pjmlp »

anthk wrote: post #19
pjmlp wrote: post #9

Earlier quoted context omitted.

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?

Not much, I have read a few articles about it, but never cared much to dive into it.

Other than it was probably great having an OS where LISP had the spotlight alongside Assembly.

Re: A Historical Perspective on COBOL (2020)

#39

Post by denton-scratch »

ASalazarMX wrote: post #31
DoomHotel wrote: post #23

Earlier quoted context omitted.

IBM mainframes also do/did hardware BCD arithmetic, starting with System/360. And as for COBOL not lending itself to structure, how did Structured COBOL exist, then? I wrote lots of COBOL without a single GO TO anywhere in the code.

I'd wager the version of COBOL GP used was older. I learned COBOL in the 90s on a personal PC, and it allowed structured programs then. No spaghetti code needed, just PERFORMs and strategically placed periods. Even a program with GOTOs could be made be structured.

Well, what I was using was called Burroughs COBOL. I was using it on minicomputers, but it was basically the same COBOL that ran on the big Burroughs mainframes. Mainframes needed to maintain backward compatibility, so I guess the COBOL I was using was 1st-generation.

I gave up COBOL before I ever encountered any Structured COBOL. Around that time I performed psychological repression of all memory I had of the language, or even that I'd used it.

It has taken years of programming-language therapy for me to start to recover these memories.

Post reply on HN