The Shape of Code

F is for Fortran, Forth, Frink and Flow.

Fortran is a member of the triumvirate of founding major languages. Its continuing success is due to it doing a good job addressing important application areas (i.e., big engineering and scientific number crunching problems) and the availability of high quality compilers (non-software engineers will pay for good tools and big science problems attract lots of government funding). Computer science types may turn their noses up at Fortran, but they are in the fashion business (which is why Algol 60 died out) and not interested in solving big real-world problems. For many years Fortran compilers reliably generated faster code than C compilers because lots of customers will willing to pay for high quality (C compilers assumed that optimization was the programmer’s responsibility) and because Fortran’s lack of pointer types made it much easier to figure out what code was doing. These days C compilers have been around long enough that high-end optimizations have trickled into them and they also have enough processing power and main memory to figure out what those pointers are getting up to.

Forth and BASIC were the minimalist languages of their day (and Forth still is in some niches). Forth was the techi’s language (who else would be content to write code using reverse Polish) that allowed developers to get that bit closer to the bare metal and talk technical stuff about threaded code. Perhaps the reason Forth has lost the general appeal it once had is because its core users have embraced respectability (e.g., creating a language standard and boasting about the availability of ‘proper’ compilers); returning Forth to its roots of bare metal, threaded code, hell-raising might bring back the following it once had.

Frink supports dimensional analysis of source code, something I am a big fan of (this kind of analysis is a step up from traditional strong type checking). Other languages designed, in a bygone age, to support dimension checking have disappeared, as have proposals to extend popular languages.

Flow adds gradual typing to Javascript; it is from Facebook who seem to be making a habit of this sort of thing, and I hope they succeed. A consequence of OO’s success is that most developers now think of types purely in terms of a mechanism for matching calls to the appropriate method. The idea of intentionally creating type information that is intended to fail to match, as a means of detecting coding mistakes, has been lost to a generation of developers. I would like to predict that languages supporting strong static typing are going to make a big comeback (once word starts to spread about the time saving benefits of static type checking), but things did not turn out that way last time such languages were in fashion.