Hacker News Reader

The reasons are going to vary depending on who you ask. I personally don't agree with any of your reasons. In my opinion, as a long time user of Haskell, the practical reasons are the following -

1. Tooling has historically been a mess, though it's rapidly getting better.

2. Error messages are opaque. They make sense to someone familiar with Haskell, but others cannot make the leap from an error message to the fix easily.

3. It's a jack of all trades. The resulting binaries are not small. Performance can be very good but can be unpredictable. It doesn't compile nicely to the web. Doesn't embed well. There is basically no compelling reason to get into it.

4. The ecosystem is aging. You can find a library for almost any obscure usecase, but it would be many years old, and possibly require tweaking before it even compiles.

>So why hasn't it happened?

Off the top of my head, memory safety challenges for junior Haskellers (laziness footguns), State monad being fundamentally flawed: there is an inability to get at and log your application state just before a crash, bloated tooling, GHC frequently breaking existing code. Laziness and monadic code makes debugging painfully difficult.

I like Haskell for Advent of Code only.

I acknowledge that those things can be challenging, however I'd like to respond to some of the specific issues:

- Space leaks due to laziness are a solved problem. I explain the technique to solve it at: https://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrep... This technique has not completely percolated throughout the community, but I am confident that it does actually resolve the "laziness causes space leaks issue"

- Flawed state monad: well, you point out the analysis of its flaws from the effectful documentation. That's correct. The solution is: just use effectful (or another similar effect system. I recommend my own: Bluefin)

- GHC breakage: I've been keeping an inventory of breakage caused by new GHC versions, since GHC 9.8: https://github.com/tomjaguarpaw/tilapia/ There has been very little! The Haskell Foundation Stability Working Group has had a massive effect in removing breakage from the ecosystem.

- Laziness and monadic code makes debugging painfully difficult: I mean, sort of, but if you're using monadic code in the style of a decent effect system like effectful or Bluefin this is a non-problem. It's hardly different from programming in, say, Python from the point of view of introducing debugging printfs or logging statements.

Thanks, I've followed along with a lot of your posting on the Haskell discourse. One thing regarding this matter:

>well, you point out the analysis of its flaws from the effectful documentation. That's correct.

Thinking deeper about this, that there is essentially no way to fix this issue with StateT, because of the type choice, the monad, the composability requirement, all conspiring together to not be undone, does that signal something deeper that is wrong with the flexibility of Haskell, that we can progressively paint ourselves into a corner like this. Could it not happen again, but with another late breaking requirement, for effectful, or bluefin?

> I've followed along with a lot of your posting on the Haskell discourse

Ah, that's great to know, thanks. It's rarely clear to me whether people read or are interested in what I say!

Well, yes, in principle even a design that is perfect according to some spec could be completely wrong if the spec needs to change. and impossible to tweak to match the new spec. This is true of any language or any system. This raises a few important questions:

1. How easy does a language make it to "unpaint" yourself from a corner?

In Haskell it's easier than in any other language I've experienced, due to its legendary refactoring experience. For example, if you "incorrectly" used the State monad and got stuck, you can wrap it up in an abstract type, change all the use sites, check that it still compiles and passes the tests, then change the definition to use new "uncornered" implementation, again check it compiles and passes the tests, then unwrap the abstract type (if you like, this stage is probably less important), then add the new feature supported by the new implementation.

2. How likely is it to paint yourself into a corner in the first place?

In Haskell, again, less likely than any other language I've experienced, because the constructs are so general. There is far more opportunity to tweak a design when you have general constructs to work with. (That said, I've met many Haskell behemoths that couldn't be easily tweaked so, particularly contorted type class hierarchies. I recommend not designing those.)

3. Why won't effectful or Bluefin lead to "corners"?

Because they're just Haskell's IO, wrapped up in a type system that gives fine-grained control over effect tracking. Anything you can do in Bluefin and effectful you can do in IO, and vice versa. So to really paint yourself into a corner with IO-based effect systems it would have to be something that you can't do in IO either, and at that point we're talking about something that can't be done in Haskell at all. So there's no real downside to using IO-based effect systems in that regard.

> State monad being fundamentally flawed

Could you explain a bit about what you mean here? In what way is it fundamentally flawed?

I'm not saying you're wrong; I just want to understand.

Basically StateT uses Either to model either the application state or an error. So if your application throws, you lose the current state forever. They sort of painted themselves into a corner with this choice of type, there's no real way out now.

This explains in more detail:

https://github.com/haskell-effectful/effectful/blob/master/t...

