
I tried Haskell for 5 years - sndean
https://metarabbit.wordpress.com/2017/05/02/i-tried-haskell-for-5-years-and-heres-how-it-was/
======
arnon
We have a code base of roughly 200,000 lines of Haskell code, dealing with
high performance SQL query parsing, compilation and optimizations.

I only remember one situation over the past 5 years that we had a performance
issue with Haskell, that was solved by using the profiling capabilities of
GHC.

I disagree that performance is hard to figure out. It could be better, yes -
but it's not that different than what you'd get with other programming
languages.

~~~
zzalpha
_but it 's not that different than what you'd get with other programming
languages._

Until you have to solve a (maddeningly common) space leak issue. That's a
problem unique to lazily evaluated languages (basically Haskell) and is
godawful to debug.

It reminds me of solving git problems... you suddenly find yourself having to
tear back the abstraction layer that is the language and compiler and start
thinking about thunks and so forth.

It's jarring and incredibly frustrating.

~~~
eximius
I find this response a little ironic because we don't really see complaints
about knowing the C runtime and C compiler when performance becomes a problem,
which is also jarring and frustrating. But, ultimately, sometimes languages
have failings and we need to peek under the hood to figure out how to address
it - we're just more comfortable with the relatively common and direct mapping
of the C runtime.

I am not experienced enough with Haskell to know whether peeking under its
hood involves a more complicated model or not. It might be more frustrating.
But its certainly not a unique experience - it's costs are just less
distributed over other runtimes.

~~~
Veedrac
When have you ever had the C runtime be the cause of a performance problem?

~~~
adrianN
Writing a custom replacement for malloc is relatively common. Does that count?

~~~
zzalpha
_Writing a custom replacement for malloc is relatively common._

You... can't be serious. That's common to you?

~~~
adrianN
Yes? From the Wikipedia:

"Because malloc and its relatives can have a strong impact on the performance
of a program, it is not uncommon to override the functions for a specific
application by custom implementations that are optimized for application's
allocation patterns."

~~~
zzalpha
"not uncommon" is far far from "common". If you're writing your own malloc
replacement you're pretty deep into the weeds of high performance computing.
Heck even just deciding to replace the stock implementation with an off-the-
shelf replacement puts you in fairly rarified company. I'd wager the vast
majority of software written for Linux makes use of the standard glibc
allocator.

I expect high performance games are the most common exception, but they
represent a fraction of the C/C++ in the wild.

Space leaks in Haskell, on the other hand, are unfortunately relatively easy
to introduce.

------
choxi
If anyone's curious to try out functional programming, I would highly
recommend Elm. I haven't been so excited about a language since I went from C
to Ruby ten years ago, and Pragmatic Studios has a great course on it (I have
no affiliation):
[https://pragmaticstudio.com/courses/elm](https://pragmaticstudio.com/courses/elm)

~~~
pivotal
I spent some time working through various Haskell books with varying success,
then decided to do a code challenge (adventofcode.com) using Elm. I didn't
finish, but after writing Elm for many days on end, suddenly Haskell clicked a
lot more. The Elm compiler is far more friendly than Haskell's and will walk
you through a lot of rookie mistakes and oversights.

I find Elm exciting, and with the prevalence of React/Redux these days, a lot
of front end developers would be wise to familiarize themselves with the
origin of many of the concepts borrowed from Elm.

~~~
nickpeterson
I bought a few Haskell books but could never really grok it. In the last
couple years I started learning f# and have found it's an incredible "intro to
Haskell" language. I opened one of my Haskell books the other day and realized
I understood everything much more quickly.

~~~
insulanian
F# is a beautiful, pragmatic, functional programming language. It's a shame
some people dismiss it due its Microsoft origins.

~~~
nickpeterson
Yeah, F# feels like Don Syme looked at ocaml and haskell and applied a bit of
yagni and tossed in some other useful conventions (I'm sure many others were
involved as well).

It drives me crazy that Microsoft doesn't push it harder from an investment
perspective. They don't even write books about it :)

~~~
comp1927
There are books out there. For new language adoption, F# do have new features
like Type Providers. However, it's not the best language in X for X in ['data
science', 'distributed system'] etc.

~~~
nickpeterson
Sorry, my language was vague. There are many F# books, but I find it telling
that Microsoft Press doesn't really write books about it. Look at C#, VB.Net,
Office, SQL Server, Sharepoint, etc. Almost everything has a new book (or 10)
every new edition. F#? Nothing.

------
gjkood
Question to the Haskell experts here.

Is Haskell more academic in nature or used heavily in Production environments?

Is there an application sweet spot/domain (say Artificial Intelligence/Machine
Learning, etc) where it shines over using other languages (I am not talking
about software/language architectural issues like type systems or such)?

I have no experience with Haskell but do use functional languages such as
Erlang/Elixir on and off.

~~~
platz
> _Is there an application sweet spot /domain_

State of the Haskell ecosystem: [https://github.com/Gabriel439/post-
rfc/blob/master/sotu.md](https://github.com/Gabriel439/post-
rfc/blob/master/sotu.md)

    
    
        The topics are roughly sorted from greatest strengths to greatest weaknesses. 
        Each programming area will also be summarized by a single rating of either:
    
        Best in class: the best experience in any language
        Mature: suitable for most programmers
        Immature: only acceptable for early-adopters
        Bad: pretty unusable

~~~
harry8
The state of the Haskell ecosystem is that it is amazing at encouraging people
to write libraries, especially libraries to assist in writing haskell code but
amazingly bad at encouraging people to write actual programs, especially
actual programs useful for something that isn't writing code.

Take out the programs that are for writing code, ghc, shellcheck, darcs etc.
And what are you actually left with? git-annexe, pandoc, xmonad is hledger
worth knowing about if you don't care what language it was written in? (Maybe
it's amazing, first I've heard of it).

