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?