I agree loosely with what haskman above says about creating relatively bug free applications, the guard rails are so robust. But those same guard rails mean you can paint yourself into a corner that it is harder to get out of without imperative state, case in point above.

Most functional languages give you so much more choice in managing persistent mutable state than the typical imperative languages. In the latter everything can be made into persistent mutable state so you have both those that are due to the problem and those that are due to the implementation.

Haskell gives you a wide range of tools, from simulated state like the State monad, to real ones like the ST monad and IORef inside the IO monad. For synchronization between threads you have atomic IORef, MVar, and TVar.

If you problem requires you to have persistent mutable state, Haskell helps you manage it so that you can truly separate those persistent mutable state that's due to the problem from those that's due to the implementation.

I generally don't like Haskell, but the view of non-Haskellers (myself included) regarding state does remind me a bit of resisting structured programming because gotos are easier to program.

That's a good analogy and I like it! If someone is really used to simply using goto for all kinds of flow control purposes, there could be some resistance if there's a coding style guide that enforces using if/else/while/do and such. It reminds me of similar arguments about recursion is too powerful in Haskell and similar languages and good style means using map/filter/foldr and the like; or the argument that call-with-current-continuation is too powerful. When a single tool is too powerful, it can be used for a large number of purposes so it ends up being the code reader's job to figure out which purpose the code writer has intended.

Out of curiosity, what don't you like about Haskell?

Good question. I haven't revisited it in over 10 years. I think it was just too much "new" stuff to learn at once, making it feel too difficult to do anything in it at the time, especially considering I wasn't learning it full time.

Maybe now that I'm older and wiser (debatable) a revisit is in order, but lately I prefer dynamically typed languages (like Clojure and Elixir) to statically typed ones. I'll probably add it to my TODO list, but the list is long and time is short.

Well if you like Clojure you probably also appreciate how it doesn't just give you mutable variables everywhere but instead gives you different tools for different purposes. You have transients, atoms, agents, volatiles etc for different use cases.

Yup, there's never enough time. If you do try feel free to reach out to me at any time.

Oracle influenced / bought academia into teaching Java for a generation. See Dijkstra’s criticisms[1] from the time, from when his department was forced to stop teaching Haskell to undergrads for political reasons. Note that Haskell had not been too hard for Dijkstra’s undergrads.

Later, Python took its place, since people realized the Java ecosystem was way too complicated and was turning off would-be CS students. Python directly targeted the academic use case by having similarities to C, Java, and Bash——it was not a better language, it just made existing imperative and object-oriented assignments easier for classroom environments. Believe it or not, a lot of programmers and even academics sort of give up on exploring significantly unfamiliar directions after graduating.

[1] https://www.cs.utexas.edu/~EWD/OtherDocs/To%20the%20Budget%2...

Re Dijkstra:

He's asking for something that is really inappropriate. He lost in the CS department, and he wants the Budget Council to decide on what languages should be taught? Like they know anything about it!

He lost a political battle, and he's appealing it to the only place he can, and he's buttering them up to do it, but the people that actually know something about the topic decided against him already.

And, you're quoting only one side of the battle. One vocal and eloquent side, but only one side. Maybe look into why the UT CS department made that change? (And not why Dijkstra says they did.)

> He lost a political battle.

Political campaigns are often bought.

He mentions the expensive promotional campaign that was paid towards Java.

> the people that actually know something about the topic decided against him already

Matters of pedagogy often involve value judgements and trade-offs, with knowledge alone being unable to provide definitive answers.

However, Sun/Oracle did know that more money would flow their way if undergraduates were to learn Java. The letter suggests that one or both of them decided to act accordingly.

It’s questionable to assert that every knowledgeable faculty member thought that pivoting to Java was the best option. (Dijkstra himself is a counter-example?) From the looks of it, just a single department chair——not the full CS department——had the decision-making authority on this curriculum change.

> inappropriate

Would inappropriateness make his arguments any less true?

Why in an academic context would it be inappropriate to request input from additional stakeholders? If the letter was unconventional, remember that a purpose of the tenure system is to protect unconventionality.

The Budget Council is not a stakeholder in the CS curriculum. The Budget Council does not have the knowledge or expertise to say anything relevant about the matter - and Dijkstra should know that. That's why it's inappropriate.

I mean, look, if you had a letter signed by the majority of the department, complaining about the chair's decision, then the Budget Council might consider reversing the chair, on the authority of the expertise of the majority of the department. But overrule the chair on the basis of disagreement by one professor? No way. You can't run a university that way, because there's always at least one professor who disagrees with a decision.

An academic knows well that grants and other forms of financing are their lifeblood. It’s also how the government chooses its priorities within academia.

