I share the author's sentiment, and it's what lead me to Haskell. It's faster and cheaper for me to write prototypes in Haskell than it ever was in Ruby.
And at least in startup-world which is the bulk of my career, the speed at which you can build a reasonably robust prototype can be the life or death of a business, and this prototype usually ends up being the production product anyway. Prototypes are seldom rewritten "properly".
I’ve worked professionally in Haskell across three jobs (one huge corp, two start-ups), and seeing how bad Haskell functions in practice, when quickly mutating state to incrementally modify behavior is live-or-die necessary and under constant business pressures from product managers who don’t care about the paradigm of the backend.
I’ve found so many unexpected runtime errors in Haskell, behavioral bugs that require deep, stateful dependency injection to properly test for, type class designs that were set up wrong for some use case last year and now are horribly brittle and unmanageable to try to use it for the new use case that needs customer feedback immediately.
Plus, for all the syntactical niceties of Haskell, the code becomes unreadable the instant you start needing a dozen different GHC compiler pragmas all defining weird special behavior or syntax. Yet it’s just basic Haskell 101 these days to require new compiler pragmas for tons of basic functionality that you could get out of the box in other languages. Getting a whole team up to speed on how to mentally keep track of that from one section of code to the next is a very difficult chore.
My real life experience with Haskell is why I don’t use it professionally any more.
Hey mlthoughts2018, I've noticed a number of your comments have been exactly on the mark, even if they've been downvoted. I know you don't have your email in your profile, but if you'd like to discuss some ideas I have that aren't fully baked yet I'd appreciate your insight.
I'm zachaysan@gmail.com if so. If you're not (or too busy, etc) that's totally understandable. Don't feel like you need to explicitly decline.
I see. I guess I should rewrite my Haskell projects into something else then. Yes, I am more than satisfied with how quickly I can develop features according to business needs. Yes, I am more than satisfied with the [observed] robustness. Yes, these businesses are currently 100% of my income. But as you rightly point out, Haskell is bad. /s
A few things are interesting to me here:
1. How we've managed to come to such different conclusions despite supposedly having similar experiences
2. The vigour with which you attacked my rather innocuous comment
3. I had a look at some of your previous comments about Haskell, and you seem to repeat the same talking points over and over, almost verbatim. In fact, this comment you made is particularly interesting:
> it becomes the same shit code mess as any other paradigm.[0]
If what you say is true, then what is your argument exactly? If everything inevitably produces the "same shit code mess", then why are you attacking me for essentially saying "I like Haskell and it is working for me"?
I did not intend to “attack” you and I don’t believe that’s a good-faith characterization of what I wrote.
I do attest to this same criticism of Haskell from time to time because I believe it’s important to refute the very frequent, baseless claims that are often made on Hacker News that claim that functional programming or static typing can make any difference on the reliability or rate of defects in software: they cannot and do not.
I’m not at all trying to dissuade anyone else from using Haskell if they want to use it, and in fact I’d even go so far as to say Haskell is my favorite programming language.
As long as everyone checks the wild claims at the door, and we all admit that there is no difference in terms of safety, robustness, performance, reliability, readability, etc., between Haskell, Scala, Rust, OCaml, Python, Java, Go, Erlang, C++, C#, F#, C, FORTRAN, etc.
None of them is conceptually superior or dominant across a wide range of use cases. It’s just as easy to get hard-to-fix errors in all those languages, just as easy to categorically prevent other classes of errors, just as easy to design for compositional or extensible interfaces, etc.
As long as everyone is essentially willing to accept a No Free Lunch theorem about programming languages, then I don’t care what language people like to use or happen to prefer for personal reasons. I’m not attacking any such preferences.
But when there are unqualified comments about some paradigm or language (like functional programming, or Rust, or Julia, or Haskell, or static typing) being strictly better than some alternatives (like OOP or Python or C), then it’s worthwhile to counter that claim by pointing out that no, in fact, all those paradigms easily lead to the same problems and in no way offer any type of widely applicable solution to the usual problems of developing software.
> I did not intend to “attack” you and I don’t believe that’s a good-faith characterization of what I wrote.
You were recently warned by a moderator to stop making sarcastic and unsubstantive comments[0], so I don't think it's me who has trouble reading your tone.
> I believe it’s important to refute the very frequent, baseless claims that are often made on Hacker News that claim that functional programming or static typing can make any difference on the reliability or rate of defects in software: they cannot and do not.
Any comments I have made regarding the benefits of FP and static typing are anecdotal, and are therefore not baseless.
There's also anecdata like this[1], which further refutes the point you're repeatedly trying to make.
> and we all admit that there is no difference in terms of safety, robustness, performance, reliability, readability, etc.
That doesn't match my experience. My experience has been that it is cheaper for me to run my businesses on Haskell and Elm, as opposed to Ruby and [plain] JavaScript. I've tried both approaches, and I perceive a difference.
> As long as everyone is essentially willing to accept a No Free Lunch theorem about programming languages, then I don’t care what language people like to use or happen to prefer for personal reasons.
I'll accept there's no free lunch — my technology choices aren't a panacea. They do make a difference to my business however, and as a business owner I am perfectly within my rights to make that judgement call.
I don't see any attacks in what mlthoughts2018 wrote above. It's a strong critique of Haskell, sure, but there's nothing wrong with that, as long as it doesn't go into the programming language flamewar thing (which it didn't).
And at least in startup-world which is the bulk of my career, the speed at which you can build a reasonably robust prototype can be the life or death of a business, and this prototype usually ends up being the production product anyway. Prototypes are seldom rewritten "properly".