A Year of Functional Programming

STM applies to OOP just as much as it does to FP. There is nothing magical about monads that make STM possible, they just make building the infrastructure for STM easier.

> With Haskell their reuse was an order of magnitude higher as measured by the number of external library dependencies!

If we're talking real world -- as we should -- then this should be contrasted with the tradeoffs and alternatives. The most important kind of code reuse, IMO, actually happens at a larger scale, and in the past few years has worked remarkably well, since the advent of open-source. I'm talking about reusing projects like ZooKeeper, Hadoop, etc. Being able to use such a project might save you millions of LOC, regardless of the level of internal code reuse. The lack of Haskell libraries and bindings relative to other languages reduces this most important kind of reuse. In fact, using ZooKeeper also reduces a large number of bugs.

> But don't worry, we're working on it.

Excellent. I'd love to get a full picture, tradeoffs and all, of a big, important software project in Haskell (which isn't a compiler).

> The other day our newest hire made the comment that at our company each individual developer is responsible for roughly the equivalent of an entire team at all his previous jobs.

I can say the same for my current job, even though we're mostly doing Java (and some Clojure), and at our previous jobs we also used Java. This mostly has to do with the quality of developers, company structure and size, and less with the choice of programming language.

You know, you're right - that does sound a lot like Erlang.

Which is generally considered an extremely pragmatic language.

I guess it all goes back to the Actor model and the origins of OO in Simula.

It's not that I don't think that programming in a functional style isn't a good idea , it's just that the discussions about functional programming and the languages people use to implement its style so often suggest:

   If you use language 'x', then using
   mutation is wrong.

and recently, I've been thinking about the practically important but socially awkward question:

   What language is best for implementing
   mutable state?

By which I don't mean:

    What language makes avoiding mutable
    state impossible?

because given my skill set on some absolute scale that encompasses Knuth, I've got big fish to fry. Trying to maintain ideological purity is a distraction at best and an impediment at worst, if I am ever to see an [m42] and have a solid intuition about its solution.

Even the most rousing chorus of 'Onward Christian Soldiers' isn't going to help me implement Hoare's Quicksort in Clojure. Consing and filtering are great, but they miss the idea of working in-place. Racket's built in O(log n)priority queue isn't a substitute for a traditional O(1) queue implementation:

   +-------+
   |   | o-|------------------+
   +-|-----+                  |
     |                        |
     v                        v
   +-------+    +-------+   +--------+
   |   | o-|--->|   |o-|--->|   | nil|
   +-|-----+    +-|-----+   +-|------+
     |            |           |   
     v            v           v
    'a           'b          'c

The built in priority queue is mutable anyway.

The illustration of queues in Racket isn't rendered from whole cloth. If one searches the Racket documentation (depth first is implied?) the only hit for 'queue is the priority queue which lives in the 'data library [and again, it's still mutable and not thread safe]. But the real problem is that providing Racket implementations on Rosetta code is one of those ways Racketeers are encouraged to give back, and the implementation of LIFO on Rosetta Code shows the priority queue, rather than an actual queue, in part because using 'mcons is considered taboo under functional programming mores. It's a socially acceptable answer, rather than a correct one.

Some things just have to be to be mutable in order to get built in a way that will be useful when dealing with large tables when the first test of usability is getting built in the first place. It's not that playing with dangerous objects ought to be encouraged, it's that it there's nothing wrong with a little dynamite now and then for removing stumps when the alternative is lifting the grinder to the top of the cliff with a crane. All that really matters is acting in accord with the fact that, yes, we're using dynamite.

There's a continuum between Coq and MMIX. A good functional programming language allows refactoring a solution from right to left. It doesn't pretend as if there isn't a right wing or that it doesn't matter politically.

High frequency trading is dominated by C++, Java and C#. There are a few places using F# and Ocaml but they're relatively small players. I know of only two places that seriously considered Haskell and they both decided against it in the end.

I doubt any of these languages are significantly more popular in "more difficult problem spaces."