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.
COBOL was designed for organizations transitioning accounting systems from unit record equipment. It makes sense in that context, and could have been much worse. Someone said (I think about FORTRAN, but it still applies) that criticizing the designers of those early languages is like criticizing Lewis & Clark for not taking Interstate 90.
> Unlike FORTRAN and Lisp, it begat nothing.
Cross-platform portability.
And long-windedness, though I don't count that a positive.
It's useful to review what the computing landscape looked like back then. The choice of language was either fortran, cobol, or assembler. And if you were automating business processes, your programs were reading fixed length lines of data off a tape.
So compared to assembler, cobol was a dream. Sure it was a dead end, and its creators seemed to lack the insight and sophistication of the Algol creators, but no one ever claimed it to be a general purpose language, and it did its job well.
Sure it's fun to bloviate, denigrate, and opine, in ignorance, but there are good reasons why it was widely used for so long, and why there are billions of loc still in production.
"your programs were reading fixed length lines of data off a tape"
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.)
I've used COBOL for about 2 years. Like any other tool, you could get used to it and it got the job that it was intended for done. The fact that it didn't have the niceties of modern languages is simply because it was conceived of long before those modern niceties existed or were validated outside of the realm of research.
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.
That would have probably been the alternative but assemblers in those days did not usually support macros and if they did they were of very limited power.
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'.
> And it's no surprise that COBOL was a historical dead-end. Unlike FORTRAN and Lisp, it begat nothing.
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.
(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.)
> CP/M was written in a different subset of PL/I, PL/M
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.
> the best coders are the clearest writers of English as well
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.
I heard that good lawyers can earn more than good coders. And dunno about Germany, but in my country brain drain is also a problem. And I'm not sure if there really are that many smart people to begin with ;)
If you can sum up algorithm or object structure you create in a single paragraph reading of which saves me four hours of puzzle solving, then it is super useful. Same with one line explanation of clever unusual hack.
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.
Since Fortran had a large amount of existing code soon after it was invented, the standards committee has always tended to add new features to Fortran after other languages had already tried them out and perhaps discovered pitfalls.
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 pioneered expressions which were used in addition to statements. This was huge. Modern languages are still expanding on the idea of programming with expressions (especially functional languages).
BASIC was clearly begat by FORTRAN. This is easier to see in the 1960s versions of both languages, which used line numbers and GOTO statements for program flow, although later versions of both FORTRAN and BASIC borrowed structured programming elements from the ALGOL family.
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).
"Projects promoting programming in "natural language" are intrinsically doomed to fail."
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.
Then again, the argument is not against the wide use of the language, but the way the ideas are manifested. For all we know, Dijkstra might have hated Python.
>"For all we know, Dijkstra might have hated Python."
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.
It's worth noting that Dijkstra was a computer scientist, not a programmer. From Wikipedia:
> 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.
I was reading through a survey of programming language history the other day in Michael Marcotty's Software Implementation, which includes this quote from Jean Sammet (1969): "COBOL ... encourages a certain amount of verbosity. The benefit gained from this, however, is increased readability and understandability in looking at programs."
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."
I wrote a fair bit of COBOL back in the 90s, and read a lot more of it.
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.
In addition to that paper, I raged against COBOL for a long time.
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.
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.