Log in

No account? Create an account

Functional programming without a functional programming language

One of the numerous fronts in the Programming Language Wars is "how fast does the code run?" This is a remarkably difficult question to answer, for reasons discussed here, but one can make certain general observations. As pointed out here, there's a top tier of languages that are typically compiled to native machine code without run-time garbage-collection, including C++, C, Fortran, Ada, and ATS. A second tier includes a bunch of languages that are (a) typically compiled to bytecode and then JITted, and/or (b) run-time garbage-collected: Java, LuaJIT, Julia, Haskell, Scala, Ocaml, C#, Go, Common Lisp (SBCL), Rust, Pascal, F#. I won't bother with the several more tiers right now.

The top-tier languages are all fairly mainstream, primarily-imperative, three-piece-suit affairs, except perhaps for ATS (with which I'm not familiar).

The second-tier languages include Scala, Ocaml, Common Lisp, and F#, all of which are primarily-functional, as well as Haskell, which is purely-functional (e.g. it has no assignment statement at all, and it takes advantage of this fact to do lazy evaluation and a variety of compiler optimizations), and a couple of primarily-imperative languages.

If you've read anything technical about my current employer, Google, you're probably familiar with the MapReduce framework for massively parallel computing: we alternate "map" phases (do the same thing to a gazillion data points independently) with "reduce" phases (combine a bunch of data points into fewer data points). You may or may not have heard that MapReduce has been deprecated internally for new code for a year or more: in its place, we use libraries that turn C++, Java, and Go into, effectively, primarily-functional languages with lazy evaluation (think Java Streams). MapReduce is still around, but as essentially a compilation target rather than something humans are supposed to actually write.

Of course, it would be a whole lot easier to write in a REAL functional language with lazy evaluation, rather than trying to retrofit C++ to play that role, but we've got an awful lot of existing C++ code....


That's an embarrassing result for MATLAB, given that its original selling point used to be fast matrix inversion (on a home computer!).

I wonder how the results change with the new language execution engine that just shipped? Certain things got a LOT faster, but who knows what they tested.

Also impressive is how high up JavaScript is. I guess we're getting better at writing compilers that do fast type inferencing and string-to-code evaluation?