6 ms·

With Haskell, one always finds articles explaining how great it is, how its features (pure functionality) lend to correct code. But, articles explaining the cor

With Haskell, one always finds articles explaining how great it is, how its features (pure functionality) lend to correct code. But, articles explaining the core use cases and how only this language enabled solving it are rare. I'd love to read someone's decision postmortem that goes something like 'Here is a problem we were looking to solve. And here is how specific features A/B/C of Haskell helped us solve it well. Here's why Haskell was the correct choice for solving this problem'. What we instead have is 1000's of articles trying to teach us monads. Till such articles become mainstream, it will remain a niche language. The whole avoid success at all costs looks more like a meme to me than actual strategy. There are functional languages (Clojure(Script), Elm) which made pragmatic decisions about the feature sets and have found commercial success. But with Haskell, it seems a reverse process was followed. It starts with some (questionable?) assumptions like lazy evaluation is good and then builds on top of it. For commercially viable software, the process is generally reverse. You start with specific problems and build a feature set from it. The best way to understand this academic Vs. pragmatic approach is to look at Golang's relative success vs Haskell. No matter how much PL researcher snobs complain about golang, its creators started from real problems and chose some constraints carefully. The result is its widespread adoption in its niche (networked infrastructure code that can tolerate GC). Such cases are not documented for Haskell or are rare to find. It is perfectly alright and better to say, look this was a research language to find out how far we can go with certain choices and assumptions. But constant evangelism about how it is elegant etc does not help.

EddySchauHai 4y ago
I worked in a Haskell environment that used a lot of formal methods & some of those tools, such as Agda, would generate Haskell that could then be optimized for performance. It was pretty wild but for me, a test engineer, was a pain for more boring tasks like JSON parsing or calling Rest APIs etc :) It got me into property based testing though, and now I'm much more type-driven, so there were some really cool perks of working in such an env.
verandaguy 4y ago
>But, articles explaining the core use cases and how only this language enabled solving it are rare From my (limited) experience with Haskell, my impression is that it's strongest in domains that map _very_ well to formal mathematical models. Mathematical computation is an obvious example, but things like programming language parsers are also really intuitive to build in Haskell. My experience trying to use Haskell for other stuff — mainly, building web backends, my bread and butter back then — was painful. Simple CRUD against a database is actually pretty decent thanks to there being decent Postgres drivers and libraries, but the moment you need to handle arbitrarily-nested data structures (like a JSON request/response with a nontrivial schema), you run up against a lot of awkwardness, to the point that for the longest time this was known in Haskell as the "records problem." Lenses and similar tools have tried to solve this problem over the years, and maybe they have, but I moved on from the language when I saw how deep that rabbit hole went. None of this is to say Haskell isn't fun or rewarding, but it definitely has its strengths and weaknesses.
- havercosine 4y ago
  Thanks for writing about that experience, makes sense. My first to forays in the language ended the same way. I tried to do mainstream programming stuff in it but realised I wasn't making much progress in first few days and eventually moved on.
  - epgui 4y ago
    It sounds like you folks didn't give the language enough of a chance and may have felt the friction of trying to write Haskell in the style of another language. It takes a while to learn how to go with the grain, in any language. While I totally sympathize with this, I'm not sure it's a very good vantage point from which to judge a language.
    - pdimitar 4y ago
      Which goes back to the root comment and the issue it raised: Where are the practical Haskell tutorials. No preaching, no "you're holding it wrong", ONLY this: "you need to handle arbitrarily nested JSON? here's how".
