> Unlike FORTRAN and Lisp, it begat nothing.
Cross-platform portability.
And long-windedness, though I don't count that a positive.
COBOL could actually do more sophisticated stuff than that. For example, it had the "occurs depending on" construct, where you could read a record that had variable numbers of repetitions of a sub-structure, with the number of repetitions specified by one of the fields. (I never actually programmed in COBOL, but I've had to deal with code that had to support COBOL-style data structures.)
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/...
So beware of criticizing an old programming language from a modern viewpoint, just like FORTRAN and Lisp it taught us a lot of valuable lessons. If all the COBOL code in the world that is still running would stop working tomorrow morning at 9 am you'd definitely notice.
Delphi was launched decades after COBOL and so of course had many more modern language concepts built into it. It also had a fantastic little IDE and in general was a more comfortable environment to work on (by way of being on a PC rather than a mainframe).
To really appreciate COBOL you should look at the entirety of the environment that it was used in rather (where batch processing was the norm and subroutines rather than function s where the code blocks) than to compare just the language features. You also may have noticed the occasional 'CALL' verb, which was COBOL's way of modularization.
I think that your impression of COBOL may have been a little bit clouded by that one job. I've seen some really readable COBOL, and given that the alternative was assembler and that those programs were patiently put together line-by-line on punched cards and never ever were refactored using an interactive editor should go a long way towards understanding why we make progress in little steps rather than in huge strides.
Delphi came into existence by way of Pascal, which is from the ALGOL family of languages, an entirely different branch on the tree of programming languages. Comparing Delphi with COBOL directly is not really very useful because you'd be comparing a language made for interactive applications on PCs in the late 80's with a language made for batch applications on mainframes in the 60's. The 20 years in between were the most important years for the IT industry when it comes to language development.
Also, the GPP was rather adamant about COBOL being a dead-end but Pascal actually owed a fairly large chunk of its data structures to COBOL and without the 'record' construct I highly doubt Pascal would have gone as far as it did, it was a good idea whose time was ripe and COBOL being business oriented had immediate need to support this (as well as data files), and then there was the fact that COBOL more or less introduced platform independence (though in practice that translated into 'less work than otherwise').
All in all it really is not fair to label COBOL a 'dead end'.
Not entirely true. One obvious thing it influenced was PL/I, which was supposed to unify FORTRAN and COBOL along with block-structured programming from Algol. PL/I was only ever moderately successful. While it saw some use in business data processing, COBOL was always more popular for that task. I think its biggest successes were systems programming (e.g. Multics, CP/M, MVS, Honeywell CP-6) and compiler development (e.g. the compiler for the HAL/S language used to program the space shuttle computers). (In most of those applications, they didn't use pure standard PL/I, rather dialects such as PL/M, PL/S, XPL). In those applications, compound data structures are very important, and the PL/I syntax for those was obviously influenced by COBOL (in the use of level numbers). And PL/I has in turn influenced several other languages, I think the most notable would be REXX, although I'm not sure how much of the COBOL influence survives in those descendant languages.
Other languages COBOL arguably influenced include DIBOL (a business programming language developed by DEC, it was a mishmash of COBOL, FORTRAN and BASIC) and ABAP (SAP's application programming language, derisively nicknamed "German COBOL").
Ada annex F (Information Systems) was consciously influenced by COBOL, especially in the concept of "picture strings". I think the influence of COBOL picture strings can be seen in other languages also, e.g. the date formatting syntax used by java.text.SimpleDateFormat. So in that small area, arguably Java is descended from COBOL.
I personally think the syntax of SQL shows some definite stylistic influence from COBOL. A similar wordiness and proliferation of keywords. Since SQL was designed by IBM in the 1970s, and the first implementations of it ran on IBM mainframes, obviously the team that invented it were very familiar with COBOL, and it shows.
English Wikipedia reports that the legacy telecommunications programming language CHILL (CCITT High Level Language) was influenced by COBOL–no idea how true that is. Polish Wikipedia reports the existence of a mid-1960s Soviet language called "Algek", which was based on Algol and COBOL. Around 2000 someone invented a language called "CobolScript", which was supposed to help COBOL programmers get into web development – it didn't take off.
This is all odds-and-ends, but it isn't literally nothing.
https://en.wikipedia.org/wiki/PL/M
The PL/M source code for various version of CP/M can be inspected here: http://www.cpm.z80.de/source.html
(Maybe I am being somewhat inaccurate in calling PL/M a "PL/I subset"; maybe it would be more accurate to say that PL/M is a distinct language which was heavily influenced by PL/I, a member of the PL/I language family.)
It is somewhat amazing to me that I can't recall that I ever knew that, despite once having owned a CP/M machine and having written some software for it. I always assumed it was written in assembly.
"Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer."
And yet, people with much linguistic proficiency are rare in the field of software development. I don't know why this is so, and it is a tragedy.
Thats what I found as well, which is why we need more of them. Maybe it is a german thing, but I can tell you that we don't have a lot of those types doing software development. Maybe because people here are more likely to study humanities instead than in the US? I really don't know.
Also, code review comment that teaches something instead of just vaguely alludes that "this is bad". It is better when junior learn why instead of memorizing seemingly arbitrary rules.
Also, communication in the team and out of team. If you can explain why the estimate is too small or that users/managers/customers naive idea is, well, naive (without using that word), then you are the gold. If you can ask the question in a way that makes people understand what you are asking and gives you answer, you are double gold.
If you can explain why the proposed design change or style guide change would be helpful, then you don't have rely on snark and put-downs when pushing for those changes (and thus avoid long term consequences such style has). And so on and so forth.
Which programming language was begat by FORTRAN? The ALGOL family seems rather independent to me.
Both FORTRAN and COBOL had the misfortune to be created before structured programming. Others, like FORTH and LISP were lucky that they are flexible enough to easily add new programming conventions.
You could probably say that modern report generators were begat by COBOL to some degree (even though FORTRAN had formatted output too)
It seems programming languages designed to be "easy to use" suffer from lots of people writing really terrible code with it. Excel or VB have similar issues.
From my experience working on compilers, the thing Fortran begat the most was advanced compiler optimization algorithms, which then trickled down into C and C++.
FORTRAN compilers were great for loop optimizations, but not clear if it pioneered much else worthwhile.
Fortran->Matlab->Julia is a pretty obvious family tree. Much of how numpy and similar libraries do numerics is also quite obviously influenced by Matlab (and thus Fortran).
And yet Python became a thing. In Djikstra's defense, Python's design philoshophy is more about striving to be a "highly readable language" rather than to emulate a "natural language", but the two are almost interchangeable in practice.
Dijkstra died in 2002, which was after Python was released. There may be some comments from him out there about the language, though I can't be bothered to look them up, I don't find Dijkstra to be particularly insightful.
> Despite having invented much of the technology of software, Dijkstra eschewed the use of computers in his own work for many decades. Even after he succumbed to his UT colleagues' encouragement and acquired a Macintosh computer, he used it only for e-mail and for browsing the World Wide Web.
I think Dijkstra was writing from a very specific perspective, and that is mostly only relevant today from a historical viewpoint.
Marcotty writes: "The important thing is not whether the committee was right in its conclusion, but that a serious effort was being made to design a programming language for communication between people as well as with computers."
To put this in context, consider this quote from Backus and Heising (1964) about Fortran: "[Our group] had one primary fear: ... an important application ... would run at half the speed of the hand-coded version. It was felt that such an occurrence ... would almost completely block acceptance of the system."
There are so many different ways that software can be bad. COBOL had plenty of warts, sure, but it also had a very top-down simplicity to it. I'm the FNG at a new job and have been given a shitpile of Magento to shovel; I think I'd rather have the COBOL. (I'm pretty sure Magento is the absolute worst example of what somebody can do with PHP.)
COBOL didn't support any of the abstractions that programmers today abuse to as an excuse to build out intractably tangled messes of code so that they could refer to themselves as "software architects". That alone has kept a soft spot for it in my heart.
It wasn't until on my first consulting gig writing RPG III for a year, that the IBM guy installed COBOL on the system 34, and Presto COBOL wasn't all that bad.
For its time it was better than alternatives. After a while, not so much.
https://news.ycombinator.com/item?id=1373443 https://tekkie.wordpress.com/2006/05/31/rediscovering-dr-dij...
And before you get angry at me, answer this simple question: have you actually ever used COBOL? I spent a year of my life translating a COBOL mess into Delphi. It was horrible - the code I was working with had no functions (unless you think of a module defined in an entire file as a function), global scope on variables, and tons of ugly COBOL boilerplate, as dictated by the language.
And it's no surprise that COBOL was a historical dead-end. Unlike FORTRAN and Lisp, it begat nothing.
That's why I'm hard-pressed to venerate anyone that had anything to do with perpetuating that mess.