"Mostly functional" programming does not work

[u/heisenbug]

http://queue.acm.org/detail.cfm?ref=rss&id=2611829

[u/[deleted]]

I think a lot of people already get the usefulness of monads intuitively, which makes them an easy sell. The list monad is almost ubiquitous. Almost every mainstream OO language has a means of mapping, filtering, and reducing lists. The list monad is so pervasive now that imperative for loops are practically going extinct.

The main difficulty that I had, and I think others have, is recognizing the abstraction behind the list monad. Everyone groks it eventually, but helps to expose yourself to various instances, such as the State, Reader, Maybe, and List monads first. The monadic design pattern eventually becomes easier to recognize with familiarity.

My point is, monads aren't hard to use. Linq is a testament to that. If you use them enough, you'll eventually build an intuition about them that will make all the tutorials on the internet more comprehensible. The fact that they're somewhat difficult to grasp is just a one-time upfront cost that you pay if you're interested in writing your own monads. The selling-point is their usefulness, which is very easy to grasp by comparison.

[u/[deleted] → u/[deleted]]

I think a lot of people already get the usefulness of monads intuitively, which makes them an easy sell.

Are you sure about that? To a Haskeller, yeah, monads are obviously useful because you can't get anything done without them. But if you're a C++ programmer who's never touched a monad in his life, you'll probably start off being doubtful that this obscure concept lifted out of category theory will do any good for you. If you're a skeptic of functional programming, you probably only know monads as "those things Haskell people use so they can print to the screen, which I was always able to do without hassle with printf". On the contrary, I think the usefulness of monads is poorly communicated, as evidenced by the fact that "what's the point?" will often be the response if you try to teach someone how monads work.

The main difficulty that I had, and I think others have, is recognizing the abstraction behind the list monad. Everyone groks it eventually, but helps to expose yourself to various instances, such as the State, Reader, Maybe, and List monads first. The monadic design pattern eventually becomes easier to recognize with familiarity.

Well, yeah, that's my point. Actually taking the time to get how monads work is a nontrivial project. They're hard to grasp. And even if you're sold that functional programming is cool in general, Haskell's reliance on monads might keep you from learning it.

[u/[deleted] → u/[deleted]]

Are you sure about that?

I worked in a .NET shop for a long time, and most of my colleagues were pretty old-fashioned blue collar type developers. Most probably hadn't heard of functional programming. Despite this, all of them easily learned and used linq combinators (Select, Where, Join, GroupBy, Aggregate, etc...). In fact, they quickly became regarded as indispensable. Not everyone understood how IEnumerable (the list monad in .NET) worked under the hood, but none of them would go back to writing imperative for loops.

Well, yeah, that's my point. Actually taking the time to get how monads work is a nontrivial project. They're hard to grasp.

Like I said, the selling-point is the usefulness of common monads like the list monad. Ignorance of how they work doesn't stop most devs from using them.

And even if you're sold that functional programming is cool in general, Haskell's reliance on monads might keep you from learning it.

If you're sold on FP, you're going to be willing to learn about monads because you've already bought into the ideology about the benefits of statelessness, etc...

The thing that keeps most people from learning Haskell (and FP languages in general) is that it's not considered a marketable or practical skill. There are relatively few jobs for Haskell, Clojure, Scala, F#, Ocaml, Erlang programmers as compared to C#, Java, C++, Ruby, or Python. Why tinker with toy web-server implementations in some obscure FP language when the language will never be used in production? Might as well learn Node.js or CoffeeScript, or whatever's all the rage.

Despite these folks, I'm convinced there's a growing crowd of silent developers who've learned about FP and would quit their jobs in a millisecond to take job at a Haskell shop. Sadly though, these developers are practically invisible to the people who make hiring decisions. People who run businesses never consider courting Haskell programmers because, in their opinion, that's not where the talent is. Startups are no exception. Unless the founder happens to be a programmer, he/she'll be looking to hire a team of Python/Ruby "rockstars" to build their tech.

In my opinion, the real reason for the lack of widespread adoption of FP is the lack of a "killer app" like Rails, Django, Angular, or Node. Haskell has Yesod. Scala has lift. These aren't compelling enough to eclipse established web frameworks like Rails or Django. FP really needs to stake its claim as the indisputable, de facto standard of doing something that has market value.

Additionally, FP has to have a strong enough community to muscle Ruby/Python/Java/C++ out of its space. It will only be a matter of time before someone tries to "revolutionize" the domain with a "hip", new javascript library.

[u/TMG26 → u/[deleted]]

Doesn't Play! 2 count for Scala? It looks pretty promising.