Business Programming Languages and the Legibility of Programming | Hacker News Reader

Business Programming Languages and the Legibility of Programming

computer.org

57 pointsrbanffy12 comments

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).

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.

Algol introduced some key concepts used today, such as nested blocks instead of go-to's (or at least prefered over), and readable-versus-writable parameters (similar to by-value versus by-reference parameters). The length limit of variable names was mostly a hardware-centric concern back then, I believe; not a language design preference itself. It was bound to expand as hardware got cheaper & faster. The first compilers were really slow; shortcuts mattered a lot.

I will agree that things like "record statements" may have come from the COBOL camp, although there may have been precursors in punched-card templates. I should note Algol was influenced by FORTRAN.

> the verbose syntax of COBOL programs also allowed for the use of longer identifiers

Virtually every Cobol site out there also requires programmers to prepend their user-defined names with some mnemonic, e.g.

  pg5005-this-paragraph
  lv-this-local-variable
  acpr7502-all-variables-in-programs-in-accounting-system-payroll-subsystem

This also means they never confuse user-defined names and program keywords.

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.

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.

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.

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/

A key criterion any good programming language must satisfy is that programs written in it must be comprehensible. Getting the right results from your payroll reports is just as important as getting your Paxos implementation correct. However, since most so-called "business" programming has minimal algorithmic complexity, the languages used to write that can look quite different.

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.

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.

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.

Reply on news.ycombinator.com