5 ms·
I worked in insurance so much time ago, in a COBOL shop (I was doing web-services on top, so I'm not a COBOL programmer myself). A few things come to my mind:
by kimi 8y ago
I worked in insurance so much time ago, in a COBOL shop (I was doing web-services on top, so I'm not a COBOL programmer myself). A few things come to my mind:
- COBOL has no stack and no dynamic memory allocation. The memory cost of a procedure is known in advance and you cannot leak memory. There is not much room to be smart, and in the long run it's likely a reason for success. You would not want people with a three month training editing 20-yr old C code.
- COBOL procedures are damn CPU-efficient at what they do
- COBOL works in symbiotic relationship with DB2. A lot of things that are complex/tiring to do in COBOL (like e.g. working with strings...) can be done in SQL. And when you have SQL you can do pretty powerful things.
- COBOL procedures do not usually sent SQL queries as strings to the database. They compile down to a procedure that does physical, low-level handling of database tables. If you change a table, you have to recompile all procedures that depend on it (and it may take hours to days....) but again is damn efficient in production.
- mainframes run constantly at a CPU usage of over 90-95%. There is a huge amount of procedures constantly running to maximise the return on the system.
- pkaye 8y ago> COBOL has no stack... So no function calls?
- nafey 8y agoAlthough I am not familiar with COBOL I am assuming this means you have to indicate where the control returns to after a function ends
- jrq 8y agoSo that's kind of like a coroutine. Taking recursion away seems like an unnecessary limitation, considering how much power main frames have. Resource efficiency is great and all, and certainly there's a benefit to not hammering the stack as often, but that takes away an entire category of definitions you can't express, right? Maybe someone who writes cobol could chime in on this.
- joshuaduffy 8y agoCorrect. They are called subroutines in COBOL.
- blattimwind 8y agoRecursive and iterative functions have the same computational power.
- adrianN 8y agoAnd every computable function can be expressed in Brainfuck. That doesn't mean that some algorithms are a lot more elegantly expressed when your language supports recursion.
- Koshkin 8y ago> how much power Do not forget that when COBOL was created mainframes were less powerful than today's microcontrollers.
- kbp 8y ago> Taking recursion away seems like an unnecessary limitation Modern Cobol doesn't seem to have this limitation, eg http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3PG20/4.1.4 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handhel.... When Cobol originally appeared, call stacks weren't standard, Lisp didn't exist yet, and neither Fortran nor Algol supported recursive functions; it made sense at the time.
- jrq 8y agoOhhhhhh, of course! Gosh, thanks. I sometimes hold historical technology to unfair standards because I'm not thinking about the continuity of it all. Crazy to think twenty-somethings are out there hacking COBOL!
- kbp 8y ago> So no function calls? No recursive ones. If you forbid (direct or indirect) recursion, then a function's local variables can all be static rather than stack-allocated. Similarly, each function could have a hidden, static "return address" variable (since all parameters are static, it's really just a hidden parameter) that is set behind the scenes when a procedure is invoked and jumped to when it exits. edit: I was just guessing how you'd do return addresses, but it looks like that is how they used to work. From Wikipedia: "Machines before the mid 1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting, but does not support recursive subroutines." Ancient Fortran also didn't support recursive procedures, and they were only sneaked into Algol 60: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/ https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...
- infradig 8y agoI debugged many a COBOL pragram by running down the stack. In fact, I wrote a COBOL debugger for Sperry/Univac 1100's running HVTIP transactions.
- kimi 8y agoMaybe I remember incorrectly, or they just did not use it because it was a different revision/standard. Obviously COBOL today has everything (there must be reactive COBOL somewhere).
- Someone 8y agoClassic COBOL needs a stack (or something equivalent. A popular choice was to store return addresses of calls near function entry points, distributing the stack through memory) to support the case where a single subroutine is called from more than one place in the program (most, if not all, programs will have those, if only to do I/O) What it doesn’t need (and didn’t support) is recursion, and without recursion, the maximum depth of the stack can be computed at compile time, so that a program can refuse to run if there isn’t sufficient room for a stack that size. (The first FORTRAN’s were similar in this respect. If you wanted your program to support larger arrays, you recompiled it)