As a somewhat experienced programmer, I would actually say that the language extensions are an important part in disincentivizing learning Haskell for me, because even if I learn the base language, it seems like I would need to understand all these weird extensions to read real-life code, which always seems to involve half a dozen of them.
https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_gui...
Also typically language extensions are pretty simple, single purpose, and well documented.
I will try again to explain with an example how these extensions are borderline user-hostile.
One of those extensions in your article linked above is apparently something called `DoAndIfThenElse` which enables if..then..else syntax with if and then on the same line, so far as I can tell [1].
When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging.
There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim.
Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. I think whoever is steering the ship in Haskell/GHC land should really focus on ways to freeze new language extensions, and make the current ones well-documented in addition to providing options like the one you linked. Newer languages have environments that are much friendlier towards newcomers in terms of both documentation and (for lack of a better word) runnability of real-world code.
----------------------------------------
[1] I would really like to know why this is considered a popular language extension, and/or why it was needed, but let's skip over that for the moment.
[2] https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-lang...
Well thats kind of the point of the GHC2021 extension. It will be a standard so that new programmers that format if else statements as they would in other languages don't get a weird error that very much does SAP their energy.
> There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim.
It certainly calls it into question, though I did say typically. I'm open to weakening to "many times" if there are more than a few other examples.
> Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases.
The problems described occur as a result of the extension not being turned on, so I find the logic doesn't work here.
But that isn't really the case today, is it? Almost all the cool power features of Haskell have been adopted by the rest of the world. Type inference, pattern matching, explicit nulls, algebraic data structures, rich type systems... although it isn't usually enforced, the world has woken up to the fact that "mutable state is dangerous and should be avoided whenever possible". Writing a program without any reassignment isn't nearly as alien to a programmer starting out today as it was 20 years ago. Back then, even passing a function as an argument was edgy (and, in C/C++, risky).
I think what's hampered Haskell, and made at least me reluctant to pick it up again, is that for all the ridiculous talent working on Haskell, there hasn't come some brilliant fix to the space leaks thing. Almost as if there's something fundamentally hard about composability and laziness. I'm really not sold on laziness by default anymore, it costs so much more than it tastes - and for everything else, Haskell is a victim of its own success in that so many of the things it pioneered has gone mainstream.
In brief, I think Haskell is still the purest expression of what makes it great. This is both a good thing, for the reasons I outlined there, and a bad thing, because e.g. stringing together a few iterator methods in Rust may be a functional style but it still prepares you for the concepts you'll encounter in Haskell about as well as zooming a Hot Wheels around on the kitchen floor prepares you to drive a lap in an F1 car without stalling out or flying off the track.
People with a modern imperative background know this intuitively---or maybe they just assume it, and happen to be correct---as soon as they look at a page of nontrivial Haskell code.
One thing people seem to miss about laziness in Haskell is that it's (unfortunately?) really tightly coupled with how "control structures" are expressed. For instance, instead of writing a loop with some infinite or indefinite condition, you might declare a list using a generator function and iterate over its values. I would like to see how other similar languages (e.g. Purescript) have done away with it, and how it impacts them. But my recollection from when I actually knew Haskell is that it was an incredibly powerful feature tightly integrated with the language design, not only from a data perspective but also from a perspective of allowing code structures to map much more closely onto the data structures they're manipulating.
(This is a big part of why, as I think I mentioned somewhere else in this thread, Haskell is so ergonomically suited for working with tree-like linked data structures.)
More likely, network effects can explain how something makes it to the mainstream. For example having a big corporation behind the development and marketing of the language.
Though I'd recommend a youtube channel called 'Low Level Javascript' (really!) which comes close in developing some of their parser combinator library.
Granted the ASCII tick/apostrophe is neither the proper symbol for primes nor quotation marks (should be curly), but programmers are reluctant towards Unicode.
If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.
IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't.
(I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.)
This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points:
* Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor.
* Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows.
* Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't.
The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.
Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Lazy evaluation is actually a double edged sword so it's not a clear win either.
Rust on the other hand is adding safety and correctness assurance specifically without or with very little runtime overhead while providing very predictable performance (both in runtime and space).
You can sub Haskell out for Clojure/Scala/OCaml and arguably mixed paradigm languages like Kotlin/Rust/Swift and be fairly happy.
However if the constraints of your problem call for Rust then your only other real options are to sacrifice correctness/data safety and use C/C++ instead.
FWIW I think Haskell is awesome, this is just why I think we don't see it in "the real world' much.
Back when I was fluent in it, I wouldn't reach for Haskell for functional purity or lazy evaluation---I'd reach for it because I wanted the richness and flexibility of its type system and pattern matching for building and manipulating a tricky data model, or because I was doing something involving tree-like linked structures and/or that lent itself well to recursion. Parsers are the obvious example, but they are a very narrow view of what Haskell excels at.
(In short, I'd reach for it for reasons that are basically impossible to explain to somebody who doesn't already know what I'm talking about.)
I can't be so effusive about Rust. It's a really great language with a thoughtful and restrained design, powerful and practical and flexible, but I would actually say the opposite re: filling gaps: Rust feels like more of an iterative improvement in the space occupied by C/C++/Go/etc., while Haskell is transcendently good for those classes of problem where it excels.
---
Today I'm more or less fluent in Rust after a few hours' warm-up, but it would take me days or weeks to warm up my Haskell. Why? Mostly because I've largely stopped programming for fun, and I use nothing like Haskell at work. Throw in the quality of Rust's tooling and the largely effortless reproducibility of its builds (great for warming up a 6+ month old project), and it's just a far more practical choice for the little hobby programming I do. Hence my earlier comment. But I still contend that Haskell has vast untapped potential, locked away behind an intractable adoption barrier. It's less that it has nothing new or useful to offer us, and more that we are unwilling to pay the price of admission.
Is the end result reached by other means the same? Can you give an example of a competing approach in a non-pure language that gives one Haskell's advantages?
There is maybe some niches where that wouldn't be the case like very high assurance software where instead of Haskell you might choose say ADA instead but I'm not really familiar with those domains.
Kotlin plus property testing gets you very far and the industry defaulting to that would be a huge improvement.
I'll have to rewrite one of my Haskell projects in Kotlin and see if I feel anything is missing.
Rust brings a new set of tools and tricks and safety to an important use case that has had no movement for such a long time. The only real advancement has been smart pointers and "modern" C++, but while they are an improvement they also contribute to C++ being a bag of all the features.
I haven’t yet tried programming rust, but I have read that error management and suggestions for correction in rust are superb. That makes a world of difference for a neophyte in a programming language.
I feel the burden of proof for the claim "superior languages make only marginal differences" is one that is very high and one you have not met.
The null hypothesis would be that all reasonably well supported modern general-purpose programming languages are about as productive as each other on average. I have my own anecdotal opinion(s)^[1], but the onus is really on anybody claiming language X is superior (no air quotes there) to prove it to the rest of us.
In this case, by using air quotes, I meant to draw attention to the fact that the aforementioned proposition regarding Haskell's superiority is (AFAIK) unproven, as well as to illustrate the skeptical attitude a practical business leader might have toward embracing it, for what I consider to be totally fair reasons.
Also note that I'm not necessarily using 'marginal' in a pejorative sense. A marginal improvement can be significant.
^[1] Anecdotally I think Haskell is transcendently good for certain kinds of problems, and a huge pain in the ass for others.
I noticed that and considered (and should have said) this to prevent any miscommunication:
I feel the burden of proof for the claim "language choice makes only marginal differences" is one that is very high and one you have not met.
Then if we want to disprove the null hypothesis there we give one programmer brainfuck and the other Python ;)
Hence "reasonably well supported modern general-purpose programming languages".
I think this null hypothesis is where most sufficiently jaded working programmers end up, and business leaders without a programming background will start there because it's all Greek to them. I'm not here to prove its correctness, just to raise it as a very real factor working against Haskell's adoption.
Nothing would delight me more than for somebody to come along and unequivocally prove that Haskell is a silver bullet. But the point here, really, is that nobody has yet.
There's also a burden of proof on those who claim there is no diffrence.
Ultimately, asking programmers to relearn how to be programmers (or, more relevantly, asking businesses to accept that overhead and/or a vastly reduced hiring pool) is just too large of an ask for whatever marginal gain you might expect from using a "superior" programming language.
To be clear, I learned Haskell for fun and got to what I'd consider an intermediate level of expertise. It was an incredibly enriching experience, and gave me a new perspective on programming in general. But it was hard, and the rabbit hole just keeps going---sure, you can juggle monads in your sleep, but are you proficient with the `lens` library? No? Well, I can recommend you a pile of textbooks that might help.