The Pretentious Haskell Phase

Someone drew my attention a “leaving Ruby for Haskell” rant from a few years ago. I thought I’d reprint my reply here.

For the record, I love Ruby and Haskell, and I am well aware that there are successful commercial projects written in Haskell. Part of me still wants to work on one.

I guess I’m jaded because I went through my own Pretentious Haskell Phase many years ago. Before I started working mostly in Ruby, as a matter fact. Back when the only free guide available was the ironically-named “Gentle Introduction“.

Every enthusiast programmer goes through it at some point. It’s similar to the Smug Lisp Weenie phase, but with more righteous anger about how people should be Prevented from Doing It Wrong.

And the thing is, there is nothing wrong about these arguments. I can argue right along with them. In fact, I can write the “leaving Ruby for Haskell” rant better than most, and without any disingenuousness.

Haskell is a beautiful crystalline palace. Everyone who has learned Haskell knows, in the back of their mind, that they are going to rewrite all this code in Haskell One of These Days. Really. Any day now. Next week, maybe.

A few have even tried. And really, it was terrific. It went much better than you might have expected.

I mean, it didn’t work out in the end. They have fuzzy memories of wandering around that crystal palace, repeatedly smacking nose-first into transparent panes of breathtaking beauty and diamond-hard ontological perfection. But they’re pretty sure that wasn’t Haskell’s fault. They just weren’t quite smart enough. They hadn’t studied enough type theory when they tried to use Haskell in practice. The libraries weren’t quite mature enough.

They’ll get back to it one of these days.

Potentially related: The Inescapable Pragmatism of Procedures.

6 comments

  1. I left Haskell for Ruby, kind of.

    Ruby is quite a fun place for a Haskell programmer, and I’ve really enjoyed the change. I still miss a few things from home though.

    It saddens me when I hear the “not smart enough” argument re: Haskell. Most people are smart enough, but maybe they are coming at it from the wrong direction, or they are jumping in at the deep end.

    Unfortunately, it is hard to know where to start and there’s a lot to sift through. A fair proportion of it leaves me cold too, if not worse – and I started with Haskell some time before monads were invented… This uncertainty is a serious problem, with no good answer yet IMHO.

    I did attempt an answer a few years back, via several articles in the PragPub house journal – starting with https://pragprog.com/magazines/2012-08/thinking-functionally-with-haskell. There might be some interesting pointers there.

  2. Well put, Avdi. I worked in Haskell for two years and the very often felt the panes of crystal against my nose, especially the first year.

    Some random thoughts (apologies for the randomness). Note that I haven’t programmed in Haskell in about four years.

    Haskellers are still busy figuring out types. It’s a new design space and there’s a lot of experimentation. Unfortunately, most of the libraries you find are from some point along an experiment. And it’s a big space so it will likely take a while.

    The whole idea that you’re not smart enough is a real thing, but I think it’s a thing in most languages. Most languages have WATs and we as experienced programmers pride ourselves on knowing how to navigate them. It’s really a shame. Just look at “accidentally quadratic”. Programming is just hard. The more we try to make it easier, say by defining a common operation as a method and giving it a nice descriptive name, the more opaque we make the abstraction. A method like “delete” on a collection is innocuous, but iterate through the collection, calling “delete”, and for some reason the loop gets real slow. What’s worse, it worked fine when you tested it. We blame the same cause: we’re not smart enough. We need to go back and study algorithmic complexity, perhaps do better testing. Unfortunately, I think Haskell only adds to the problem instead of trying to solve it. It “eliminates a class of errors” while inventing a new one.

    I don’t know what the answer is, but I believe we can find the questions that will get us there. OO and FP both are too based on mechanical notions.

    Eric

  3. I have a very different experience of Haskell, having deployed a few projects into heavy production use. There’s a lot of imperative-feeling programming using IO and mutable references, and the type system helps ensure that we’ve considered how that affects our computations. We don’t use zygohisto prepromorphisms or whatever craziness, but we do factor out common bits to allow for good code reuse.

    Haskell doesn’t feel like a glass palace to me. It feels like a house made out of bricks, but the bricks aren’t cemented in, and you can temporarily turn off gravity and move huge parts of the house around. You won’t be allowed to turn the gravity back on until the building is structurally sound though. Programming in Ruby, PHP, or JavaScript all feel like building a house out of adobe — it’s more freeform and flexible, but I have to be extremely careful in considering how everything fits together, and I have basically no help to ensure I get things right. Making any underlying changes is possible, but it’s so easy to screw everything up.

    I can understand how people feel that they’re not smart enough for Haskell. I don’t feel smart enough for Ruby. I don’t think this is a reflection on the tools we use, but rather how our brains and mindsets adapt to the tools we use.

Leave a Reply to Eric Normand Cancel reply

Your email address will not be published. Required fields are marked *