Systems Past: The software innovations we actually use

How is transactional integrity an outdated concept? And you are actually telling me that there are "databases" that don't have transactional integrity?

> FORTRAN’s conflation of functions (an algebraic concept) and subroutines (a programming construct) persists to this day in nearly every piece of software, and causes no end of problems.

This is exactly what Haskell solves. Not by eliminating subroutines, but by separating the two concepts out again. In particular, functions are functions in the algebraic sense, and subroutines just become values in the IO type.

> Tracing compilers scratch the surface of reversing this mistake, but so far I know of no programming languages that are specifically designed around such a mechanism.

I'm not sure why he thinks tracing compilers help rectify the issue. Perhaps they can claw back some performance gains from knowing a function is pure, but static compilers can do that too.

And I think it's fair to say that Haskell was basically designed around "such a mechanism"; it's a shame the author doesn't know about it.

> ISWIM (which some programming language histories identify as the “root” of the ML family) is based on ALGOL 60 (source), which of course is based on FORTRAN

While ISWIM was influenced by ALGOL, it was based on the λ-calculus. And the λ-calculus, of course, precedes Fortran—and, in fact, computers in general—by quite a margin! It was originally developed in the 1930s.

Many modern functional languages are just thin layers over a typed λ-calculus: Haskell's Core intermediate representation is actually exactly that extended with some low-level primitives. This means that they are far closer to formal logic than they are to Fortran!

Considering the idea of a programming language a fundamental innovation derived from FORTRAN disregards earlier concepts, like Gödel numbering from the year 1931, which exhibit language interpretation. I guess what I'm trying to say is that every good idea is closely related to countless others; pigeon-holing them into the Only 8 categories and naming a "first" doesn't do justice to all of the interesting ideas of computation.

MySQL with MyISAM tables.

Text isn't as important as language itself, but there's the rub: no one has yet devised a better way to program computers than language. Even the so-called "visual environments" we see today ultimately boil down to recognizable linguistic concepts: they do it by arranging shapes in space rather than writing text, but you can pick out the same nouns, verbs, and other parts of speech. And that's the problem. Visual environments are trying to represent language, and they're just not as good at it as text, which is the closest thing to a native format yet devised for the stuff. Eventually the inefficiencies start to get annoying, people go for the greater efficiency of text, and the visual environment languishes.

The bottom line is that visual environments will never be as good as text for representing programming languages. Rather than trying to do language better than text, they need to find a paradigm that's better than language, and implement that. I don't have any clue what something like that would even look like; to be honest, I'm not sure it can even be done. But the greatest victories against the most hopeless-seeming odds are won by changing the whole nature of the fight, and that's what visual programming is going to have to do.