A Year of Functional Programming

I'm guessing Haskell is used by more people than you think. There are 6500 packages on hackage. The Haskell subreddit has more than 16,000 subscribers. And there are usually more than 1300 people in the #haskell IRC channel at any given time. That's more than #ruby and ##javascript and about the same as #python. Also, Standard Chartered bank has roughly 1.3 million lines of Haskell code running in production.

> And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language.

This statement applies equally to pretty much every language out there. We don't understand the tradeoffs between mainstream languages either. We have no idea how those choices are actually going to end up affecting our projects. To claim otherwise is intellectually dishonest. How do you know that Ruby or Perl would be better than Brainfuck? The tradeoffs and merits aren't clear. They're at best hypotheses of potential merits. So how do we actually make these decisions in practice? We look at the language features and think about how they can help us manage common situations in software development, then we go with our best guess. We can do that for Haskell just as well as we can do that for Java, C, Ruby, etc.

Many FP paradigms (including Haskell's) impose an overhead when doing operations that are not pure. In the case of a SMB clone a huge percentage of the work of the program may end up not being pure, therefore a large overhead may be imposed. Further, many of the advantages of FP paradigms (including Haskell's) are dependent on pure functions.

In the case of a SMB clone, a large percentage of the application may be intended to be impure, therefore the "worst case scenario" comment.

That's the second sense I described. It's only meaningful if you're actually talking about a particular function. And you're still left with the question of the actual domain of the function. Semantics, but relevant semantics.

"Many FP paradigms (including Haskell's) impose an overhead when doing operations that are not pure. In the case of a SMB clone a huge percentage of the work of the program may end up not being pure, therefore a large overhead may be imposed. Further, many of the advantages of FP paradigms (including Haskell's) are dependent on pure functions."

That's somewhat true of FRP, basically false about Haskell IO generally, but either way if you can do it in PyGame someone can do it in Haskell - it's mostly a matter of working in a high level language, not a matter of functional-programming-imposed overhead.

I would recommend listening to what John Carmack had to say about implementing games in Haskell (and also Lisp, IIRC).

I don't think I've ever heard of LabVIEW described as a functional language (and it's clearly not a "purely" functional language), but it programs like one. Programs are written by connecting VIs (functions in LabVIEW-speak) with wires in a data-flow diagram. VIs don't contain any state (usually, unless you explicitly use local or global variables--which all the documentation warns you never to do upon pain of something really awful). VIs mostly don't have side-effects (unless you're explicitly doing something with the filesystem, or data acquisition, or motion control, or... ).

One of the difficulties of using FP for "real" things is that you give up something you got for free with imperative languages, namely control of timing. LabVIEW works around this with something called a sequence diagram, which forces VIs to be called in a deterministic order (because, being FP, you can't otherwise divine in what order VIs will be called).

LabVIEW also encourages the use of a trick to enforce sequencing without using sequence structures (and this trick is absolutely mandatory if you don't want a write-only program): The abstract name of an instrument resource is passed to a VI, and then returned unchanged. Since the returned values of a function aren't determined until it is run, you can chain several functions together in this way so that they run in sequence (which, IMHO, is bad practice because this abstract resource thing being passed about is something which is needed by each function, and can be modified by each function, but SHOULDN'T be modified by any function).

Annoyances aside, I've written a number of medium-sized programs in LabVIEW that implement entire data acquisition systems, including control of external instruments, positioning of mechanical parts, high voltage power supplies (no side effects, heh, sure thing), pulsed lasers (same), and a synchronous detector of my own design. I would also note that the data acquisition systems do not use any local or global variables (as LabVIEW uses those terms), so it could be argued that they are have a very high "functional purity," though that was not my intention when I wrote them.

My personal opinion is that the productivity claims of the FP camp are largely inflated. Maybe FP is better suited to problem domains that exist entirely inside the computer.