I attended a talk at CUFP (Commercial Users of Functional Programming) by a compiler team at Intel on why they were using SML (which -- like caml -- not lazy by

I attended a talk at CUFP (Commercial Users of Functional Programming) by a compiler team at Intel on why they were using SML (which -- like caml -- not lazy by default and allows I/O and mutability without having to isolate them ala IO and St Monads) and the comments were quite interesting: many graph algorithms are best expressed in a mutable fashion and he saw no fundamental advantage of simulating mutable state via recursion/CPS (for algorithms that primarily used mutable state) and actual mutability; it wasn't a performance based argument -- the compiler still outputs extremely efficient (obviously) imperative assembly code, but the additional complexity. Obviously the functional parts of the language still applied with primarily functional algorithms, like parse-tree traversal and transformation, which is an excellent example of monads being useful and handy outside of pure and lazy language. Note that the author also notes two significant problems that have nothing to do with functional programming or purity per-se: 1) Calling language-x from Python/Ruby/whatever is difficult unless language-x is C/C++. I fully agree here. At one employer we've built custom bindings from Perl to OCaml (for a DSL we've built) and it was troublesome (e.g., it was broken during 64-bit conversion and our patch fixing it was not initially accepted, although the Nria team later came up with the same approach -- which involved "burning" a register -- later anyway). This is less of a problem for large scale distributed applications that talk via RPC, but this create a problem of building and re-building first-class RPC libraries in each language -- which (as in this very example!) is again best done by building the core RPC protocol implementation in C/C++ and linking it into the applications (with perhaps a native JVM implementation as JNI is a pile of manure? [Personal curiosity: with Google having a huge Java presence, how does Google handle maintaining up-to-date Java clients for BigTable/Spanner et al?]). 2) Lack of OO. OCaml has OO but it's never used. OCaml has a marvelous module system that is far better than Haskell's. Unfortunately it lacks type classes (hence -- very annoyingly -- no generic "print"/"show" function), but first class modules and campl4 (equivalent of template Haskell) can help there. I am guessing that it doesn't solve the author's problem (which I honestly can't claim I have, but that is like my opinion, man) -- lack of dynamic dispatch. Problem is inheritance based dynamic-dispatch polymorphism and generic polymorphism are hard to reconcile. I am very impressed by the work Odersky has done with Scala as well as C++11 (and boost/tr1 before it), but these are by no means simple languages (by simple I don't mean simple like Visual Basic, I mean simple as in "implementing a compiler for it is feasible in an advance undergraduate or beginner graduate class"). When I write golang, Haskell, Erlang, or OCaml I honestly don't miss OOP as modules, interfaces/signatures, type classes, and the like provide what I want out of OOP. However, I've never maintained (as opposed to wrote) commercial code in these languages. tl;dr That's all folks, I'm now switching to an emacs window to write more C++ code -- while (as a big FP enthusiast) hoping practices for programming-in-the-large would emerge for non-OO statically typed functional languages (from places like Basho, Galois, and Jane Street who have built impressive multi-year projects in those languages), OCaml gets multi-core support, and Scala succeeds in its mission.