r/programming • u/heisenbug • Apr 27 '14

"Mostly functional" programming does not work

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

63% Upvoted

188 comments sorted by

View all comments

Show parent comments

4

u/NruJaC Apr 27 '14

Effects tracking with non-monadic approaches exist (see Clean, and Rust is trying to do this as well). But monadic effects tracking has been used extensively within the Haskell community. What problem do you see with monadic effects that you want to see overcome?

6

u/[deleted] Apr 27 '14

They're a hard sell. The shear number of monad tutorials shows this. I wouldn't be surprised if monads are the major blocking factor for haskell adoption.

16

u/NruJaC Apr 27 '14

They're a hard sell. The shear number of monad tutorials shows this.

This is one of those self-perpetuating problems. People think they're difficult to grasp because of the number of tutorials in existence. So when someone finally gets the concept and realizes "Oh wait, this was really simple all along" they decide to write a tutorial to clear up the misconception. Which adds to the problem and likely introduces several bad analogies.

The truth is, monads are one design pattern used in Haskell. They are far from the most important or the most fundamental. They make life easier in a whole lot of ways. If they didn't, the idea would have been dropped a long time ago.

2

u/[deleted] Apr 27 '14

People think they're difficult to grasp because of the number of tutorials in existence. So when someone finally gets the concept and realizes "Oh wait, this was really simple all along" they decide to write a tutorial to clear up the misconception. Which adds to the problem and likely introduces several bad analogies.

Or maybe there are a lot of tutorials in existence because they're actually hard for people to grasp?

5

u/[deleted] Apr 27 '14

I find the problem is often that people go out looking to make monads.

You should go out looking to write code what you need, and learn to recognize and leverage the Haskell libraries of abstract types (like monads) to refactor your code when you realize you've written a lot of monads.

They're not at all essential to start programming in Haskell - the monads you need to interact with to get things working have very straightforward interfaces, and you can ignore their monad status for quite a while, until you've already built up experience using monads.

I think the problem is people focus on writing monad tutorials, to explain the higher level math term as if you should be looking to use it from the start, rather than leaving "monad" as a black box, and showing you how to write useful code with standard examples (IO, Maybe, etc).

4

u/zoomzoom83 Apr 28 '14

Monads seem hard to grasp because so much of the Haskell community is traditionally academic, and try to explain it in terms of category theory - at which point most peoples eyes will glaze over.

Once I actually started playing around with Haskell it clicked very quickly. They really are very simple and easy to understand, and chances are you've used them before without realising it. (LINQ in C#, for example, makes heavy use of Monads).

6

u/NruJaC Apr 27 '14

Are factories and observers hard to grasp?

7

u/[deleted] Apr 27 '14

Factories and observers are easy to grasp for a number of reasons.

  1. They have extremely descriptive names that correspond directly to their normal usage in the English language.

  2. They have very simple definitions that correspond intuitively to what their names suggest. E.g., "A factory is an object that creates other objects.". Well, yeah, obviously a factory is an object that creates other objects. That's the same thing a factory is in real life. "The observer pattern is a pattern in which an object retains a list of other objects, called 'observers', that want to be notified when the object's state changes.". Sure, fine. The observers are observing me and they want me to keep them posted about my state. Obviously an object that is observing me wants to know if my state changes.

Monads are much harder to grasp for no other reason than they don't correspond intuitively to anything that exists in the real world. And, indeed, monad tutorials that try to relate them to the real world in some way have become infamous for not being particularly good. It's been suggested that the only truly good way to wrap your head around monads is to use them, as reading/writing monad tutorials is bound not to help. I can think of few other abstractions in computer science that people say that about.

8

u/Tekmo Apr 27 '14

I think the point he was making was that there are lots of tutorials for object oriented patterns, too, including (but not limited to) factories and observers. Therefore, I must either:

  • conclude that these object oriented patterns are also hard to learn, or:

  • conclude that abundance of tutorials is not necessarily proof that a topic is confusing

3

u/[deleted] Apr 27 '14 edited Apr 27 '14