Admittedly, I don’t know anything about who was on the budget committee to which Dijkstra wrote this letter. But it is just ordinary for academics to write proposals outlining their priorities in hopes that the grant/budget/financing committee will bite.

I don't think that's it. I know plenty of people who were taught lisp first thing at university, and as soon as someone handed them an imperative language, they never looked at lisp again. And lisp is way easier than haskell IMO as IO is just a function and not a pilosophical concept

I wouldn’t assume that your colleagues were less capable as undergrads than the students that Dijkstra encountered at UT Austin.

Imperative languages do offer many advantages over Haskell, in that most coursework and industry jobs use them and that, consequently, their ecosystems are much further developed. These advantages are a consequence of university programs' alignment with the imperative and object-oriented programming paradigms, to Oracle's benefit.

Your colleagues having never looked back at lisp is hardly evidence that Haskell would have been too difficult for them or that Oracle didn’t have a hand in this.

I don't think that holds water. We've had functional programming for longer than oracle or java have existed, and for far longer than oracle has owned java. Haskell itself has been around for longer than java or oracle-owned java.

Functional programming just seems harder for people to get into. Perhaps it's bad for everyone that people don't make that effort, but it doesn't seem like a conspiracy

My mistake, at the time, Java was being promoted by Sun Microsystems, which only more recently became a part of Oracle.

The promotional campaign that Dijkstra mentions was perhaps orchestrated by Sun Microsystems, though perhaps not since Oracle was indirectly strategically aligned with Java, as the eventual acquisition shows.

Yes, it is more difficult to get into FP. However, asking the question why it became more difficult, when historically the opposite was true, is certainly worthwhile. Surely there was some cause.

> Oracle influenced / bought academia into teaching Java for a generation

I think you probably mean Sun? Or maybe that Oracle continued what Sun started.

Nah man, Oracle… here is a personal story. I was teaching at a Uni, introductory programming course. Dean hits me up and asks if I can teach introduction to web development as then current professor was going on maternity leave. I was like “heck yea, that sounds like fun.”

before the first class I get an email from one student asking if they must purchase the book for the class since it $275 (this is years ago) and I was taken aback, what kind of book costs $275 - even for a college textbook that was nuts. I told him to not purchase it until we meet for the first class. I go to the office and see my copy of the book, it is programming the web with oracle forms from oracle press!!!! I talked to Dean and he was like “yea, that is what we need to teach!” needless to say that, none of the kids bought the book, and I did NOT teach oracle forms, and I was never given that class again :)

That is wild

Thanks, I had unconsciously guessed Oracle, based on Dijkstra’s mention of Java’s expensive promotional campaign.

Sun and Oracle were strategically aligned at the time, so it could have been either or both.

My first CS class was in Scheme (R6 iirc), and the year after they switched to python. Then a thousand cries in failure to understand python metaclasses. They are garbage at the repl, and you have a distinct set of folks that edit their editors.

Most Python programmers don't really have to understand metaclasses or other advanced concepts like descriptors. The main metaclass they'd use would be to create abstract classes, and these days you can just subclass ABC.

I wish I'd have had either of those. C++ was the fad when I was going through, so freshmen learning how to write linked lists got a fast introduction to (and a hatred of) the STL.

Haskell is superb at handling persistent mutable state. The only problem is that you may have analysis paralysis from choosing between all the choices (many of them excellent).

> So why hasn't it happened?

4. History. In those types of discussions, there are always "rational" arguments presented, but this one is missing.

> One with lots of persistent mutable state.

You mean like a database? I don't see a problem here. In fact, there is a group of programs large enough, that Haskell fits nicely, that it cannot be 3; REST/HTTP APIs. This is pretty much your data goes in, data goes out.

> > One with lots of persistent mutable state.

> You mean like a database?

No, I mean like a routing switcher for a TV station. You have a set of inputs and a set of outputs, and you have various sources of control, and you have commands to switch outputs to different inputs. And when one source of control makes a change, you have to update all the other sources of control about the change, so that they have a current view of the world. The state of the current connections is the fundamental thing in the program - more even than controlling the hardware is.

Thanks. This does sound like a state machine, though, but the devil is probably in the details. Yes, here Haskell is probably a bad choice, and something where direct memory manipulation is bread and butter should do better. Which is completely fine; Haskell is a high level language.

But in your example, PHP is also a bad choice, and alas, it dwarfs Haskell in popularity. I can't really think of where PHP is a great fit, but Haskell isn't.

Sounds like you want green threads, a concurrent runtime, and best-in-class synchronisation primitives.

HTTP APIs are just an interface. The application behind it can be almost anything.