5 ms·

Accessibility is not an issue. It takes only a little bit of effort to get productive with a Haskell codebase. I think it's more of a mental block because the l

Accessibility is not an issue. It takes only a little bit of effort to get productive with a Haskell codebase. I think it's more of a mental block because the language is different from what one might be used to. What Haskell needs, and doesn't have, is a compelling reason for people to make that small effort (i.e. the killer usecase).

AnimalMuppet 2y ago
"Relatively bug free code very fast" sounds like a killer use case to me. So why hasn't it happened? Some possibilities: 1. People are just ignorant/unenlightened. 2. Haskell is too hard to use for most people. I think that different programmers think in different ways, and therefore find different languages to be "natural". To those whom Haskell fits, it really fits, and they have a hard time understanding why it isn't that way for everyone, so they wind up at 1. But for those who it doesn't fit, it's this brick wall that never makes sense. (Yes, this is about the same as 1, just seen from the other side. It says the problem is the language, not the people - the language really doesn't fit most people very well, and we can change languages easier than we can change people.) 3. Haskell isn't a good fit for many kinds of programming. The kind of programs where it fits, it's like a superpower. The kinds where it doesn't, though, it's like picking your nose with boxing gloves on. (Shout out to Michael Pavlinch, from whom I stole that phrase.) What kinds of programs fit? "If you can think of your program like a pipe" is the best explanation I've seen - if data flows in, gets transformed, flows out. What kind of program doesn't fit? One with lots of persistent mutable state. Especially, one where the persistent mutable state is due to the problem, not just to the implementation. Myself, I lean toward a combination of 2 and 3.
- youerbt 2y ago
  > 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.
  - layer8 2y ago
    HTTP APIs are just an interface. The application behind it can be almost anything.
  - AnimalMuppet 2y ago
    > > 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.
    - youerbt 2y ago
      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.
    - mrkeen 2y ago
      Sounds like you want green threads, a concurrent runtime, and best-in-class synchronisation primitives.
- odyssey7 2y ago
  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%20Council%20concerning%20Haskell.pdf https://www.cs.utexas.edu/~EWD/OtherDocs/To%20the%20Budget%2...
  - chikere232 2y ago
    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
    - odyssey7 2y ago
      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.
      - chikere232 2y ago
        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
- thdhhghgbhy 2y ago
  >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.
  - AnimalMuppet 2y ago
    > 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.
    - thdhhghgbhy 2y ago
      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/transformers.md 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.
  - tome 2y ago
    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-unrepresentable/ 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/ 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.
- haskman 2y ago
  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.
- kccqzy 2y ago
  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.
  - bcrosby95 2y ago
    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.
    - kccqzy 2y ago
      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.
    - tome 2y ago
      Out of curiosity, what don't you like about Haskell?
      - bcrosby95 2y ago
        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.
- tome 2y ago
  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).
zwnow 2y ago
I don't have a math background. Without a math background, you will have a bad time with Haskell.
- tome 2y ago
  There are many successful Haskellers without a math background.
- TuringTest 2y ago
  Haskell can be taught as recursive programming, learning about accumulator parameters and high order functions. A background in logic (which most programmers have to some degree) is more useful than an approach in math in that regard.
- yakshaving_jgt 2y ago
  What are you trying to achieve by spreading fear, uncertainty, and doubt here? I don't have a math background. I failed high school maths. I've been working as a professional Haskell programmer for several years. What you are saying is just demonstrably not true. So why are you saying it?

AnimalMuppet 2y ago

"Relatively bug free code very fast" sounds like a killer use case to me. So why hasn't it happened? Some possibilities: 1. People are just ignorant/unenlightened. 2. Haskell is too hard to use for most people. I think that different programmers think in different ways, and therefore find different languages to be "natural". To those whom Haskell fits, it really fits, and they have a hard time understanding why it isn't that way for everyone, so they wind up at 1. But for those who it doesn't fit, it's this brick wall that never makes sense. (Yes, this is about the same as 1, just seen from the other side. It says the problem is the language, not the people - the language really doesn't fit most people very well, and we can change languages easier than we can change people.) 3. Haskell isn't a good fit for many kinds of programming. The kind of programs where it fits, it's like a superpower. The kinds where it doesn't, though, it's like picking your nose with boxing gloves on. (Shout out to Michael Pavlinch, from whom I stole that phrase.) What kinds of programs fit? "If you can think of your program like a pipe" is the best explanation I've seen - if data flows in, gets transformed, flows out. What kind of program doesn't fit? One with lots of persistent mutable state. Especially, one where the persistent mutable state is due to the problem, not just to the implementation. Myself, I lean toward a combination of 2 and 3.

youerbt 2y ago
> 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.
- layer8 2y ago
  HTTP APIs are just an interface. The application behind it can be almost anything.
- AnimalMuppet 2y ago
  > > 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.
  - youerbt 2y ago
    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.
  - mrkeen 2y ago
    Sounds like you want green threads, a concurrent runtime, and best-in-class synchronisation primitives.
odyssey7 2y ago
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%20Council%20concerning%20Haskell.pdf https://www.cs.utexas.edu/~EWD/OtherDocs/To%20the%20Budget%2...
- chikere232 2y ago
  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
  - odyssey7 2y ago
    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.
    - chikere232 2y ago
      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
thdhhghgbhy 2y ago
>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.
- AnimalMuppet 2y ago
  > 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.
  - thdhhghgbhy 2y ago
    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/transformers.md 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.
- tome 2y ago
  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-unrepresentable/ 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/ 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.
haskman 2y ago
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.
kccqzy 2y ago
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.
- bcrosby95 2y ago
  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.
  - kccqzy 2y ago
    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.
  - tome 2y ago
    Out of curiosity, what don't you like about Haskell?
    - bcrosby95 2y ago
      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.
tome 2y ago
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).

zwnow 2y ago

I don't have a math background. Without a math background, you will have a bad time with Haskell.

tome 2y ago
There are many successful Haskellers without a math background.
TuringTest 2y ago
Haskell can be taught as recursive programming, learning about accumulator parameters and high order functions. A background in logic (which most programmers have to some degree) is more useful than an approach in math in that regard.
yakshaving_jgt 2y ago
What are you trying to achieve by spreading fear, uncertainty, and doubt here? I don't have a math background. I failed high school maths. I've been working as a professional Haskell programmer for several years. What you are saying is just demonstrably not true. So why are you saying it?