COBOL, and other PLs of that day, were heavily integrated with the ISAM file structure. ISAM a precursor of SQL, and was basically a hash table implemented very efficiently in a file. If you have hash tables, you can do pretty much anything. (Actually, it was better than a hash table. Once you had indexed (I) into the file, you could sequentially read forward (S). The AM is Access Method.)
I was thinking more about performance than space. If you hit the disk for every recursive call (not sure if it is the case, I can't read COBOL) the performance is probably going to be terrible even if the files are memory mapped. Optimized tail recursion would avoid most of that.
Nobody bothers about the 8080 these days. If it had been a disassembler for the Z80, it might be a different matter. But there's dozens of those around, and written in C to boot.
New parts of old systems, mostly. There are some huge COBOL application spaces out there, and quite often writing new modules for that with a more modern COBOL mind- and featureset is still easier than writing it with a different technology and then taking the trouble of connecting that to the existing part using eg CORBA.
The answer has been "no" for a long time. Once people got excited about Algol they started basing languages on the idea of inline math/expressions. FORTRAN survived by changing; COBOL was mostly abandoned.
I thought so as well. Nobody would call a python-like language "a python". I understand that the balkanisation of lisp is responsible for the fact that anything s-expr based is called a lisp. But, common lisp and scheme are actual, specified languages.
True that, though Common Lisp interpreter is not full Common Lisp e.g. "Common Lisp + its tons of standard libs" -- just "interpreter able to parse Common Lisp".
Does this mean that they are storing the stack as records on a file ? Hopefully they will implement tail recursion as soon as possible :-)
Wait, what? Someone forgot about the PERFORM verb. Or, are they writing this in an old enough version of COBOL for that not to be present?
Also Common Lisp does not require tail recursion and the traditional style doesn’t really use it either
<grin>
Only 35 years ago.
A few lines from the beginning ....
000010* This program is written in NEVADA COBOL .
000020
000030 IDENTIFICATION DIVISION. 000040
000050 PROGRAM-ID. JACKS-DISASSEMBLER.
000080* Version Number 1.0
000100
000110* AUTHOR. simonblack.
000120
000130* INSTALLATION. Giacomo Software, P.O. Box 584, Hamilton, 3300
000140
000150 DATE-WRITTEN. 29 MARCH 1984.
000160
000170*
000180* THIS PROGRAM PREPARES *
000190* AND DISASSEMBLES INTERMEDIATE PSEUDO-CODE FILES *
000200* INTO 8080 ASSEMBLY LANGUAGE. *
000210* *
000220*
000230
000240 ENVIRONMENT DIVISION.
000250
000260 CONFIGURATION SECTION.
000270 SOURCE-COMPUTER.
000280 CPZ-48000-SBC.
> wc /a/comp/development-jvs/cobol-150623/crak80.cbl
Nobody bothers about the 8080 these days. If it had been a disassembler for the Z80, it might be a different matter. But there's dozens of those around, and written in C to boot.
https://m.youtube.com/watch?v=wx8CEy0yMSY
Naturally no one is writing greenfields applications, rather incrementally refactoring existing codebases.
Unlike Python, Lisp is not "batteries included". The original and standard definition of Lisp is the handful of special forms in McCarthy's paper.
Dev didn't say they made a Common Lisp -- just a Lisp.
See the Lisp 1 programmer's manual from 1960:
http://history.siam.org/sup/Fox_1960_LISP.pdf
This was then expanded into Lisp 1.5:
http://www.softwarepreservation.org/projects/LISP/book/LISP%...
The first line in the README after the title is:
> A Common Lisp Interpreter Built in COBOL.
http://www.lispworks.com/documentation/lw50/CLHS/Body/01_g.h...
Roughly: A language would be a subset of Common Lisp, when all programs in that language are valid standard Common Lisp programs.
Please now do it in "brain fuck language"