ilrwbwrkhv 4y ago
josephcsible 4y ago
> But, articles explaining the core use cases and how only this language enabled solving it are rare. There isn't much that only one programming language can do, so it's not fair to ask for this. The benefits of using Haskell over other programming languages are that it's easier to reason about code in it, and you can have more assurance that code is correct.
jonnybgood 4y ago
I may get some flak for this but Haskell still being called a research language is doing Haskell a huge disservice for adoption. The new ideas of Haskell are now old and well-known in programming languages research for over a decade. Seeing Haskell as a research language causes the community, by and large, to remain in an academic-mindset. But what the Haskell community needs now is an engineering-mindset. I think Doctor_Ryner in the OP states it perfectly: “In other communities people mostly discuss regular production problems and data structures, while in a Haskell chat people discuss monads, applicative functors, crazy types and things like that.” This is why use cases and how only Haskell enabled solving it are rare.
- catach 4y ago
  I suspect that the community is overall quite happy with increased adoption being a non-goal. That is, it does not need to shift to an engineering-mindset because it does not value the consequences of that shift.
  - gilmi 4y ago
    I don't think that's correct. Especially since there's a community-led organization with the specific goal of increasing adoption https://haskell.foundation/ https://haskell.foundation/
    - kqr 4y ago
      I think there are many different people with different opinions in the community. The inofficial motto of 'avoid "success at all costs"' is not a joke. It's easy-ish to achieve success if you allow yourself to pander to the masses who don't always understand what they are missing, and there's always been an element in the Haskell community that tries to do what's right, notwithstanding what the large masses think.
      - gilmi 4y ago
        I agree that there are many opinions and that Haskell people don't want to compromise on what they see is the value of the language, but I've also seen a lot of people express their desire for more adoption. For example in threads talking about the haskell.org download page, in threads about improving learning resources, and with the Haskell Foundation. This desire is usually expressed with sentiments like "let's make this easier to learn" and "Let's fix this so it's not a footgun", and not "success at all cost".
gilmi 4y ago
I wrote an article of a few usecases and why I think Haskell is a good match for them: https://gilmi.me/blog/post/2020/04/28/consider-haskell https://gilmi.me/blog/post/2020/04/28/consider-haskell
hota_mazi 4y ago
You make a lot of awesome points. The lesson I derive from Haskell is that "If it compiles, it will work" 1. is inflated nonsense 2. has a lot less to do with Haskell-the-language than with Haskell-the-type-system I have observed a similar phenomenon with Rust. That statement is not perfect, it's hyperbole. If it compiles, it doesn't mean it will run (otherwise, why bother writing code? We just write function signatures and call it a day). But Rust's type system is incredibly sophisticated, just like Haskell's. And guess what... Rust supports mutability. It doesn't just support it, it encourages it. It tells you "Step over that fence, it's okay, I got your back". It's so liberating. The secret here is not functional programming. It's not immutability. It's a sound and powerful type system.
- zozbot234 4y ago
  Rust supports mutability that's bounded to a single program scope. That's a lot closer to functional immutability than to default-shared mutability as used in most procedural languages. Shared mutability is very clearly opt-in, and usually exceptional.
spion 4y ago
> The result is its widespread adoption in its niche And everywhere else, unfortunately. Go is an overreaction in the opposite direction. In 2010 I can't agree that there is a good reason to make a language without generics and reasonable error handling from the very start.
- klodolph 4y ago
  Seems like a lot of people disagreed, because Go is definitely a “successful” language. Kind of getting sick of hearing these same complaints, over and over, to be honest.
  - josephcsible 4y ago
    Go is only successful because Google spent so much money propping it up by paying people to write stuff in it. It has so many major flaws that it would have had no chance of taking off otherwise. If Google had spent the same amount of money on Haskell instead, it'd be even more popular than Go is today.
    - HeyImAlex 4y ago
      Go is very simple, provides decent static type safety, has a nice concurrency model, and compiles to fast static binaries across all major platforms. People choose it all the time because it’s a great choice. A wild number of popular open source tools are written in go, very few of them created by google. As someone who wrote go for many years I think you’re overstating how limiting it’s “major flaws” are. And fwiw go ranks much higher than haskell on stack overflow’s annual developer survey.
      - epgui 4y ago
        Everything you just said either applies equally to Haskell, or is a cultural factor mostly explained by what the parent comment wrote.
        4y ago
whateveracct 4y ago
Who cares about "articles"? Go program in it. It's clearly superior if you do more than navelgaze.
bawolff 4y ago
> But, articles explaining the core use cases and how only this language enabled solving it are rare. Articles of that form are usually BS though, for any language. These are general purpose programming languages. They all have different benefits and drawbacks, but you can usually use any of them to do anything you want.
aranchelk 4y ago
> But with Haskell, it seems a reverse process was followed. It starts with some (questionable?) assumptions like lazy evaluation is good and then builds on top of it. Haskell was created by researches who wanted to study properties of lazy functional programming. I’ve never heard anyone say they did it because lazy evaluation was “good”, it was their area of research. The co-creator has even said that if he had to do it over again it might be better if it were strictly evaluated. I worked in Haskell for a few years before switching over to a very closely related but strictly evaluated language, PureScript. The pureness and laziness of Haskell forced the creators to work out monads for IO which I find extremely useful. Haskell-like monads certainly can (and have) been implemented in strictly evaluated languages. I don’t miss implicit laziness very often, but I’ll say with partially applied functions, it’s nice to know that values will be calculated as needed and results shared across invocations once those functions are fully applied. That’s something I wish we had in PureScript. Note that in addition to laziness this also requires a compiler optimization that moves let bindings out of inner functions, aka let-floating. Laziness is also nice as it allows you to be very declarative, defining what things are without ever worrying about the calculations running when you don’t need the result. In practice it’s easy enough to create thunks manually and evaluate them when needed. Doing this can get tedious and the resulting code is less succinct.

