[HN Gopher] A Historical Perspective on COBOL (2020)
___________________________________________________________________
A Historical Perspective on COBOL (2020)
Author : omrjml
Score : 58 points
Date : 2021-05-05 10:53 UTC (2 days ago)
(HTM) web link (logicmag.io)
(TXT) w3m dump (logicmag.io)
| js8 wrote:
| (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 logic" of the
| applications.
|
| After the microcomputer revolution, new languages emerged and
| this divide was lost. "Modern" languages such as C or Java do not
| make this distinction. Today, programmers are supposed to be
| interchangeable, and they are supposed to work equally well on
| system infrastructure and application logic. I suspect it's
| partly the pride, because infrastructure work is often seen as
| more attractive - all the distributed algorithms stuff, scaling,
| etc.
|
| To me interesting question is, was this divide valuable and
| should we return to it? I think so. With the advent of functional
| programming, it is possible to understand applications a layers
| of translation between different languages (see
| https://degoes.net/articles/modern-fp-part-2), where the language
| of the business problem is at the top layer, and the language of
| the operating system is at the bottom layer. The (application)
| programmers, working on the upper layers, should specialize in
| the application domain, and the (system) programmers, working on
| the lower layers, should specialize in computer systems.
| le-mark wrote:
| > 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 practices of the time, all memory was
| statically declared, no dynamic memory allocation, no call
| stack, just gotos and conditional branching, and mapping fixed
| length data from tape drives into memory. Note this all made
| cobol very stable and even secure (no possibility for buffer
| overflows for example).
|
| Also clearly not what was needed for true systems programming.
| DoomHotel wrote:
| 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.
| ASalazarMX wrote:
| Ah, the joys of forgetting to put a period at the end of
| the COUNT-ROWS paragraph.
| nradov wrote:
| Java is the new Cobol. Java was always intended as an
| applications language. Due to GC and lack of direct memory
| access it's not really suitable for systems programming.
| snidane wrote:
| Cloud is the new mainframe. The split between infrastructure
| (platform) and application engineers is back.
| pjmlp wrote:
| 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
| illusion possible for the rest of us.
| PedroBatista wrote:
| 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.
| pjmlp wrote:
| Depends, in the context of COBOL that would be some ORM
| library.
| Zababa wrote:
| > 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, especially now with
| serverless where you only write functions.
|
| In a way this is the return of the distinction between
| application and system, but the system is left to another
| company. This would fit with the (anecdotal) pattern I've
| noticed where before companies had cleaning people, IT
| people, etc and now everything is subcontracted to other
| companies.
| bigbillheck wrote:
| 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.
| Teapopish wrote:
| At least a dozen state unemployment systems still run on this
| sixty-one-year-old language, including ones that help administer
| funds of a billion dollars or more in California, Colorado, and
| New Jersey. When the deluge of unemployment claims hit, the havoc
| it seemed to wreak on COBOL systems was so widespread that many
| states apparently didn't have enough programmers to repair the
| damage; the governor of New Jersey even publicly pleaded for the
| help of volunteers who knew the language.
| vincent-manis wrote:
| I haven't written a Cobol program since the 1980s, and I am
| hopeful I never will. Still, Cobol had many significant advances.
|
| 1. It popularized the notion of program portability, in that a
| Cobol program was expected to run, nearly unchanged, on any
| machine with a Cobol compiler.
|
| 2. It popularized the notion of data portability, in that DISPLAY
| data (though not COMPUTATIONAL data) should be the same, and
| produce the same results, on machines of disparate architectures.
|
| 3. It popularized record data types.
|
| 4. It emphasized the idea of program readability, even though we
| would now (I hope) reject "pseudo-English" as a solution.
|
| The fact that it fell (far!) short of these ideals should not
| blind us to Cobol's significant contribution to programming
| languages.
| veltas wrote:
| 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.
| hosh wrote:
| What do you think about SQL?
| veltas wrote:
| I have a low opinion of it! And I'm not in a tiny minority
| there. There have been other query languages that seemed
| better to me, but SQL won. SQL's not nearly as wordy as COBOL
| though, if you want to calculate tax in SQL you're going to
| write a formula. I think there's a time and place for
| different styles of languages, for a general purpose (or even
| business-oriented) language I think it should have a
| relatively simple and succinct syntax. I just think a
| programming language that's more consistent and _mechanical_
| is easier for most people to grok, and I know a ton of
| programmers that like to tell everyone that they "sucked at
| maths, you don't need to be good at maths to program", the
| syntax didn't put them off.
| kps wrote:
| > _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.
| veltas wrote:
| Very interesting, and I have a lot of respect for Grace
| Hopper personally. I think tech that's meant to look
| 'correct' to the right people is often worse off for it,
| though. I've got no interest in appealing to the people that
| won't even bother trying to look at it if it reminds them of
| maths or uses something other than plain English, but it has
| a place I suppose. I just think the posted article
| overestimates its scope.
| AnimalMuppet wrote:
| 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.
| hosh wrote:
| 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.
| zozbot234 wrote:
| 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 explained in some other
| way.
| js8 wrote:
| 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
| to the industry.
|
| So C and FORTRAN didn't came out of the academia, but were more
| widely adopted by it, which influenced later generations of
| students.
| pjmlp wrote:
| 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_on_UNIX_6t.
| ..
| anthk wrote:
| What's your opinion on ITS?
| hyperman1 wrote:
| 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 will threat
| it gently, do a lot of interpreting of codes themselves, and can
| be fired if they look behind the curtain.
|
| These are not unavoidable technical blockers, but every
| programming language also carries a specific culture within it.
|
| None of this should block unemployment payments, but all of this
| places COBOL firmly in the sixties to maybe eighties.
| mech422 wrote:
| 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
| stuff fairly quickly..
| hyperman1 wrote:
| 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.
| denton-scratch wrote:
| 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 the fact that we were under
| commercial pressure to ship code, we shipped a lot of spaghetti
| code.
|
| The idea that COBOL code is "easy to maintain" is nonsense. Any
| non-trivial COBOL program that is easy to read and maintain is
| going to be harder to write than an equivalent program in (say)
| Pascal, PL1 or ALGOL.
|
| I worked for Burroughs; one of the super-powers of the Burroughs
| systems was hardware BCD arithmetic. It allowed a COBOL
| programmer to declare numeric variables with any specified number
| of decimal digits, and perform arithmetic on them with exact
| precision, easily. This is necessary when handling currencies,
| for example. Also, a hex dump of a BCD variable is precisely it's
| decimal value - BCD made it easy to debug.
|
| It is said that COBOL is unsuited to systems programming. This is
| true; but it's not impossible. I was lucky enough to be sent on
| an "advanced COBOL course", in which I learned that the Burroughs
| COBOL compiler had seven passes; and that you could stop it
| during the later passes, and edit the intermediate code, before
| resuming the remaining passes. This meant that you could do
| things like access registers and IO ports. It blew my mind (but I
| never made use of those learnings!)
|
| For many years, I denied that I had ever learned COBOL, for fear
| of being marked-down as an old fogey. Now I'm retired, I _am_ an
| old fogey, and I don 't give a tinker's cuss.
| DoomHotel wrote:
| 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.
| ASalazarMX wrote:
| 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.
| lcvella wrote:
| The article dismisses the criticism against COBOL with an
| argument akin to "mathematicians use those funny symbols because
| they like to feel superior to everybody else."
| YeGoblynQueenne wrote:
| >> 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.
___________________________________________________________________
(page generated 2021-05-07 23:01 UTC)