Why does everyone hate Haskell, jazz, and pure math?
adueck.github.io
adueck.github.io
It's just wrong to ascribe the popularisation of HOFs like `map` to Haskell. `map` was there in good old (practical) Lisp 1.5 back in the 1960s. Why ascribe this to Haskell (released 1990) rather than Lisp? Guido said Python v1 (1994) got HOFs "courtesy of (I believe) a Lisp hacker who missed them"[1], Ruby had blocks in V1 (1995). Haskell's research direction was not about very, very old news like HOFs, it was about non-strict evaluation, and cool type system stuff.
[1] https://www.artima.com/weblogs/viewpost.jsp?thread=98196
That said, to really squeeze the most out of HOFs the language probably needs a well developed type system. I've noticed with untyped code that at some point HOFs start becoming hard to write because the layers of abstraction get confusing in a way that static analysis would be helpful with. Although my lesson there is to not go overboard with HOFs - if I need static analysis to write working code it is probably too clever to understand by reading it! The Haskell community might succeed in proving that view wrong, but until then...
I have the same with Nix (from NixOS).
It’s a really nice idea to have a functional language that compiles to a working linux installation, but those abstract functions can get really complicated, especially when I return to something I wrote six months ago.
It makes me really miss Rust’s type system…
Scheme is specifically mentioned as an inspiration in the spec.
The promise is that you learn this difficult language and you gain a higher-level, cerebral understanding of software, and the type system protects you from bugs.
The reality is that you realize that this language was designed by a merry bunch of category theorists who had little interest in software engineering. The effort put into different parts of the language is super unbalanced. GHC is an impressive feat of compiler engineering. But the other tooling is poor, and so is support for basic features such as records.
Whatever extra bugs are caught by Haskell’s elaborate type system that wouldn’t be caught by a simple type system like Java’s, are replaced by bugs introduced by laziness.
Jazz is a bit different. Non-musicians generally don’t enjoy it. The more knowledge you have of Jazz the more you appreciate it.
These rules cut out 99% of space leaks. The profiling tools are a big help for the last 1%.
That's a bit reductive. Jazz covers a lot of ground from Dave Brubeck[0] to Sons of Kemet[1] to Mopo[2] to Hiromi[3]. There's very different reasons to find each of them appealing.
0. https://www.youtube.com/watch?v=tT9Eh8wNMkw
1. https://www.youtube.com/watch?v=0mu1FHeNkpo
2. https://www.youtube.com/watch?v=m94-ih0gf7k
3. https://www.youtube.com/watch?v=QU2893TnTbUEven though I am studying category theory right now I feel I have so little incentive to learn Haskell because I don't think I'll ever use it except with category theory. And I get that category theory is kind of like native to Haskell but I could still explore those concepts in a lisp but that compiles to Javascript or something.
My concrete example is the Haskell Web framework IHP. I tried to get it working on my windows machine for two days and couldn't get anything smooth to work. Granted I have rsi and cannot use my hands as much as the next developer. However, when new frameworks like fastHTML pop up where everything is on one python file and immediately ready to go, It's really hard to convince myself to go through the trouble and pain to get to the same spot with Haskell as I can with another language immediately.
I think Haskell's great. I got over my hesitation to learn it by accepting that it's a useless language. I just treat it as an intellectual exercise.
Web programming is very important and useful. Haskell is ill suited for it and it's ecosystem around it is very weak. You make a great point comparing it's experience with other options.
Post admitting Haskell's uselessness, I would put web programming towards the end, on a tier list of things to do with Haskell. If one of the goal is having a fun experience.
EDIT: Added more info
As for the type system preventing you from bugs, I agree that it doesn't really live up to the promise.
> Whatever extra bugs are caught by Haskell’s elaborate type system that wouldn’t be caught by a simple type system like Java’s, are replaced by bugs introduced by laziness.
I think you're simply wrong. I've been writing software professionally for almost 30 years: say what you will about Haskell's weaknesses, I've consistently found it to provide a better _software engineering_ experience than most other languages I've used. The only thing I think comes close is Erlang/Elixir, and even then I miss the sophistication of Haskell's type system all the time--the ability to make a change one place and have the type checker tell me so much about where else I need to make corresponding changes is invaluable.
Feeling constrained in what I can express because the type system forbids it almost always leads me to realize a logical fallacy in how I've been considering a given piece of code. And yes, Haskell records are bad in a lot of ways, but it still isn't enough to make me throw the baby out with the bathwater, and the existence and utility of row polymorphism in PureScript in my mind dismisses the notion that this has something to do with the type system.
In fact I think this article is frustrating and off base because I value Haskell so much for its ability to help me write useful, maintainable code; I don't care about esoteric extensions or type-level programming other than how much it enables me to solve problems.
I don't get why so many people have the attitude about Haskell that you do. I think a lot of people bounce off of it but this is not the same as asserting that it doesn't live up to the promise--it does, and then some, as far as I'm concerned.
Then again, I was also a jazz performance major
https://www.youtube.com/watch?v=re96UgMk6GQ&t=802s
This talk is seven years old btw. Caring about industry users in Haskell is not new.
Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.
Without good records it’s unreasonably hard to write large software projects. Just look at any Java code, what’s it full of? class declarations. What’s C code full of? struct declarations. What’s JS code full of? object literals. Structures are a critical part of any programming language. A significant part of all code involves declaring structure types and marshaling things in and out of structures.
One of the issues is that Haskell added a lot of type system features without thinking how they’d interact with records. AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible. But they could still have much better nominal records.
I love Haskell, it’s frustratingly close to being a great language, but it needs a push to prioritize developer experience.
There has been an incredible amount of work over the last decade put into all the things you mentioned, which it sounds like you're unfamiliar with. https://github.com/haskell/haskell-language-server in particular is a pleasure to use in my experience. Package management is far from perfect, but it's always being worked on and I'll take it over anything in Python or the Node.js ecosystems any day. Developer experience has improved a lot since I started using the language and this is an area that the community and leadership absolutely cares about--I'd be surprised if anyone spent time reading relevant discussions in https://github.com/ghc-proposals/ghc-proposals or https://discourse.haskell.org/ or etc. and agreed with you.
> Haskell has the worst support for records of all its peers. SML, OCaml, F# all have better records.
> Without good records it’s unreasonably hard to write large software projects.
> AFAIK it’s hard to retrofit ML-style structural subtyped records onto Haskell, because the type system is designed around that not being possible.
Haskell is not ML, and while Haskell records are weak they are not what is preventing people from writing big projects in Haskell. There is much more to the language than records. But I said this in my previous comment.
Nothing you've written resonates with me, and I've written Haskell and PureScript professionally as well as Java and JS along with a bunch of other languages that haven't been mentioned. I'm also actively working on an open source project in my spare time with thousands of lines of Haskell and PureScript code (https://github.com/ddellacosta/automation-service), not to mention a half dozen other random half-done projects and contributions I've made to other open source libraries and applications. What have you written in Haskell that has made you dislike it so much?
> Talk is cheap.
Yes it is.
What is the popularity of it via surveys?
Regardless, this has nothing to do with what I wrote in the comment you were responding to, so I'm not sure what your point is in raising these questions.
Our team's big mistake was believing blog posts that swept laziness problems under the rug. In hindsight, there's plenty of criticism about Haskell's laziness in complex apps, and we should have taken that criticism more much seriously.
I linked a blog post[1]. I wouldn't say it sweeps anything under the rug. In fact it takes laziness out from under the rug and shows you exactly how to deal with it. If you think that approach wouldn't have solved your problem then perhaps you could elaborate why.
[1] http://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrepr...
We had lots of legacy subcomponents that permeated throughout the app's data structures, and as a practical matter, we couldn't reopen all that existing code. Some of that legacy code crossed organizational boundaries, so eliminating laziness throughout simply wasn't do-able.
So given all the above, there are two reasonable conclusions, which aren't contradictory:
1) If we could have reworked lots of existing code, we could have eliminated space leaks via @tome's approach.
2) Haskell's laziness is fundamentally misaligned with projects like ours, which has cross-organization code, long-running iterative algorithms, and complex data structures.
In desperation we used deepseq, which everyone knows is bad, and shortly thereafter we cut our losses by switching platforms.
[1] http://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrepr...
[2] Here's a space leak I fixed two years ago in a popular library by making invalid laziness unrepresentable https://github.com/mrkkrp/megaparsec/issues/486#issue-135418...
Actually, let's be honest, there is hardly a soul that knows what Haskell is either. So hate is not really a great word for this title, nor is the use of jazz and pure math.
Even cows can enjoy music.
> it was Rafael Bombelli who first set down the rules for multiplication of complex numbers in 1572. The concept had appeared in print earlier, such as in work by Gerolamo Cardano. At the time, imaginary numbers and negative numbers were poorly understood and were regarded by some as fictitious or useless, much as zero once was.
Here I am.
I think pure math is simply not applied math - so math that is not being done in direct service of a particular goal, such as working out insurance pricing or perhaps ML/AI etc.
So it's essentially about who pays you. Seems fairly clear to me.
Not really, because many disciplines are inherently applied. There is, for example, no such thing as "pure teaching", since teaching is always practical.
To me the lack of a practical purpose at the moment is the defining characteristic.
Here you go, 37 minutes of free jazz: https://www.youtube.com/watch?v=8bRTFr0ytA8
Free jazz being unusual and difficult to listen to is sort of a meme. I recommend reading the comments under the video for examples.
Never ever, ever read YouTube comments.
Haskell fans seem to delight in making simple problems complex rather than complex problems simple.
That’s a reductive way of talking about a group of people. Is that from your personal experience with Haskell fans?
My personal experience with Haskell fans doesn’t match that at all. The Haskell fans I meet tend to be reasonably pragmatic, but care more about correctness. There are some who do research, but they acknowledge that research doesn’t always yield practical advancements. The Haskell fans I know will acknowledge that Haskell is not most people’s first choice for a language, and that one of the main benefits of Haskell is to yield insights that can be ported to other languages.
Rust is now approaching mainstream, if it isn't there already.
Could be an observational bias. I think the silent majority are quietly using the simple, easy parts of Haskell to solve problems in simple ways, and aren't tweeting about it. Because it's boring.
I apologize to all pragmatic Haskell fans for the unfair generalization!
Haskell fans like neatness and good type systems. EJAs like to torture people, with verbosity and cumbersome abstractions.
I like the idea of Unison. Would be good to see a normal language using hashed functions to avoid recompilation.
For the last long while, though, Stackage (versioned repository of packages that build together under a fixed computer version) and stack fix this problem. It's one of the things I miss when I use other packages/build managers from other languages.
s/computer/compiler/
Joking aside, 80% of the benefit of functional programming in practice, in my experience, comes from referential transparency, expression-based programming, and sum types. It's even fine to allow for procedural code inside of these referentially transparent functions. The effects these features have on program structure, logic flow, and data structures are profound enough that the benefit of IO monads and other more pure features have diminishing returns for the extra elbow grease that needs to be put in. It's also fine to break the rules in a number of cases you can hopefully count on one hand; stateful code needs to be isolated and well-understood.
It's an interesting mix that you picked.
Rust shows that sum types are useful even outside of functional programming.
Just like Java (and others) have shown that garbage collection is useful even outside of functional programming; but functional programming was where GC was 'born'. Just like functional programming was where sum types were 'born'.
Incidentally, garbage collection was born with Lisp. And Lisp is arguably a functional programming language (or family of languages), that for the longest time didn't have sum types.
What we call functional programming is a grab bag of features and absence of some other features, but the exact contents vary over the decades. Even C++ got closures these days.. and that's how progress looks like!
We see similar developments for closures and support for first class functions in general.
And my sincere hope is that in the future, other features like sum-types and pattern matching over them will go the same way.
The functional programming community pioneered many of these features; but those features aren't restricted to that small corner of our industry.
I hope that relations-as-datatypes will see widespread use in the future. SQL shows that relations are good for expressing business logic, and I used them in a Haskell dialect as an internal datatype (unconnected from any database), and the experience was great.
There's no reason Python etc couldn't host relations as datatypes, the same way they already host dicts.
Yes! This is the real win of functional over imperative languages. It means you can understand blocks of code in isolation and then compose them into larger blocks. Bottom-up programming. This is what is missing from the imperative paradigm, and why that approach struggles to scale with problem complexity.
1. The right-hand-side of the declaration
2. Where you are in program execution
Consider this JavaScript:
let x = 1;
x += 1;
x *= 3;
Valid answers are 1, 2 and 6.
Now lets restrict our JavaScript to pure expressions:
let x1 = 1;
let x2 = x1 + 1;
let x3 = x2 * 3;
This makes it easier to reason about the code - you only need to follow the definitions.
This is an unnatural way to write JavaScript, but some languages make this easy (Clojure, Elm, OCaml, F#, Haskell, Erlang, ...).
Nevertheless, I'd take a functional language over procedural any day. The horror of mutable memeber variables changing all over their class is real.
You also failed to mention immutability. Immutability permits trivial concurrency without requiring mutex lock semantics. I'd call that a massive benefit, especially considering how much load a Phoenix server can handle.
I know. Quicksort comes to mind. But you then lose a guarantee. Might not make a difference practically, though (which presumably is what Rust's design banks on).
* https://www.theonion.com/aging-rock-musician-realizes-it-tim...
"Haskell? I was into those guys before they were cool. Miranda, man, that even had diagonal comprehensions... Have you heard of Hope? Kiff this, mec..."
Lagniappe: https://www.youtube.com/watch?v=nSKp2StlS6s
it has more actual Sax
* especially not those with the new Smith and Wesson, the 408 Tactical with xenon projector slung under the barrel...
[oddly enough, I am getting no hits for "venial Finns". (ok, one, but it was poorly OCR'ed ſ)]
Suojeluskuntain Ase- ja Konepaja Oy please. ( https://www.sako.global/ )
Incidently, you can see my house in the background here: https://youtu.be/W6KJM-MODME?t=139
That video must've been shot around this time of year? Google Maps shows Greenhills as being distinctly brown[0], and while we hit the low 30s here recently (the combines have been out in force on the wheat fields) I suppose you all have a good six months yet before your season.
1'100m is a long shot. Locals tend to stick to almost 1/4 that[1], eg https://gr2026.ch/wp-content/uploads/2023/11/ESF-5.jpg
If the Dubrovniks ever remaster Audio Sonic Love Affair, SAKO has a cover illo for them: https://media.sako.global/image/upload/f_auto/q_auto/ar_1.80...
[0] a landscape of "olive and gold" if we wish to wax poetic?
[1] the iron sights on my wife's ca.1900 service rifle can in principle be adjusted out well past 1 km but I strongly suspect that was only meant for volley fire?
4,593 m (5,023 yards (2.85 miles)) is their notion of a long shot: https://www.youtube.com/watch?v=7owwTz7Z0OE
We were raised (farm shooting) to think 600 yard head shots were adequate and good was north of there. Our father was in Navy after being a farm boy and routinely won inter service 'friendlies' ( AU v US v UK v etc.) so that was probably a high 'low bar' in hindsight.
Jazz musicians literally so, and to a much more insidious degree than Haskellers or mathematicians.
That is-- jazz musicians fall prey to the tendency to fill time with content pulled directly from the exercises they used to gain proficiency on their instrument. These can be simple iterations that step through a sequence of pitches, enumerating through the degrees of the pentatonic scale, compulsively sequencing through patterns in an octatonic scale, etc.
Worse, this tendency can strike old timers just as easily as newcomers. Coltrane famously began to normalize his improvised lines to patterns he'd practice that were straight out of Slonimsky's book of exercise patterns.
To get a sense of how annoying this can be even to jazz insiders-- imagine a math paper written by five researches. They read the paper aloud at a conference, and when one of them gets to the summation symbol, they immediately explain to the audience:
"So for example, here you'd add one, two, three, four, five, six, seven, eight, nine, and so forth..."
As each researcher reads their section of the paper, they do this, incessantly, for every symbol that can possibly be explained with sequences of numbers.
I had one friend who was musically gifted who loved it.
I really think Jazz is something that you have pay fairly close attention to in order to enjoy it. Or at least have a long term relationship with music. It usually has too many moving parts for most people to causally enjoy.
Of course, Jazz is such a large body of art, there are major exceptions to that generalization.
Yea, there's a reason why people like lounge pianists will often play jazz standards if they just want to create some pleasant background 'noise' and don't really want to draw attention to themselves. If a bar quietly has a "Best of Generic Jazz" playlist on, they're probably not driving away many customers. (Some) jazz is on the whole [1] probably one of the most inoffensive and generally accepted genre of music around.
[1] Yes, I know that there is plenty of jazz that isn't like this. And this is where the music nerds can get into their what is 'real jazz' arguments
I don't like imperative languages trying to do functional programming. Especially Javascript. It's just pain to debug a `.filter().map().reduce()` chain, you have to create a separate variable every time you want to insert a `console.log` there somewhere to figure it out.
Also I don't like functional programming eating away the performance. You can sure write 3 O(n) loops easily, but you can't see the instant wins to optimize it the same way you can with imperative programming. Maybe the third loop wanted to reuse something that could be found in the first loop? With imperative programming: Great, put it in a variable outside of the first loop, and fill it. With functional programming: Change all the types in the loops to fit this new variable, and remember to return it through all these functions.
EDIT:
Also as jordigh pointed out here https://news.ycombinator.com/item?id=41160794 I don't like how functional programming obfuscates performance a bit. With imperative languages what you code is what you get. Functional languages do so much more behind the scenes, that it's hard to figure it out some times.
Functional programming as in "strong static typing and algebraic data types"? ML.
I try not to begrudge anyone their enjoyment of anything, and I like jazz, for the record. It's good that we have a language for people who want to do Haskell-y things, and y'know, Pandoc is nice.
But this blog had an opportunity to make the case that Haskell innovations are trickling down into mere programming languages for squares (for the squares out there, if you don't like jazz, you're a square), and they offered two things which don't come from Haskell.
So I put it to you, Hacker News: what did the author miss? Where are the great Haskell innovations us mere programmers now benefit from?
I just wish for a dialect with strict evaluation, and side effects instead of the IO monad.
I've had the same issue with Elm, although I've actually shipped a number of projects written in Elm since it can be easier to integrate.
The crux of my issue is that I often write software which will be passed onto others for maintenance. Nobody is interested in taking ownership of projects written in esoteric languages. As the old saying goes, no one ever got fired for choosing Python.
It is a bit like a high level version of Rust, targeted at building web applications, handling concurrency by replacing the borrow checker with Erlang's processes – since it runs in the Erlang's virtual machine.
But I quibble with the broad inclusion of "jazz" in the list. I don't really like the idea that jazz is this never-ending process of avant-garde musical boundary pushing. There are these cults of personality around artists like Miles Davis and Coltrane, and at some point people decided that "easy-listening", "smooth jazz", and "elevator music" were the nadir of "cool", but those particular cultural trends don't necessarily define jazz as a whole. It's also reasonable to regard jazz as having a matured musical vocabulary that we can construct accessible tunes out of without pushing boundaries all the time. I suspect a lot more people do enjoy "lounge" jazz than would admit it.
Many languages fall into this tarpit and will never escape.
I would instead say -
I dislike Haskell because when I tried this book http://web.archive.org/web/20190705205338/https://www.cs.yal... about 20 years ago I thought it had been written in an effort to impress upon the reader how smart anyone using Haskell was, at the expense of me getting anything done.
I like various forms of Jazz but I dislike a certain type of Jazz person who seems to be in to Jazz to let you know just how much better they are than you.
I don't think I've ever had anything but enjoyment and admiration for pure math and pure mathematicians.
I'm not sure I like this blog post though.
>“Geometry is knowledge of the eternally existent,” (“Sacred Mathematics”). This quotation by Plato, an Ancient Greek philosopher, demonstrates the importance of geometry to the foundations of the universe.
To me that illustrates a depth to maths which is absent from Haskell and Jazz.
Also from Wikipedia:
>Evidence for more complex mathematics does not appear until around 3000 BC, when the Babylonians and Egyptians began using arithmetic, algebra, and geometry...
Where would F# fall, wouldn't it be hitting the sweet spot of 'Safe' and 'Useful'.
There's a difference between working on something because it is interesting and fun, essentially "hacker mentality" and it turning into something special vs pure theory and it never having use. One tinkers with the world building things, the other just adds complexity to abstract ideas with no utility.
tl;dr Faraday was a tinkerer, pure theory are fiction world builders.
Popular music with 4 cords progressions, languages like python that people need or basic math are popular. People can hate python, or basic math or reggaeton because they are everywhere.
I am a Lisper and Haskell programmer myself(along other languages) and I can tell you the proportion of people that I know that know what Lisp is is a minority, like 1% of the general population. I would say 10-20% of the population knows what Fortran or C is.
"Their practicioners seem to be divorced from the real world. They don’t actually produce anything useful. Rather than working on practical things that everyone can enjoy, they seem to be caught up in silly exercises just to show off to other nerds."
That is right. Most people in the Haskell community are totally divorced from reality. I would say more, they are not interested in reality at all. Do not tell them about engines or User Interfaces or databases. Not interested at all. They also love Pure Math problems.
I don't see the problem with that. I see the problem when people that are not interested in reality want to rule reality like millionaire children's intellectuals(Engels and Marx, Trotsky, Lenin...) wanted to rule work without having worked in their entire lives.
I see a problem if someone that told me he is not interested in how the User Interface of my app(or any user interface btw) works is telling me that I have to rewrite it in Haskell because it is perfect in his mind.
I find Haskell ideas useful up to a level, but not further than that. While science comes from philosophy and philosophy comes from love to knowledge by itself, most people doing philosophy in the past was wealthy people whose wealth came from somewhere else, like commerce having a fertile land.