EddySchauHai 4y ago

I worked in a Haskell environment that used a lot of formal methods & some of those tools, such as Agda, would generate Haskell that could then be optimized for performance. It was pretty wild but for me, a test engineer, was a pain for more boring tasks like JSON parsing or calling Rest APIs etc :) It got me into property based testing though, and now I'm much more type-driven, so there were some really cool perks of working in such an env.

verandaguy 4y ago

>But, articles explaining the core use cases and how only this language enabled solving it are rare From my (limited) experience with Haskell, my impression is that it's strongest in domains that map _very_ well to formal mathematical models. Mathematical computation is an obvious example, but things like programming language parsers are also really intuitive to build in Haskell. My experience trying to use Haskell for other stuff — mainly, building web backends, my bread and butter back then — was painful. Simple CRUD against a database is actually pretty decent thanks to there being decent Postgres drivers and libraries, but the moment you need to handle arbitrarily-nested data structures (like a JSON request/response with a nontrivial schema), you run up against a lot of awkwardness, to the point that for the longest time this was known in Haskell as the "records problem." Lenses and similar tools have tried to solve this problem over the years, and maybe they have, but I moved on from the language when I saw how deep that rabbit hole went. None of this is to say Haskell isn't fun or rewarding, but it definitely has its strengths and weaknesses.

havercosine 4y ago
Thanks for writing about that experience, makes sense. My first to forays in the language ended the same way. I tried to do mainstream programming stuff in it but realised I wasn't making much progress in first few days and eventually moved on.
- epgui 4y ago
  It sounds like you folks didn't give the language enough of a chance and may have felt the friction of trying to write Haskell in the style of another language. It takes a while to learn how to go with the grain, in any language. While I totally sympathize with this, I'm not sure it's a very good vantage point from which to judge a language.
  - pdimitar 4y ago
    Which goes back to the root comment and the issue it raised: Where are the practical Haskell tutorials. No preaching, no "you're holding it wrong", ONLY this: "you need to handle arbitrarily nested JSON? here's how".

ilrwbwrkhv 4y ago

josephcsible 4y ago

> But, articles explaining the core use cases and how only this language enabled solving it are rare. There isn't much that only one programming language can do, so it's not fair to ask for this. The benefits of using Haskell over other programming languages are that it's easier to reason about code in it, and you can have more assurance that code is correct.

jonnybgood 4y ago

I may get some flak for this but Haskell still being called a research language is doing Haskell a huge disservice for adoption. The new ideas of Haskell are now old and well-known in programming languages research for over a decade. Seeing Haskell as a research language causes the community, by and large, to remain in an academic-mindset. But what the Haskell community needs now is an engineering-mindset. I think Doctor_Ryner in the OP states it perfectly: “In other communities people mostly discuss regular production problems and data structures, while in a Haskell chat people discuss monads, applicative functors, crazy types and things like that.” This is why use cases and how only Haskell enabled solving it are rare.

catach 4y ago
I suspect that the community is overall quite happy with increased adoption being a non-goal. That is, it does not need to shift to an engineering-mindset because it does not value the consequences of that shift.
- gilmi 4y ago
  I don't think that's correct. Especially since there's a community-led organization with the specific goal of increasing adoption https://haskell.foundation/ https://haskell.foundation/
  - kqr 4y ago
    I think there are many different people with different opinions in the community. The inofficial motto of 'avoid "success at all costs"' is not a joke. It's easy-ish to achieve success if you allow yourself to pander to the masses who don't always understand what they are missing, and there's always been an element in the Haskell community that tries to do what's right, notwithstanding what the large masses think.
    - gilmi 4y ago
      I agree that there are many opinions and that Haskell people don't want to compromise on what they see is the value of the language, but I've also seen a lot of people express their desire for more adoption. For example in threads talking about the haskell.org download page, in threads about improving learning resources, and with the Haskell Foundation. This desire is usually expressed with sentiments like "let's make this easier to learn" and "Let's fix this so it's not a footgun", and not "success at all cost".

