
Business Programming Languages and the Legibility of Programming - rbanffy
https://www.computer.org/csdl/mags/an/2018/02/man2018020017.html
======
tabtab
The lesson from hindsight is that you have to experiment and actually try
things in production to see what "sticks". One cannot sit and think to really
know what the "future wants".

Between Flow-Matic/COBOL, Fortran, Algol, and Lisp; one couldn't really say
which approach would become the most popular or comfortable. Algol's style
pretty much "won" in the longer run, but it wasn't clear and couldn't be clear
up front. Despite Algol-style's "win"; COBOL, Fortran, and Lisp are still in
common use, and have defenders (sometimes for domain-specific reasons).

~~~
zozbot123
ALGOL (or rather, the various incarnations thereof) was a _very_ different
animal from any programming language we're familiar with nowadays. I'd say
modern languages might owe just as much to COBOL - didn't the "record" or
"struct" concept originate from there? As another data point, the verbose
syntax of COBOL programs also allowed for the use of longer identifiers, quite
similar to ones we'd write today even in a "low-level" language like C.

~~~
ams6110
At least in early versions there would have been some motivation to constrain
the length of variable names, because a line of code needed to fit in an 80
column punch card.

~~~
eesmith
I don't believe you are correct.

I found nothing in the COBOL 60 documentation concerning a required width. The
closest (in section VIII "Reference Format") was "right hand margin Z is
determined by the width of the paper or printing media".

While it's true that the 80 column IBM card was by far the most popular, other
options were available. I can believe that a COBOL implementation for the
Remington Rand might use all 90 columns.

The COBOL 60 documentation says (section 2, "Words") that variables are no
more than 30 characters in length.

There was no need to fit everything in the same physical line because COBOL 60
supported line continuation, using a "-" as the last character position of the
line (section VIII-2, "Reference Format"). This could even occur in the middle
of a name.

------
zengid
I feel like one of the hallmarks of COBOL (imo) is that it was oriented around
producing reports, or in other words its whole reason for existing was to do
data transformations from inputs to outputs. Early versions of Algol (like
early versions of Haskell) couldn't do any I/O!

I think that is the amusing distinction between daydreaming academics and
bean-counting business people: at the end of the day what does the language
assist you with? For academics, Algol was a tool for thought. For business
people, it was (and still is) a tool that helps them know how much money they
are making and to make the machinations of their business function.

~~~
rst
Data transformations yes; reports were one case, but not the only one. The
sample application in the FLOW-MATIC manual (online at Bitsavers) is a tape-
to-tape job. (And there's quite a bit of stuff in COBOL, including things like
MOVE CORRESPONDING, which suddenly make a _lot_ more sense if you start to
think of it as SQL for fixed-format records on tape drives.)

[http://bitsavers.trailing-edge.com/pdf/univac/flow-
matic/](http://bitsavers.trailing-edge.com/pdf/univac/flow-matic/)

------
gameswithgo
A lot of us have found the ML family of languages (F# mainly, but also
OCaml/Reason) to very legible for expressing models of business data, so much
so that you can sit with someone from the business side and cover over the
code with them directly. A toy example that you can extrapolate to various
business cases with representing a deck of cards:

    
    
      // A Suit is one of:
      type Suit =
      | Hearts
      | Spades
      | Clubs
      | Diamonds
      
      // A Face is one of:
      type Face =
      | Jack
      | Queen
      | King
      | Ace
      
      // A card is either:
      // A face card with a Suit and a Face
      // A non face card with a suit and a number
      // or a joker
      type Card =
      | FaceCard of Suit * Face  
      | ValueCard of Suit * int 
      | Joker
    

models like this are easy to read and the languages will ensure that when you
work with them that you never miss handling a case.

~~~
clausok
True. One time the portfolio manager I was working with wanted to examine an
aspect of our systematized hedging rules. He was a non-programmer (unless you
consider writing Excel formulas to be programming). I started to read through
our F# code where we formalized our hedging rules and translate them into an
email explanation. It suddenly came to my mind, "I'll just take a screen-shot
of the code here and see if that does the trick". It struck me that the format
of the F# active patterns and the layout of the code was a better depiction of
the logic than I was achieving with my written explanation. So I sent the
screen-shot. And he wrote back, "ok, got it." That became the first of many. I
started writing and formatting my code with the expectation that I would be
sending explanatory screen-shots to the PM and trading desk. It turned out
that approach made the code much easier for me to understand as well. And I
agree that the ML family of languages have uniquely advantageous
characteristics when attempting this type of legibility.

------
doggydogs94
My first job involved using COBOL to read and write various files; it was
amazingly easy. Now I have to read and write files using C/Java/Python,etc;
always have to Google to remember how to do the simplest file i/o and parsing.

