Standardized Ladder of Functional Programming [pdf]

I'm not talking about Haskell, i'm talking about Scala written in a functional style where we've used a lot of the concepts from Haskell. We're using it at Verizon for extremely large projects and it's working quite well. I know you've been pointed that out by others, so when you say there's no anecdotal data, how can you justify that? I've talked to others who work at extremely large corporations finding success with it too in extremely large projects.

I am not skeptical of type systems in general and TBH I've never worked on a large piece of software written in an untyped language (I often program in Clojure, but so far never a large system -- and yeah, I am skeptical about Clojure too even though I love it). But you're mistaken if you think I'm looking for quantitative studies; that's far too high a bar. I am looking for well-researched anecdotes, and there are plenty of them for type systems in general.

I am, however, very skeptical of the interpretation some people, especially in typed FP, give to types and the reasons they believe types provide a benefit. For example, the relationship between useful type systems and software correctness is not direct. I am currently using a formal verification tool that is completely logic based (and it has an interactive theorem prover, a model checker, and is backed by decades of careful mathematical analysis of its soundness) which is completely untyped, and yet it is as powerful as Coq for proving correctness of algorithms. If direct, formal, proofs of correctness is what you're after, types might not be the best solution. Types, however, have other clear benefits that are not related to formal correctness, or, at least, not correctness of global program properties.

Singlehandedly? Absolutely not. Why, am I the only Haskell skeptic you know? There are more on this page alone. There are even PLT researchers who warn against overselling results in PLT, and especially typed FP.

And we're not saving the industry; the industry as a whole isn't suicidal and will never bet too much money on unproven technologies. The industry isn't so fragile, but research is. Given the amount of money in the industry, even small parts that do bet on unproven tech can cause a funding surge followed by a research winter when the disappointment hits. We're saving Haskell.

If those who adopt Haskell do it with clear vision and not by believing some messianic claims, there would be no great disappointment and no research winter. Nothing is more dangerous to research than wild claims. You need to promise less and deliver more, not the other way around. And because the industry is competitive, it is actually quick to adopt ideas once they show actual significant benefit -- i.e., once they're ready. The industry adopted garbage collection almost overnight; it was almost 40 years after it had been invented, but almost immediately after it's been productized well enough to provide a significant advantage.

If pure-FP is really the way to go in general-purpose programming, eventually the industry will adopt it in some well-productized form. Getting there does require some early adopters, but they're already here and overselling doesn't help to get more good ones. It helps to get precisely those adopters who will end up causing a research winter.

----

What bothers me in terms of harm to the industry is the waste caused by people switching from one language to another, rewriting libraries over and over and thinning out the effort. I think we're losing years of progress. But there's really nothing I can do about that because even if I can convince someone that a language that is 1% "better" than another does not justify the effort of porting libraries over, there are already too many languages and platforms around, and there's always the question of, so which few languages should we pick, and why should it be the ones you like and not the ones I like. Haskell actually does not contribute much to this problem because its adoption rate doesn't yet make a dent.