I strongly dislike Haskell's focus on theory. Just show me examples on how to get things done and then the concepts will become clear. The Haskell and mathematics communities too often act like ivory towers that humans have to become enlightened to understand, and that simply is not how my brain is wired. I'm not sure of there have been any studies on the usability score of languages, but I think that Haskell would come out very, very poorly. There's a reason why python is so popular.
back
12 comments
For the context: Haskell was 4th or 5th language I learnt and the first pure functional one. My graduation thesis work was in Haskell and its backend/compiler so at one point I was living/breathing Haskell.
> ...too often act like ivory towers...
I 100% agree with this. The Haskell community as a whole and various tutorials etc., aren't optimised for a new comer.
For instance, you don't see a "stand up a web app in Haskell in 10 minutes" tutorials. Historically it may have worked in Haskell's favour to slowly induct learners, but in this age where languages are fighting for mind space I don't agree that's a good approach anymore.
Simon Peyton Jones (SPJ), an earliest and a famous champion of Haskell coined the phrase "avoid success at all cost" in a certain context which may have had some role in making Haskell seem Ivory Towerish.
A language, like any living being, needs to adopt to survive and thrive. It's unfortunate to see Haskell remain a niche language even after close to 3 decades.
> and that simply is not how my brain is wired.
This, however, I disagree with. I mean in a general sense, not specific to how your brain is wired. It all depends on the first couple of language that one learns and how they are learnt and taught. 10-15 years ago people would find it hard to grok Python's functional concepts. But as it began to be taught as the first language in universities and those graduates join the working population you see how it's super natural for them to grok Python.
> This, however, I disagree with. I mean in a general sense, not specific to how your brain is wired. It all depends on the first couple of language that one learns and how they are learnt and taught. 10-15 years ago people would find it hard to grok Python's functional concepts. But as it began to be taught as the first language in universities and those graduates join the working population you see how it's super natural for them to grok Python.
That must be the reason why Edsger W Dijksta once stated [0]:
> "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
... and ...
> "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
... and ..
> "APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums."
I must be one of those mentally mutilated programmers with no hope of regeneration :)
---
[0]: https://www.cs.scranton.edu/~mccloske/dijkstra_quotes.html
Dijkstra. A smart man. But also an arrogant prick. The typical professor living in his own bubble who never dealt with businesses and commercial activities. Those statements are totally nonsense.
When BASIC e.g. redefined what "variables" are and what the equals operator means, it did cause a generation of programmers to drift away from the long established mathematical definitions. This persists to this day in languages like Python. I have had to explain to my daughter that Python variables and equals are not like those in her maths lessons. Dijkstra was right to call out the bad decisions that were made, although I do concede his methods of doing so were not ideal.
His statements make a lot of sense: the first language learned often has a profound effect on programming habits. That's why proverbs like "one can program in COBOL in any language" appeared.
I think that some of the quotes are pretty toxic, regardless of who they are by. Programming languages are just tools and as such, they should be reasonably easy to use. Programming languages should serve people, not the other way around.
Elitism and gatekeeping do precisely nothing to help people solve problems with code.
> Elitism and gatekeeping do precisely nothing to help people solve problems with code.
I agree 99% here. The 1% is where you want to shock someone to break through. Not sure if that was Dijkstra's intention, but I assume it was. He was a teacher as well, writing books, giving lectures. I think he was genuinely concerned.
> I think that some of the quotes are pretty toxic, regardless of who they are by.
They are indeed, aren't they?
I mean, they straight up sound like bullying those who happen to not think alike or share the same opinion.
Those who are in the right are able to form rational arguments, raise concerns about specific problems, and offer solutions. But no, not in this case. The only reason for anyone to not be a diehard supporters of the author's point of view is that they have mutilated minds and are coding bums.
Most of the current generation of programmers have been mentally mutilated by Object Orientation in the C++/Java/C# style.
I include myself. It has been a definite struggle to onboard functional concepts and solve problems in a functional style. Just doesn’t come naturally.
> Programming languages are just tools and as such, they should be reasonably easy to use.
I'd like to argue on how reasonably simple is simple enough. If I need a carpenter to build a stairs I'm my house, I would expect a good carpenter to know and use all the tools appropriate, no matter how complex. Of course, most things are doable with just a hatchet just fine, but I d expect a professional to choose a hatchet because it's better, not because they never bothered to learn proper tools.
So whenever a language puts "easy to learn" as their main feature, I see it as a guide "how to build stairs with just a hatchet".
Ah yes, my brain has been permanently mutilated preventing me from reaching the one and only programmer nirvana found in functional programming. Give me a break.
> For instance, you don't see a "stand up a web app in Haskell in 10 minutes" tutorials. Historically it may have worked in Haskell's favour to slowly induct learners, but in this age where languages are fighting for mind space I don't agree that's a good approach anymore.
There's now the IHP framework that allows you to build haskell web apps in like 10 minutes. If you're curious, check it out: https://www.youtube.com/watch?v=UbDtS_mUMpI It's been called "Haskell on Rails", and for good reason.
> the phrase "avoid success at all cost" in a certain context which may have had some role in making Haskell seem Ivory Towerish.
This phrase is often misunderstood, it's "avoid, success at all costs", not "avoid success, at all costs". In other words, don't optimise for mass market adoption at the expense of everything else. Languages that have arguably done so, have ended up as extremely complex and ridden with corner cases.
The phrase is often taken as having a single true meaning, but I think the sum of them is really what makes the quote so good.
It's easy to follow a rule too far and end up way overcorrecting the original problem. What I like is that both meanings balance each other :)
Some popular mass-market friendly deliverables don't cost very much at all, avoid them and you're definitely avoiding success at all costs, but with both meanings at once this time.
I don't know much Haskell, but isn't Haskell's goal to serve as a vehicle for research in functional programming languages, rather than to offer a language that's useful for real-world work?
As I understand it, the core Haskell folks don't especially care about Haskell's (admittedly limited) real-world usage. Or, if you prefer: real-world usage is a side-effect, not a value.
I'd say that among pure functional programming languages (i.e. excluding Erlang, Scala and OCaml) Haskell is the language most suited for real-world usage.
Yes, there is a lot of research being done on Haskell, but a lot of the research is centered on areas that more or less directly contribute to typical real-world usage. Consider the recent introduction of linear types for example: They're both exciting from a type theoretic perspective, but could also improve some real-world scenarios (even though at this point linear types are still quite new, so there's not a lot of examples out there).
Conversely, I like that there's a language whose first priority is not "how do I become economically useful to the media industry as fast as possible."
a detail that doesn't contradict anything you said but may be useful for someone unfamiliar with it:
"avoid success at all costs" is usually meant to be parsed as "avoid [success at all costs]" i.e. don't compromise the language just to make it more popular.
Some context: I was taught Haskell, Prolog and Java at university (2006-2010). Coming from chaotic JavaScript and PHP scripting all were hard to grok, but I enjoyed them all. After a couple of years only Java stuck in my working memory. So: I could program in Haskell, I've probably used monads and functors fluently, but the concepts still don't click. I have the same problem with grammatic concepts like adjectives, adverbs, and the more complicated stuff. I obviously use them all the time, but I'm not fluent in the theory.
> > and that simply is not how my brain is wired.
> This, however, I disagree with.
I think it might well be correct, actually. I think that it might be the difference between abstract and concrete thinkers on that standard personality test. Abstract thinkers will find that Haskell makes more sense; concrete thinkers will find that C makes more sense.
> I strongly dislike Haskell's focus on theory.
First of all, I completely understand where you're coming from.
But the fact that Haskell embraces computer science, unlike most other programming language communities, is what attracts me to it the most. I can geek out about the mathematics that leads to simpler, safer software with like-minded people. I am always learning from Haskellers more than from any other programmers.
But it does take a lot of learning and unlearning to become a fluent functional programmer. This isn't because functional programming is more complicated than other paradigms (au contraire), it's because schools and universities have been mostly teaching OOP for the past 2-3 decades—unfortunately. As a result, most programmers have such a big gap in their knowledge that it can feel too daunting to dive in.
We could definitely do a better job teaching the theory and explaining how it's useful. That would be better for everyone: better for curious minds who want to expand their programming skills, and better for me because I'd have more company to discuss it with.
> But it does take a lot of learning and unlearning to become a fluent functional programmer.
Just no.
The reason Haskell is so complicated to become fluent in has nothing to do with the inherent complexity of functional programming. The Haskell community is just in love with complexe abstraction for the sake of abstraction, extremely terse and hard to understand syntax (see for example the obsession with introducing convoluted operators) and generally favour hard to understand style like point free where pipes are a lot easier to follow. The Haskell community is full of people who are here to geek out rather than produce software. Haskell is what happen when you let one upmanship leads your language design.
Meanwhile, you can learn SML, F# and Ocaml in a couple days, gradually enjoy the functionality they have to offer and benefit for a nice community. I really don't understand why anyone would choose Haskell.
> generally favour hard to understand style like point free where pipes are a lot easier to follow
No they don't. Every Haskeller I know (myself included) acknowledges that sometimes point free style is better, and sometimes it isn't. None of them would unilaterally declare it better, and most generally avoid it except in very simple situations.
> The Haskell community is full of people who are here to geek out rather than produce software.
The Haskell community is full of people who are here to geek out about the best ways to produce software. This means they embrace tools like mathematics, and are generally extra thoughtful about structuring programs in principled ways. It's a wonderful community of people who care about the details of their craft and treat it like a skill to be honed over time. I have a lot of respect for that.
If I could rant for a moment: I'm really sick of spending many years of my life investing in myself and my ability to produce software with the best tools humanity has to offer, only to have these people in Hacker News tell me I'm just doing mental masturbation when it seems like they don't even understand what they're criticizing.
Function application pipelines and function composition are closely related. Here's a "pipe" in Haskell:
\x -> h $ g $ f x
At a certain point you realise that in many cases seeing the `x` is not just useless but needless visual noise. The following is identical and more readable once you've internalised composition:
h . g . f
And this extends to a cute trick in which, if you need to explicitly provide that data to begin with, you can do this:
h . g . f $ x
I'm now working with Haskell having previously come from PHP and JS/TS. Composition is more readable, it's just harder to get started with because it's different to what you're used to.
As for the "geek out" comment, of course, I enjoy programming for the intellectual sake of it. I'm not product-driven. Don't make the mistake of thinking everyone's the same as you, nor that of thinking there aren't benefits to being so intellectually-motivated. I don't know if it's intentional but your comment comes across as rather self-righteous.
If you don't understand why anyone would choose something that many people have chosen, you might want to be a little less bold in announcing what motivation those people must all have.
Yeah, um... let's be sure to apply that on all sides.
I can't count the number of times I have read, here on HN, that people only choose imperative programming or OOP because they're ignorant or stupid. Because if they actually understood FP then of course they would choose it, so the only reason they don't is because they haven't learned or can't learn.
Haskell embraces PLL. Computer science is much larger than PLL, and much of it ignores PLL entirely.
In particular, most algorithms research and papers are expressed in imperative pseudo-code, as that is, in fact, much easier for humans to intuitively reason about than complex category theoretical concepts.
> much easier for humans to intuitively reason about than complex category theoretical concepts.
We're not talking about any complex category theoretical concepts here. Functors, for example, are one of the first ideas one would learn in a category theory course. Likely even in the first lecture.
Even the most advanced functional programs use only the most basic categorical constructs.
And when you say "imperative pseudo-code", you've already conjured an implicit monad involving state, I/O, etc. Functional programming just teaches us that it's not the only one—and there are simpler ones that may be more appropriate for the given situation.
> And when you say "imperative pseudo-code", you've already conjured an implicit monad involving state, I/O, etc. Functional programming just teaches us that it's not the only one—and there are simpler ones that may be more appropriate for the given situation.
No, I have not. The fact that you can recreate state and I/O using monads does not mean that anyone using state is implictitly using a monad - monads have very specific properties that imperative code often doesn't have.
It's only Haskell's laziness that makes it require monads for i/o, by the way. Other pure functional languages don't use them. For example, in Idris, IO and state are not monads, they are effects - tracked at the type system level, but without all of the commodity of monads. For example, you can have a single do-block in Idris that does IO and state operations without needing any monad transformers or lifting.
How can you say it's easier for humans to reason about when your test subjects almost all exclusively got started in programming with imperative programming? It's a slightly biased data set.
Python is probably easier to learn for most beginners, but that doesn’t mean it’s easier to write programs in. Context matters when talking about usability.
I’ve used functors and monads to solve tons of issues and have literally no clue about the theory behind them.
Agreed. Haskell solves real problems and it's quite a good language once you learn it, it's the cultural focus on theory rather than humans that I don't like.
> it's the cultural focus on theory rather than humans that I don't like.
That's completely fine. Haskell is not a single community. There are two big camps that often interact with each other, the academic and the industrial. Keep in mind the origin of Haskell is academic and it's original purpose is to test and implement ideas from Programming Language Theory. That is still there and will continue. GHC optimizes for letting people experiment with language extensions. Industrial interest didn't start to grow until somewhere around 2008-2012. It is a small community and will likely remain so.
I am a big Haskell user myself. There are many theoretical things I don't understand or need to touch, but I appreciate their contributions to the language and the community. I do agree that Haskell has lots of room to improve on tutorials for non-academics. Maybe I will get inspired to write somethings.
It's completely fine if you don't want to use it. However, you may find Haskell users' enthusiasm for the language insufferable, hehe. I do hope anyone who chooses to interact with the Haskell community finds us welcoming.
But the tutorials simply ignores the real world use case.
Lots of concepts are actually useful for solve problems (even in other language).
You need to give the reader some real world example. A concept dangles in brain without connects to other things won't live too long. You brain is likely to `optimize it out` because it is unused.
I thought "Real World Haskell"did just that very well.
If you have engaged with the Haskell community (I mean, actually talked to folks as you learn or use the language) and you came away with this impression, I would be very surprised. To learn Haskell, just do it, you don't need theory. For people who are interested in it, it's there.
What I haven't ever really seen is a good Haskell Cookbook. All the references seem to head for the ozone. Show me dumb little grounded snippets.
http://book.realworldhaskell.org/ does this in a tutorial style.
There is no real focus on theory in the language itself, but a significant part of the community, indeed, enjoys it.
For balance, here's another common opinion about tutorials: http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-sa...
> [...]
> Read the monad definitions.
> Use monads in real code.
> Don’t write monad-analogy tutorials.
In the end, the two opinions about learning monads coexist, and people have done fine following either way.
The thing about learning from examples is that it’s far too easy to learn the wrong thing from them, or nothing at all. When writing examples, one has to spend additional effort on explaining which parts of the example are ‘moving parts’ and which are ‘fixed’, i.e. which elements of the example are inherent to the problem you’re solving, and which are just placeholders you should replace with your own. Many don’t bother; it’s why every Medium ‘tutorial’ basically reduces to ‘here’s a bunch of code you can copy-paste without understanding’.
With a ‘theoretical’ description, like a BNF grammar or a Unix man page listing every possible option the program accepts, this is immediately obvious. Haskell’s focus on ‘theory’ follows the same philosophy.
Usable for what, though? If the criterion is correctness, I'd bet good money that Haskell would beat python in any fair comparison. Just because there are languages that let you forget the complexities of your domain doesn't mean these complexities vanish when you use said languages.
In terms of learning I’m the exact opposite. I like to start with theory, then apply it into practice to affirm that the theory is correct (or that it isn’t, and then make my own improvements). Not starting with theory feels too much like being directionless to me, or creating your own theory/mental model of what happened, which could be and is often wrong.
In any case, all knowledge needs to be elevated to some level of theory because a correct theory guarantees the repetition of correct application.
I’ve been learning OCaml recently and have been really frustrated with the same issues. I’ve been writing this page for people like me who want to learn through examples: https://o1-labs.github.io/ocamlbyexample/ (still a work in progress).
It's the same for me. I don't know Haskell yet but it reminds me the hard time I had with mathematics in school. It all changed when I started self-studying by first doing learning to do exercises and memorizing properties, and then learning the theory afterwards. For example I really enjoyed the first Andrew Ng machine learning course on Coursera, where you learn to do matrix calculations and backpropagation by hand for practical applications without much theory. It was great for building the intuition first.
If you want to just get things done, and then learn the concepts of fp, I always suggest using elm.
In elm I had been using andThen functions without even knowing they were related to monads.
Haskell folks are just regular IT folks who missed their calling by not becoming mathematicians.