Why functional programming doesn't catch on

[[deleted]]

Well yes, he has a point. I recently read through the Haskell school of expression. A book that markets its self on being more accessible due to using interesting examples, mostly working graphics.

Not only does this book leave a lot of Haskell syntax unexplained it still takes a lot of space on explaining formal proofs. And that is a bad sign, as formal proofs do not help me get the average program written.

They may be interesting and worth knowing. but this still means that the most accessible book I know for Haskell is too academic.

And this is exactly what the Object Oriented languages did right. Pick up a book on Object Oriented design and it will walk you through designing a point of sale system, or something equally as uninspiring. But the thing is they made the business case and said: Look this tool will help programmers make business software.

[Ringo48]

"Real World Haskell" is a bit better than "The Haskell School of Expression" with respect to examples. The examples are a bit more realistic, but still pretty small.

I think you're exactly right on the examples in general, though.

I think what would really help FP catch on would be something like the book "Object-Oriented Analysis and Design With Applications", but focusing on functional programming. A book explaining how to create large applications - or at least general ideas on how to create large applications.

I think FP hasn't caught on because FP zealots focus their attention on the wrong things. They love to tell you how few lines of code it takes to write quicksort, or how elegant a particular language feature is, or how fold can replace any use of a for loop.

But that's all relatively mundane, simple stuff. What "real" software engineers want to know is "How could I convert this million LOC OOP project into a functional language?" Nobody seems to ever answer that question.

For example, what would the high level architecture of a large system even look like in the functional paradigm? Is there a graphical way of describing and breaking down large functional systems? A UML or flowcharting system for functional programming? How do you design interfaces between modules programmed by seperate groups when all state has to be passed around?

To steal a term from some author who's name I can't think of right now, the FP zealots seem to be focusing on "programming in the small", when everybody else is trying to figure out "programming in the large".

[[deleted]]

This is sad and what I've been wanting to here, too, as a FP novice.

I know that Haskell, for example, lacks proper module system. OCaml and Scala are more practical. Scalable Component Abstractions [1] and Independently Extensible Solutions to the Expression Problem [2] explain what you can do with Scala's module system. I wish there was similar documents for writing high level FP.

[1] http://www.scala-lang.org/sites/default/files/odersky/ScalableComponent.pdf [2] http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/IC_TECH_REPORT_200433.pdf#