> one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s.

If languages like Smalltalk, APL and Lisp aren't counted, then sure, Java was big productivity boost in the history of programming.

I think that the reach of a language need to be considered, as influential and lovable those language might be most of the effect they had was by influencing other languages.

There's nothing wrong with that. Algol heavily influenced the design of scheme, but I've never seen an Algol program in the wild. That doesn't mean it wasn't influential.

Einstein got the Nobel for the photoelectric effect, which we take advantage of continuously every day. I'd say that was influential.

Fortran's older and Lisp is as old (it can be argued about whether COBOL or Lisp are older). Fortran and Lisp seem to have held up much better. ALGOL is another contemporary, and arguably the one that has the biggest impact on popular languages.

Just a note on FORTRAN (which I also used for about a decade) vs. COBOL. It's important to remember that FORTRAN could not deal easily with character data until FORTRAN-77 which introduced the CHARACTER type. Prior to that you stored character data in arrays of 4-byte words, INTs if I recall correctly. It was really painful to use for data manipulation and reports which were among the main forms of output at the time.

I'm also a big FORTRAN fan, especially the VAX-FORTRAN variant DEC introduced in the 1980s. It was great for numerical analysis but also included library calls to access the operating system, much like C. Some of us were late to the Unix party, so this was a huge step forward.

The best thing about COBOL is the distinct lack of hipster coders or frameworks. I worked on various COBOL code bases over the years, and they were always approachable, if a little long-winded. My cheques still process via COBOL code a friend's grandmother wrote and still runs on emulated Unisys hardware.

Clearly you haven't caught up with the future, my friend: http://www.coboloncogs.org/INDEX.HTM

I will not mourn the death of paper checks in the USA. I still have to pay my rent with a paper check. Le sigh.

> because you could control the data layouts very precisely

You can do that in assembly too

Ah. I’ve been downvoted... Guess I should’ve been more clear. I was referencing how the OP said COBOL was easier for data layouts. So, not really knowing COBOL, I was asking why. Poor wording.

The feature we’re talking about here is an easy to use version of doing memory layouts like you’d do with C structs and unions. And combined in with that is automatic number formatting. And all of it uses a clean concise layout that’s self documenting.

COBOL structures are better for fixed-length strings than C structs are because C really prefers strings do be null terminated. In C you've got to specify the length of each string, whereas in COBOL the compiler takes care of that for you.

I can even do that better in Lisp over C structs. In my own home-grown dialect. Suppose we have

  struct foo {
    int count;
    char name[16]; /* not null terminated! */
  };

REPL: define an alias name foo for the type with typedef:

  1> (typedef foo (struct foo (count int) (name (array 16 char))))
  #<ffi-type (struct foo (count int) (name (array 16 char)))>

Now put an instance of the Lisp struct into a binary buffer using this FFI type:

  2> (ffi-put #S(foo count 42 name "ABCDABCDABCDABCD") (ffi foo))
  #b'2a00000041424344 4142434441424344 41424344'

Now, recover a new Lisp struct instance from this binary struct:

  3> (ffi-get *2 (ffi foo))
  #S(foo count 42 name "ABCDABCDABCDABCD")

No problem; the FFI type system knows that an "array of char" is different from a null terminated string, and can make it correspond to a Lisp string in both directions.

Now, for fun, let's poke a zero byte into that buffer:

  4> (set [*2 8] 0)
  0
  5> *2
  #b'2a00000041424344 0042434441424344 41424344'

There it is. Now decode:

  6> (ffi-get *2 (ffi foo))
  #S(foo count 42 name "ABCD\xDC00;BCDABCDABCD")

What's that? My UTF-8 decoder treats the 00 as an invalid byte, and maps it into the surrogate pair range U+DCXX. The otherwise optional semicolon was output because the next character in the string is a hex digit.

If that U+DC00 is encoded back, it will reproduce the null byte:

  7> (ffi-put *6 (ffi foo))
  #b'2a00000041424344 0042434441424344 41424344'

COBOL's data types look like they're well-suited to storing fixed-width, hierarchical data, with the format of the data being specified in the data type. The numerical types are oriented toward fixed-point decimal, with explicitly specified levels of precision.

Two variables holding common license plate formats might look like this:

01 LIC-PLATE1 PIC 9A(3)9(3) VALUE '1ABC234'.

01 LIC-PLATE2 PIC 9(3)A(3). VALUE '123ABC'.

[edit: added a newline to separate my examples]

("9" specifies a numerical digit, "A" specifies an alphabetic character, and there are other types that deal with sign, explicit and implicit decimal points, etc).

Assembly deals with memory layouts, but doesn't enforce any kind of higher-level data type, and especially not a human-oriented data specification.

But it is undoubtedly more efficient to do so in COBOL.

COBOL is well described as the language for regular expressions over tables.