I spent the last two years working on software for two 8-meter telescopes. To paraphrase Alan Cooper: When you cross a computer with a telescope, you end up with a computer with some mirrors. (I’m sure the dozens of mechanical, electrical, laser and optical engineers who point and focus the 300-ton instruments would disagree, but they’d be wrong.) The observatory had an impressively large codebase of several millions lines of code, ranging from hard real-time to Web applications.
As with all scientific organizations, funding is highly constrained, and the observatory for which I worked was hit hard by the U.K.’s evisceration of its science funding. With fewer than a dozen software engineers divided among operations, real-time, and high-level evolution and development, the observatory had a capacity problem.
All technical problems are people problems, and the observatory admirably pushed toward agile software processes, even in an environment where “governance,” “oversight” and “audit” are at the tip of every manager’s tongue. (And it’s difficult to pull off “software is uniquely challenging” to people developing multi-ton scientific instruments that do stuff like “take photos of planets orbiting other stars.”)
At the technical level, though, there was the feeling that new software ought to be developed in something other than Java, the organization’s historical high-level language. The observatory’s software architect was a big believer in the power of functional programming. In my previous column, I pointed out that, by the straightforward criterion of “functions as first-class properties,” every mainstream programming language either is or will shortly be a “functional programming” language.
Python has first-class functions and was popular with the scientists. So one of the more, let’s say, “passionate” discussions we had was whether Python should be adopted by the high-level software engineering team or whether we should go with Scala. (Long-term readers can rest assured that I tediously mentioned Ruby as an additional option.)
If you read my previous column, you know that Scala was the choice. Last time, I discussed my quite-favorable impression of Scala as a “Java.Next” for programmers. On the other hand, what was compelling about Scala that justified forgoing the familiar, powerful and well-liked Python, and the advantages of a cross-discipline programming language that could be shared between science and engineering divisions? If the answer was not first-class functions, what was it?
And so we get to static typing. Forget all the hand-waving about improved quality and productivity due to category theory and monads and Kleisli arrows; that’s a bunch of crap. (It’s not crap that they allow mathematically rigorous thinking about certain problems. It’s a bunch of crap that productivity and quality follow, as supported in less emphatic terms by Pankratius, Schmidt and Garreton.)
Also, forget all that stuff about “weak vs. strong” or even “explicit vs. implicit” typing. The issue worth debating is the trade-off between static typing (with which the compiler can determine, at compile-time, the range of values and operations of a variable) and dynamic typing (where only at run-time are those aspects fully specified). To me, after two years of statically typed Scala as my primary language, I have come to the following dramatic conclusion: Meh.