Whenever I bring this up, people find it upsetting. The Haskell community
might need to get past both of those things. 1.0 was 27 years ago. So many
fabulous programmers have gone down the road for entertainment or
enlightenment so where are your damn apps if you're a language that doesn't
suck for writing them, no really, where are they?

~~~
platz
I believe a similar dynamic exists with many of the expressive high-level
languages; this is probably not an issue unique to the Haskell community.

For example, I think many would struggle to name many open source user
application written in Clojure as well.

------
hzhou321
> 1\. There is a learning curve.

Time and experience can cover up anything. So this does not say much about
Haskell other than it is all negative without time and experience.

> 2\. Haskell has some very nice libraries

So does NodeJS and (on an abstract level) Microsoft Word. Libraries are
infrastructures and investments that (like time and experience) can cover up
any shortcomings.

> 3\. Haskell libraries are sometimes hard to figure out

That is simply negative, right?

> 4\. Haskell sometimes feels like C++

That is also negative, right?

> 5\. Performance is hard to figure out

That is also negative, right?

> 6\. The easy is hard, the hard is easy

That is a general description of specialty -- unless he means _all hard_ are
easy.

> 7\. Stack changed the game

Another infrastructure investment.

> 8\. Summary: Haskell is a great programming language.

... I am a bit lost ... But if I read it as an attitude, it explains a lot
about the existence of infrastructure and investment. Will overcomes anything.

~~~
tetrep
> The line that if it compiles, it’s probably correct is often true.

That is the meat of why Haskell is so great. I've never so reckless refactored
code as much as I do in Haskell, I just wait for the compiler to tell me what
I missed and go back and fix it up. I'd _never_ do that in C, C++, Java, etc;
it'd be suicide.

And while that's still not a great fleshed out explanation, it's a great
oversimplification of the symptoms of a programming language with a great type
system. And that type system is more or less the only reason to use Haskell.

As other people in this thread have commented, Haskell has fantastic abstract
libraries, which let you do abstract things, the most useful of which that I'm
aware of/understand is parsing. Parser combinators are a very natural fit for
Haskell, and making DSLs with them becomes practically trivial to do.

Edit: I think the author takes for granted the general praise that Haskell
gets, and was attempting to temper it with his practical experiences using the
language.

~~~
Merad
> I've never so reckless refactored code as much as I do in Haskell, I just
> wait for the compiler to tell me what I missed and go back and fix it up.
> I'd never do that in C, C++, Java, etc; it'd be suicide.

That's precisely what I was doing at work today in a C# project. I was going
particularly crazy today, doing some refactoring with project wide regex
replaces rather than leaning on VS/Resharper for everything.