gilmi 4y ago

I wrote an article of a few usecases and why I think Haskell is a good match for them: https://gilmi.me/blog/post/2020/04/28/consider-haskell https://gilmi.me/blog/post/2020/04/28/consider-haskell

hota_mazi 4y ago

You make a lot of awesome points. The lesson I derive from Haskell is that "If it compiles, it will work" 1. is inflated nonsense 2. has a lot less to do with Haskell-the-language than with Haskell-the-type-system I have observed a similar phenomenon with Rust. That statement is not perfect, it's hyperbole. If it compiles, it doesn't mean it will run (otherwise, why bother writing code? We just write function signatures and call it a day). But Rust's type system is incredibly sophisticated, just like Haskell's. And guess what... Rust supports mutability. It doesn't just support it, it encourages it. It tells you "Step over that fence, it's okay, I got your back". It's so liberating. The secret here is not functional programming. It's not immutability. It's a sound and powerful type system.

zozbot234 4y ago
Rust supports mutability that's bounded to a single program scope. That's a lot closer to functional immutability than to default-shared mutability as used in most procedural languages. Shared mutability is very clearly opt-in, and usually exceptional.

spion 4y ago

> The result is its widespread adoption in its niche And everywhere else, unfortunately. Go is an overreaction in the opposite direction. In 2010 I can't agree that there is a good reason to make a language without generics and reasonable error handling from the very start.

klodolph 4y ago
Seems like a lot of people disagreed, because Go is definitely a “successful” language. Kind of getting sick of hearing these same complaints, over and over, to be honest.
- josephcsible 4y ago
  Go is only successful because Google spent so much money propping it up by paying people to write stuff in it. It has so many major flaws that it would have had no chance of taking off otherwise. If Google had spent the same amount of money on Haskell instead, it'd be even more popular than Go is today.
  - HeyImAlex 4y ago
    Go is very simple, provides decent static type safety, has a nice concurrency model, and compiles to fast static binaries across all major platforms. People choose it all the time because it’s a great choice. A wild number of popular open source tools are written in go, very few of them created by google. As someone who wrote go for many years I think you’re overstating how limiting it’s “major flaws” are. And fwiw go ranks much higher than haskell on stack overflow’s annual developer survey.
    - epgui 4y ago
      Everything you just said either applies equally to Haskell, or is a cultural factor mostly explained by what the parent comment wrote.
      - 4y ago

whateveracct 4y ago

Who cares about "articles"? Go program in it. It's clearly superior if you do more than navelgaze.

bawolff 4y ago

> But, articles explaining the core use cases and how only this language enabled solving it are rare. Articles of that form are usually BS though, for any language. These are general purpose programming languages. They all have different benefits and drawbacks, but you can usually use any of them to do anything you want.

aranchelk 4y ago

> But with Haskell, it seems a reverse process was followed. It starts with some (questionable?) assumptions like lazy evaluation is good and then builds on top of it. Haskell was created by researches who wanted to study properties of lazy functional programming. I’ve never heard anyone say they did it because lazy evaluation was “good”, it was their area of research. The co-creator has even said that if he had to do it over again it might be better if it were strictly evaluated. I worked in Haskell for a few years before switching over to a very closely related but strictly evaluated language, PureScript. The pureness and laziness of Haskell forced the creators to work out monads for IO which I find extremely useful. Haskell-like monads certainly can (and have) been implemented in strictly evaluated languages. I don’t miss implicit laziness very often, but I’ll say with partially applied functions, it’s nice to know that values will be calculated as needed and results shared across invocations once those functions are fully applied. That’s something I wish we had in PureScript. Note that in addition to laziness this also requires a compiler optimization that moves let bindings out of inner functions, aka let-floating. Laziness is also nice as it allows you to be very declarative, defining what things are without ever worrying about the calculations running when you don’t need the result. In practice it’s easy enough to create thunks manually and evaluate them when needed. Doing this can get tedious and the resulting code is less succinct.