Years ago, when I was writing the code to support my thesis, our research group was using the functional programming language SML-NJ. As the saying goes, it's pretty indy, you might not have heard of it. You can view SML-NJ as a early ancestor of Haskell, but without the rich ecosystem of Monadic tutorials and proselytizers. Our CS colleagues were very enthusiastic about the language, and rightly so: compared to, say, Java, functional languages offered (and continue to offer) a tantalizing reward of automagic parallelization. As a non-negligible bonus, SML-NJ was (and probably still is) a completely green field. There were no public available libraries as far as I knew, meaning the CS guys could start at year zero and code with purity. They began with monoids and worked their way up to vector spaces, matrices, and so on. These libraries were very elegant. Because of the close binding of math and code, they were 'obviously' correct by inspection.

My meshing code needed the user (just me, really) to enter line segments and facets which should be respected by the mesh. It became apparent that asking the user (again, just me) to enter the equations defining these was too onerous. The code should just compute the equations when given the locations of points known to be in these features. The best way to do this, I reasoned, was via a singular value decomposition: find the dimensions which explain the most variation in the coordinates of the points.

Without any extant packages in SML/NJ, I set out to write the SVD code myself. I spent two days holed up in my office with a copy of Golub & Van Loan's book. This is 'the' book for guiding you through this process, or so I reasoned, and I was a mildly competent programmer. What could go wrong?

As it turns out, G&L is written with imperative programming languages in mind: Fortran, or C, say. While the steps in the algorithm could be annotated as performing certain kinds of rotations or normalizations, which would be more appropriate in the more abstract algebraic playground I was in, they were not. I had at my disposal only setter methods for changing one element of a matrix at a time, and, if you can believe, no 'for loops'.

Before this devolves into an old programmer's war story, I should note that I did not prevail in this idiotic battle. Without a REPL or debugger, I could only use confessional debugging. This used a lot of string appends, which seemed to warp time itself (or rather, use most of the memory on my laptop--it was 2002). Yes, it was old-timey, and I was opressed by the paucity of resources at the time. But it sucked, and I am not nostalgic. Kids these days should not have to do go through this just because I did.

Solving an easier problem

Whenever we would complain to the CS guys that SML was too slow or unweildy, they would often reply that functional programming was, "solving a harder problem." I realized, my second day into this doomed project, that I didn't want to solve a harder problem: I wanted to solve the problem at hand. And so a hacker was born. I wrote a shell script frontend which would call octave to compute the SVD and write the equations to an auxiliary file, and never looked back. I realized I do not have the temperment to be a good programmer (or mathematician, for that matter), but I could be a not-terrible hacker.

Fold left

I was reminded of these dark days in my recent job shuffle. I have spent nearly the last decade coding almost exclusively in Matlab. In my new position, I have the freedom to choose the platform, languages, and libraries for solving our business problem (standard-issue business disruption--real startup stuff). Coming from Matlab, Julia seems like a natural choice: the syntax is very similar, as are many of the function names, but the definition of classes is not insane, and package distribution is possible. Multiple dispatch actually feels a lot like the nice parts of function definitions in SML, where functions are often defined in terms of different possible values of the input. Contra Matlab, the language is controlled by smart people who will collaborate to make the language better, and young enough that mistakes can and will be corrected. From the first announcement, I have been excited about the language, and have maintained that "in \(n\) years, Julia will dominate scientific computing." It just has never been clear what the value of \(n\) is.

The problem is that \(n\) is not zero. Looking around, it was clear that the libraries for the problem I was working on did not exist. Since I have very little experience in the language, writing those libraries myself seemed like a terrible idea. It should be said that friends don't let friends rewrite SVD. So I made my decision based on the libraries available. As a hacker, I don't get points for effort.