I think it depends a lot on how your project is structured. If you're passing
around object everywhere and casting... you're gonna have a bad time, sure.
But at that point you're practically using Python or something. If you're
using generics and so on properly, then you can lean on the compiler and type
system quite a lot.

~~~
iEchoic
Yup, C# codebases (especially w/ tools like Resharper) can be massively
refactored and, in my experience, almost always work perfectly as long as
there are no compilation errors. C# tooling is fantastic.

------
throwaway110034
I will never, ever use Haskell in production because of its default evaluation
strategy, the wrongness of which was tacitly conceded not long ago with the
addition of the strictness pragma (which only works per-module) to GHC.

I think it's especially telling that its community skews so heavily towards
this blogger/monad tutorial writer dilettante demographic rather than the D.
Richard Hipp/Walter Bright 'actually gets real work done' demographic. I know
which of the two I'd rather be in. Haskellers are even worse than Lispers in
this regard. For the amount of noise about Haskell, you'd expect to see high-
quality operating system kernels, IDEs, or RDMBSs written in it by now.
Instead its killer apps are a tiling window manager, a document converter, and
a DVCS so slow and corruption-prone even they avoid it in favor of Git.

~~~
Buttons840
Would you also feel that a strict-by-default language which adds support for
lazyness is a tacit admission that strict-by-default is wrong?

~~~
throwaway110034
How would you feel if Common Lisps suddenly started sporting infix operator
notation?

Haskel's alien, counter-intuitive evaluation strategy was actually marketed
(circa 2010) as a powerful performance-enhancer that facilitated optimizations
that were difficult if not impossible to do in a strict language like C.
Instead, it ironically tends to cause more performance problems than it
solves, with hard-to-debug spaceleaks capable of taking down production
systems.

The entire Miranda branch of the PL tree is likely going to prove to be an
evolutionary dead end, and Haskell will eventually lose out to Idris or some
other strict language. And I don't think it's a coincidence that the
strictness pragma (which does not even give you a strict program) was added
soon after Idris and the rest started getting traction.

~~~
Jach
> How would you feel if Common Lisps suddenly started sporting infix operator
> notation?

