Comment by mbenjaminsmith | Hacker News Reader

Comment by mbenjaminsmith | Hacker News Reader

As a counterpoint I'll explain why I don't use Haskell.

I like Haskell. I like it in theory and I like playing around with it. I like the discipline it requires having to re-think "everyday" things in order to solve them in a new paradigm. I started with Python and then learned half a dozen other imperative languages so Haskell is utterly alien to me apart from the most basic concepts like recursion. I liken it somewhat to learning Vim -- you make the simple complicated and gain something in the process. Haskell is the number one language I wish I was working in at any given time.

So why am I not using Haskell? Most of my time is spent on OS X and iOS. While I could shoehorn Haskell into a project it doesn't make business sense to do so. I couldn't justify the extra time, complexity and I certainly couldn't justify it to a client. There simply is no good answer to "what about the next developer?" and other related questions. (I think this is why shoehorning a paradigm into an existing language is much better approach when you have a tight coupling of language and platform -- I'm thinking of RAC here.)

Give me something to work on where Haskell is the obvious choice and I'd be all over it. Until then it has to stay in the toy box.

But when you see a possible fit for Haskell (I would hesitate to make 'obvious' be the bar), have you tried to persuade or demonstrate the advantages? Why not find customers/areas that would be open to using Haskell?

To some people, unfamiliar technology is scary, possibly unacceptable, and often far from 'obvious'.

I don't like the metaphor or idea behind "you make the simple complicated". I prefer to say this: with functional languages, you name more things: mapping, folding, and so on, because you use them so often. Then you get comfortable thinking in higher-level ways. This means you can build on them more effectively.

> Why not find customers/areas that would be open to using Haskell?

I don't speak for him, but I don't because I don't want to do wrong by my customers. I don't do long-term support. I can maintain a heavily FP application (in Haskell or whatever else). Most programmers can't.

That it has its advantages is good for me. Those advantages make it even harder for normal people to get good development help.

> I don't like the metaphor or idea behind "you make the simple complicated".

When I say simple things I mean what's obvious for someone who programs primarily in imperative languages, like top-down, line by line execution in functions or local variables in functions. If you can take the same functions and understand them as operations on lists of things then both ways of looking at the problem are valid, though the latter won't be obvious without having the relevant experience.

> But when you see a possible fit for Haskell (I would hesitate to make 'obvious' be the bar), have you tried to persuade or demonstrate the advantages?

I have yet to. Again, I work primarily with Obj-C. Integrating Haskell would mean complicating a fairly elegant collection of tools and libraries. "Hey I like FP" isn't something I'm willing to sell to clients nor do I think it's the responsible thing to do. I go to great lengths to ensure that I'm delivering a product that could be understood by and maintained by developers with a wide range of experience / skill. Integrating a second language / paradigm into that without any clear gain would be counter to that.

> Why not find customers/areas that would be open to using Haskell?

For me it's really a chicken and egg thing. It's not easy for me to bring Haskell into my professional or even personal projects so I'm not experienced enough to go after primarily Haskell projects. What would make me consider it would be significant downtime caused by a lack of projects in the language(s) I'm already familiar with. Until that happens I'm not sure I'll make the jump.

I could possibly see writing libraries in Haskell but again it's hard for me to make that jump when I know I could write it faster in C/Obj-C because of my familiarity. What I like about Haskell (the type system, how succinct it is, functional purity) I can get most of the benefits of in Obj-C. I rarely if ever use dynamic types and I tend to write Obj-C (well, more and more these days) in a functional style by leveraging the relatively new addition of blocks.

> obvious for someone who programs primarily in imperative languages, like top-down, line by line execution in functions or local variables in functions.

This makes me angry at "ordinary" programmers. They think it's obvious, but they never rigorously modelled the sequential execution in the first place. Instead, they use their instinct. Instinct is efficient, but when it's wrong, tough luck.

This is probably why proving the correctness of a program is so difficult: you have to pin everything down mathematically, including sequences of side effects. For most people, that's much more difficult than merely relying on their guts. As a result, no one proves their programs. Maybe they test them.

With Haskell, you can't even program without pinning it all down mathematically. As a result, no one uses Haskell… OK, not no one, but still that's a significant barrier to entry.

I wish programmers were more mathematically aware. I wish they realised they're doing applied math, whether they like "math" or not. I'm tempted to blame our education, but I'm not sure it's the only culprit.

The best guess I've come up with is that anyone who is sufficiently mathematically inclined becomes a mathematician. I'm curious if anyone has any points/counterpoints in that direction.

Well, we do have computer scientists who have worked on program proof, cryptography, and type inference. Haskell (and earlier Miranda, and ML) where invented somehow.

Accepted, but they seem to be on either side of a dividing line — I'm doing my best to straddle it, but I'm still held back by a wall of language that is too often entirely impenetrable to me. I'm a very functionally-minded programmer, and I'm rapidly adapting to Clojure now (coming from rather functional JS, and having spent a rainy week on Haskell, which taught me basic type theory and such) — but I still often hit the wall of impenetrably abstract things too :(

It takes time. I used to read many Haskell related papers, and many things were impenetrable. Then, from time to time, one of them was suddenly obvious. Then another. And another.

The best advice I can give is, don't be content with words and labels. Search for the underlying structure. Take monads for instance. Lots of tutorials, lots of examples. But I didn't really got them until I read the Typeclassopedia: when you get to read the word "monad" you realize it was explaining the monadic structure in depth from the very start.

Practice also helps. Implementing a Parsec clone in Ocaml helped me understand applicative functors and monads. (I also experienced some of the disadvantages of strict evaluation.) You may want to try that in Clojure.

Finally, when something seems impenetrably abstract or obscure, that may be because you lack some basic vocabulary. For instance, you can't understand a paper on type inference if you don't know how to read type rules: https://en.wikipedia.org/wiki/Type_rules Which you can't read if you don't know what's an environment… As I said, it takes time.

Reply on news.ycombinator.com