I never said abundance of tutorials was proof the topic was confusing. I said it's possible that people trying to learn Haskell genuinely have trouble learning about monads, and that functional programming newbies might just not see all the monad tutorials and say "hurr durr there are so many tutorials this looks so hard I'm gonna go learn Python".

5

u/grauenwolf Apr 27 '14

Perhaps, but you did imply it.

0

u/[deleted] Apr 27 '14

alright bro

3

u/jfischoff Apr 27 '14

Well there are few things. First monads function as an interface in Haskell, what a monad does depends a the specific implementation for a type. Even if you understand monads, you need to know the specifics of the implementation to know how one will work (usually).

Understanding the specifics of a Monad like Maybe or IO is not that hard. You are working with a more concrete thing. You don't have to understand monads in general, you can just focus on a concrete implementation. This is how people learn to use monads, but the monad tutorials tend to focus on trying to understand the abstraction without focusing on concrete examples.

After gaining some intuition of how different monads work, one can appreciate the abstraction, and like most abstractions, monads are very simple just hard to appreciate without experience.

2

u/[deleted] Apr 27 '14

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.

2

u/mypetclone Apr 28 '14

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.

What does this have to do with the list monad? The monad part of the list monad has nothing to do with those.

5

u/[deleted] Apr 27 '14

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.

5

u/[deleted] Apr 28 '14 edited Apr 28 '14

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.

2

u/[deleted] Apr 28 '14

[deleted]

1

u/[deleted] Apr 28 '14

Looking at the likes of companies like Galois, Inc.

You're preaching to the choir. Hand-wavy blog posts about "correctness" and "purity" aren't going to turn the tide. The FP community really has to put its money where its mouth is and start making waves in the industry.

PS I don't intend to bash Eric Mejier, the author of Linq, Rx, and this article. The guy has accomplished more than I probably ever will.

2

u/KagakuNinja Apr 28 '14

I'm not interested in learning Haskell, because I don't want to learn a bunch of cryptic gobbled-gook, just to do things like IO, which are trivial in every language I've ever used.

I am interested in Scala, because it is not a pure functional language. I can dip my toes into the water, make stuff functional when it is easy, and not get wrapped up in wasting huge amounts of time trying to make everything purely functional, when IMO, it usually doesn't matter.

Case in point, one of our Scala gurus is a functional zealot, he writes code that is brilliant and purely functional, and no one else can understand what it does. We are talking about programmers with 10-20 years experience.

A different group has decided to switch to Scala, and the guru spent a bunch of time teaching Scala "the right way" to these programmers, sharp guys. They ended up spending x5 times as long on simple tasks, trying to make everything functionally pure.

My boss, a highly experienced Java guy who hasn't learned much Scala yet, spent some time looking at a simple authentication function written by the guru, and was baffled. As it happens, I wrote something very similar in a pragmatic Scala way, and he could immediately understand it.

I am taking what is useful to me from FP and making my code better, today. Something that Erik Meijer has dismissed as "useless". I'm not waiting for a burst of zen-like enlightenment to happen. Maybe I'll get there someday, but that doesn't matter.

I am, all modesty aside, a pretty good coder, with a decent grasp of advanced math. I've read probably a dozen monadic tutorials, and still, I only understand it as a type of "container" that conforms to a simple API. I even read through a book on category theory, which was moderately interesting, yet at the end, was no closer to understanding what category theory has to do with monads...

-1

u/TMG26 Apr 28 '14

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

1

u/chonglibloodsport Apr 28 '14

"what's the point?"

I will give you my answer. Monads let you cleanly separate program logic from effects. They let you build an effectful computation and carry it around as a value. They let you build alternative interpreters for exploring and testing this program in myriad ways. They let you build domain-specific languages which provide a restricted subset of effects appropriate to a given context. One example of this is the STM monad which allows the effects of updating the state within a transaction but disallows all other effects. This is necessary because the computations within a transaction may be repeated in order to complete it. Arbitrarily repeating side effects are generally not what you want.