You mean like this? (I linked it the other day.)
[https://github.com/rigetticomputing/cmu-
infix](https://github.com/rigetticomputing/cmu-infix) But one might argue that
the prefix notation + macros being able to support such a library is just
further testament to their use as default...

------
m-j-fox
> very hard to understand why a function could be useful in the first place

So true.

[https://hackage.haskell.org/package/base-4.9.1.0/docs/Contro...](https://hackage.haskell.org/package/base-4.9.1.0/docs/Control-
Monad-Fix.html)

> mfix :: (a -> m a) -> m a

> The fixed point of a monadic computation. mfix f executes the action f only
> once, with the eventual output fed back as the input. Hence f should not be
> strict, for then mfix f would diverge.

But why tho?

~~~
ashark
Ubiquitous single-letter symbols mapping to who-knows-what possible things,
pnflly abvted fncn nms, and unclear motivations for code are what I've bounced
off of with Haskell every time I've tried to dig in. The community seems to
have adopted all the worst parts of mathematics culture, along with whichever
good parts they've brought in.

~~~
wereHamster
Serious question. In the following code, what would be better function / type
names? (or you can pick another bit of Haskell code that you know and/or have
particular trouble understanding).

    
    
        class Foldable t where
            foldl :: (b -> a -> b) -> b -> t a -> b

~~~
nimih
Maybe something like:

    
    
      class Foldable myFoldable where
        foldl :: (summary -> element -> summary) 
              -> summary 
              -> myFoldable element 
              -> summary
    

This is the translation I do in my head when I read that type signature, at
least.

~~~
ashark
Wow. That's much better.

Apparently-idiomatic Haskell reads (or, rather, doesn't) about like line-
noise/code-golf style Perl to me.

~~~
jinfiesto
The problem with this is that there are Foldables that do not behave in the
way that is implied by the above re-write of the parameters.

I think this is kind of the problem when you are really high up in
abstraction-land. The functions that you're using are so generic that it's
hard to say that they operate on anything in particular, except that the
arguments fulfill certain properties or laws.

------
jes5199
Haskell: where difficult problems are trivial, and where trivial problems are
the subject of ongoing academic research

~~~
tathougies
> and where trivial problems are the subject of ongoing academic research

Like what?

~~~
hzhou321
I am not holding that (joke's) view, but monad came to mind as an ongoing
academic research (to original Haskell at least) in order to solve a rather
trivial stateful programming (trivial in an imperative style). To generalize
that example, there are solutions that are trivial to express in an imperative
style but seems convoluted in pure functional programming. How to retain the
trivialness are subject of ongoing academic research.

EDIT: To be specific, I can think about the example of machine efficiency that
can simply be specified literally in C but it is uncertain and opaque in
Haskell.

~~~
tathougies
This confuses me. You don't really need monads to perform io or specify
sequencing in Haskell, although do notation is very convenient for sequencing
sctions.

Ultimately, if you want imperative style, you can just write imperative code
that's well typed in Haskell.

~~~
hzhou321
> You don't really need monads to perform io or specify sequencing in Haskell.

By implying certain logic dependence? It would be rather un-natural, which I
assume is the reason for the invention of monad.

> Ultimately, if you want imperative style, you can just write imperative code
> that's well typed in Haskell.

It is not just a style. There are logic implications. In imperative
programming, the states are always assumed. That is, the operations are
assumed to have different effect switching orders. Note this is a much
stricter assumption than the alternative that some/all operations are
stateless. The benefit of such stricter confinement provides certain
convenience. For example, because the order of instruction is meaningful and
can convey ideas, contexts can take place, and local ideas can be focused
(rather than carrying the whole states). In the real world (compared to the
mathematical world), most action affects vast states that are impossible to
quantify, and we (as an adaptive species) are well adapted to stateful
imperative thinking. How do you perform rigorous logic thinking when the
inputs (states) are never complete?

In computer programming, the states can always be fully described. However, if
you always want to fully describe your states, you'll either restrict your
functions and programs with limited states (input/output) or you will be
constantly writing cumbersome functions/programs with a long description of
all its states. The solution is to share and imply some of those states in the
types, monad, for example. So yes, monad is not strictly a necessity but a
convenience. Since Haskell never makes assumptions of hidden states, merely
imitating an imperative style is still not imperative programming. Because the
states are still not assumed, but rigorously specified and carried. So even
with a seemingly similar code style, the cognitive process in Haskell and a
conventional imperative language is very different.

Which is better? It depends. If you are holding the view that everything
computer solves are mathematical problems, or when you are solving
mathematical problems, certainly you would think only Haskell's approach makes
sense. On the other hand, if you understand that computers are merely a tool
for solving real-world problems, then you are often not looking for
mathematically correct answers but practically good enough solutions.
Practically good enough solutions allow room for shortcuts or undefined
behaviors. Embracing these uncertainties (shock to mathematicians) allows for
efficient means. Under the latter context, a pure mathematical restriction can
be a burden rather than help. The latter approach, in fact, carries much more
complexity. For example, calculating pi to one millionth digit. In functional
approach, it is solving a mathematical problem and a correct answer is what
you looking for. In imperative approach, memory cost, speed efficiency,
various shortcuts are all part of the consideration and part of solution. It
is not always just the answer matters, how you get the answer also matters.
But do they really matter? It depends.

Real programming is often a mixture of both -- in C or in Haskell. C defaults
to imperative style with explicit stateless when needed. Haskell defaults to
stateless with explicit stateful when necessary. Trivial in one is difficult
in the other.

------
matt_wulfeck
> _The same is not true of Haskell. If you have never looked at Haskell code,
> you may have difficulty following even simple functions._

Why is it that people talk about this almost as if it's done virtue of the
language? As if the fact that's it's so inscrutable proves that it's valuable,
different, and on a higher plane of computing.

~~~
tikhonj
The point is that it's not _inherently_ inscrutable—it's different. And being
different _is_ a virtue: at the very least, you'll learn something from
Haskell, and it's going to let you do things other languages won't. It's not
just an Algol reskin.

~~~
tormeh
If it had Algol syntax and Algol naming conventions it might actually have
succeeded outside of academia. The decision not to go with an Algol-derived
syntax was probably the biggest mistake ever done in Haskell's design.

~~~
dllthomas
Maybe... I'm not convinced the semantics would feel as good in that setting.

------
fizixer
Wow, really good writeup. And on point regarding '5 days' vs '5 years'
approach.

And it really confirms my biases against the language.

------
dmix
> The easy is hard, the hard is easy

Probably the best single line description of Haskell.

The learning curve helps with the former (easy) part, the latter (hard) part
contains some really brilliant ideas where you start to wonder why so many
people still use other languages for everything, then you remember how hard
the easy stuff can be...

------
nicolashahn
I don't think it takes 5 years to learn this stuff. Nothing stood out to me
and I only used Haskell for 10 weeks for a single college course 2 years ago.
It's all true though.

------
devrandomguy
> _Types / Type-driven development Rating: Best in class_

> _Haskell definitely does not have the most advanced type system (not even
> close if you count research languages) but out of all languages that are
> actually used in production Haskell is probably at the top._

What are these other research languages, that have such incredible type
systems? Do they usually have implemented compilers, or would they only be
described in an abstract form? Can I explore them for fun and curiosity?

~~~
tines
The fact that he mentions type driven development probably means that he has
dependent typing around, probably as seen in the language Idris, whose
recently published book is called the same. Idris is very much not just an
abstract language.

~~~
devrandomguy
Yes, the author mentioned Idris shortly afterwards, but I get the impression
that this is just the tip of an iceberg. Idris was presented as the one
example that is most likely to evolve from a research-only language, to a
production language.

~~~
dllthomas
There's also agda and coq, at various points on the spectrum between
programming language and theorem prover.

------
KirinDave
I strongly agree with most of this. I've been so pro-Purescript because I
think we need a break from Haskell into something new but related. Haskell is
great, but has so much baggage it's tough to enter into.

------
Maro
I have tried to use Haskell a number of times in the past ~5 years for small-
scale projects and witnessed others try to use it, and most of these projects
(actually I think all) have resulted in failure / rewrites in more
simple/plain-vanilla languages like Python/Go. I keep thinking Haskell is
interesting, but at some point I had to force myself to stop investing time in
it because I kept concluding it's not a good investment of time for a move-
fast/practical person like me. I again had to remind myself when I read this
post.

Some reasons I remember for the various failures, in no particular order:

\- steep learning curve = experienced (in other languages) programmers having
a tough time not being productive for weeks/months in the new language, with
no clear payoff for the kind of projects they're working on

\- sometimes/often side-effects/states/global vars/hackyness is what I want,
because I'm experimenting with something in the code; and if I'm not sure if
this code will be around in 3 months, I want to leave the mess in and not
refactor it

\- in general, I think all-the-way pure no side effects is too much; I think
J.Carmack said sth along the lines: Haskell has good ideas which should be
imported into more generally useful languages like C++/etc, eg. the gamestate
in an FPS game should be write-once, it makes the engine/architecture easier
to understand (but in general the language should support side-effect)

\- I found the type system to be cumbersome: I kept not being able to model
things the way I wanted to and running into annoyances; I find
classes/objects/templates etc from the C++/Java/Python/whatever world to be
more useful for modeling applications

\- when the spec of the system keeps changing (=the norm in lean/cont.delivery
environments), it's cumbersome/not practical to keep updating the types and
deal with the cascading effects

\- weird "bugs" due to how the VM evaluates the program (usually around
lazyness/lists) leading to memory leaks; when I was chasing these issues I
always felt like I'm wasting my time trying to convince the ghc runtime to do
X, which would be trivial in an imperative language where I just write the
program to do X and I'm done

\- cryptic ghc compile errors regarding types (granted, this is similar in C++
with templates and STL..)

\- if it compiles it's good => fallacy we kept running into

\- type system seemed not a good fit for certain common use-cases, like
parsing dynamic/messy things like json

Working at Facebook for the last year and seeing the PHP/Hack codebase which
powers this incredibly successful product/company has further eroded my
interest in Haskell: Facebook's slow transition from PHP to Hack (=win) shows
that some level of strictness/typing/etc is important, but it's pointless to
overdo the purity. Just pick sth which is good enough, make sure it has
outstanding all-around tooling, have good code-review, and then focus on the
product you're building, not the language.

I'm not saying Haskell is shit, I just don't care about it anymore. I'm happy
if people get good use out of it, clearly there are problem spaces that are
compact, well-defined and correctness is super-important (like parsing).

~~~
dllthomas
> \- when the spec of the system keeps changing (=the norm in
> lean/cont.delivery environments), it's cumbersome/not practical to keep
> updating the types and deal with the cascading effects

Interesting. I find that one of the best parts of Haskell. If I expose the
assumptions I've relied on in the types, then when those assumptions break I
have tremendous help knowing what code must change to deal with it.

------
nabla9
> Performance is hard to figure out

1000x changes in performance is not a problem if:

1\. Performance of one module is not overly dependent on the code that uses
it.

2\. Performance never degrades order of magnitude with new compilers.

------
dlwdlw
The thing with enlightenment level ideas isn't that they aren't enlightening
but that they attract hype. Individuals pretending to be enlightened if you
will.

A scientific mindset as well as liberalism are also ideas where new proponents
often want to draw a line in the sand to stratify people into superior and
inferior. The original proponents were chasing a higher level of quality for
all, but the need for social stratification weaponizes and gates ideas.

~~~
highwind
I'm confused. Can you tell me how your comment relates to the article?

The author of the article is sharing his experience with Haskell, explaining
ups and downs. He concludes by

> Haskell is a great programming language. It requires some effort at the
> beginning, but you get to learn a very different way of thinking about your
> problems.

Are you interpreting the word "different" as "better"?

------
Safety1stClyde
> If you read an article from 10 years ago about the best way to do something
> in the language, that article is probably outdated by two generations.

Thank you, that is all I need to know about Haskell. I won't be learning
Haskell then, in the same way that I won't have anything to do with C++. I
don't have enough time to use these fashion-dominated and fad-obsessed
programming languages.

~~~
charlieflowers
Holy cow! Don't ever _dream_ about getting into node.js then!

~~~
Safety1stClyde
Anything to do with Javascript is prey to churn. Many modern web pages consist
of a blank page which loads various bits of Javascript from various servers
which then process other Javascript via Javascript templates into the final
page. There might be a small minority of web sites which actually are updated
so often that these actions are justified, but the bulk of the websites
clearly are those where some Javascript-fixated person has decided that "there
is no such thing as too much Javascript".

Considering that the language was not very well designed in the first place,
putting it on both the web browser and the server, and then insisting on
regenerating what could easily have been supplied as static HTML pages by
running dozens of Javascripts on both the server and the browser should be
enough to convince an average observer that Javascript is being abused in this
way due to nothing more than faddism.

------
davidrm
This has been the most disappointing blog post I have read in quite some time.

~~~
vadman
Why? The author didn't crap nor fawn all over the language. He highlighted
what he thought were important quirks of the Haskell
ecosystem/community/whatever, in a measured manner, while noting that if you
invest time and effort you can indeed produce relevant output.

Should one dive in given those quirks? The decision is up to the reader.

Curious, what did you expect/wish for?

EDITED for better phrasing.

------
anorphirith
we should forbid click bait titles on HN, it's an insult to the audience's
intelligence

Clickbait title are so common we think they're normal titles.... Here's how he
did it: you create a craving for an answer then you offer a solution for that
craving. "here’s how it was" ==> that's the trick Also "here’s how" should
never be used in a title, we all know that the title's subject IS what you're
going to talk about. a pre-click bait era title would have sounded like:
Learnings after using Haskell for 5 years

~~~
hyperhypersuper
While this title follows a particular style it actually tells you what the
article will be about (5 years of Haskell). What bothers you about it?

~~~
ajkjk
It's clickbaity because you have to click to find out if their opinion is
highly positive or negative. It _sounds_ like it's going to be answered by
"... terrible" or "... great!", and that it's phrased that way to make you
click and find out.

Granted, once you click you find out that's not why it's titled that, but you
still feel baited into clicking to find out. A better title would be something
like "I tried Haskell for 5 years and here's the good and the bad", or
something like that.

~~~
leshow
It's hardly clickbait. Clickbait would be a purposely inflammatory or
exaggerated title to get you to click the link. This is the complete opposite
of that.

> It's clickbaity because you have to click to find out if their opinion is
> highly positive or negative.

I think you just stated the purpose of a title. Wiki says clickbait is:

> "... relying on sensationalist headlines or eye-catching thumbnail pictures
> "

There's nothing sensationalist about. "I tried Haskell for 5 years". It's
rather banal.

