HISTORIAN RAAAAAAAGE
Hate to defend C here, but there's a lot of nuance to this discussion! C and COBOL were both products of their context, and "why COBOL" is a complex sociological question. So let's go into the history of all these claims! https://twitter.com/woolie/status/1248434168419078144
Hate to defend C here, but there's a lot of nuance to this discussion! C and COBOL were both products of their context, and "why COBOL" is a complex sociological question. So let's go into the history of all these claims! https://twitter.com/woolie/status/1248434168419078144
Let's start with C, created by "legendary male hackers". First of all, "hackers" implies they didn't know CS. But Ken Thompson has a masters in CS and Dennis Ritchie had (effectively) a PhD. They knew what they were doing.
So why is C so "weird"? A couple of historical reasons.
So why is C so "weird"? A couple of historical reasons.
First, C wasn't written in a vacuum. It was a typed evolution of B, which was a low-memory version of BCPL, which was a syntactic simplification of CPL, which was an I/O and business superset of ALGOL-60. C has a lot of quirks from that lineage, such as using `=` for assignment.
(You can read more about the ALGOL ⇒ CPL ⇒ BCPL ⇒ B ⇒ C chain here: https://www.hillelwayne.com/post/equals-as-assignment/)
Of course, that doesn't explain why it's so unsafe. Lots of reasons there, but a big one is because C wasn't formally specified for a long time.
Of course, that doesn't explain why it's so unsafe. Lots of reasons there, but a big one is because C wasn't formally specified for a long time.
K&R's "The C Programming Language" was an informal specification, which left lots of ambiguities. C was only standardized in 1989, 11 years after K&R and 17 years after its first introduction. So almost two decades of compiler writers running into ambiguous cases.
K&R only mentions "undefined" ten times or so, and the first edition doesn't even include it in the index. But to preserve compatibility with all of the disagreeing compilers, the ANSI C committee had to add dozens of "undefined" and "implementation-defined" cases.
(Those are different. Former means "all bets are off, no guarantees whatsoever", latter means "compilers have to specify what consistently happens, but different compilers can do different things". Each term appears about a hundred times in the specification.)
COBOL also has a few undefined and implementation-defined cases, but a whole lot less than C, and they're not all over the place in the same way.
Also it's possible to write safe C code! Just very expensive. It's often for isolated, embedded systems, like avionics. See DO-178C.
Also it's possible to write safe C code! Just very expensive. It's often for isolated, embedded systems, like avionics. See DO-178C.
Okay, so that's the historical context on C, what about COBOL? COBOL was pioneered by Grace Hopper and Jean Sammet in 1960, as an evolution of Hopper's FLOW-MATIC. The goal was to create a standard languages for businesses, in the same way that engineers used FORTRAN.
COBOL made several PL innovations, like having a concept of hierarchical record data and output formatting. Things that would be very useful to businesses, less so for engineering and academia, which is why business needs were unfairly ignored by the CS world at the time.
But COBOL wasn't a particularly great language. It had lots of redundant syntax, odd punchcard constraints, was very hard to write compilers for, etc. This shouldn't surprise us. We've learned a LOT about good language design in the past half century.
So why does it now "run the world"? Legacy. 1960 was when governments and large corporations started adopting computing en mass. Since most of them needed business stuff, they used COBOL. And since "computers" meant mainframes, these places kept using COBOL for decades.
"Why don't they move off"? Because migrating to a new language is a nightmare. Facebook, written in PHP, came out in 2004. By 2011 they had to make their own virtual machine to speed up PHP. If migrating off a 7 year-old codebase is hard, try 47 year-old codebase.
This is also why the US Department of Veterans Affairs is stuck on MUMPS.
There are ways to migrate off legacy languages, but they all depend on modular designs and good interfaces, something that's lacking from mainframes, COBOL, and 50 year-old software.
There are ways to migrate off legacy languages, but they all depend on modular designs and good interfaces, something that's lacking from mainframes, COBOL, and 50 year-old software.
That explains why it runs the world's systems. What about "you only hear about it when the world breaks"? Is that because it's particularly stable?
That's a bit optimistic. I did some cursory reading that suggests these legacy COBOL systems are all trash fires.
That's a bit optimistic. I did some cursory reading that suggests these legacy COBOL systems are all trash fires.
But critically, they're trash fires that people have been fighting for fifty years, so there's a lot of built up protection around them. They're also kept as isolated as possible from more modern systems.
And even then, COBOL programmers make bank off maintaining these systems.
And even then, COBOL programmers make bank off maintaining these systems.
In conclusion: C has problems, but a lot of those problems are driven by historical context. COBOL has benefits, but a lot of those benefits are driven by historical context. These problems often transcend who made them into how society at large used these languages.
History is cool y'all
(If you liked this tweetstorm, you might also like my recent essay on historically influential languages that died out: https://www.hillelwayne.com/post/influential-dead-languages/)
(If you liked this tweetstorm, you might also like my recent essay on historically influential languages that died out: https://www.hillelwayne.com/post/influential-dead-languages/)
PS: There's at least one interesting case of the government successfully migrating huge legacy systems: JOVIAL to Ada and Java. But that's an incredibly complex topic I can't even begin to do justice to.