7 ms·

Is Haskell really the language of geniuses and academia? (2019)

41 points by synergy20 4y ago

evelynsalt 4y ago
A lot of Blub programmers exist. To them anything like Haskell is a weird language. Source: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
havercosine 4y ago
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.
hardwaresofton 4y ago
I’ve found this explanation to be useful and easy: Haskell is the Mercedes of programming languages. It has features you didn’t know you wanted or needed and eventually other languages will get there, and Haskell will seem average/harder to differentiate. I’ve written a more practical post on why Haskell is worth using[0], excuse the clickbait title. [0]: https://vadosware.io/post/how-and-why-haskell-is-better/ https://vadosware.io/post/how-and-why-haskell-is-better/
- asciiresort 4y ago
  There’s a reason Toyotas sell like hotcakes. It gets you from A-to-B reliably.
  - whateveracct 4y ago
    But if you can afford more and enjoy the craft and skill of driving, you probably buy the Mercedes. Most SWE's brains can't afford more though, sadly.
  - hardwaresofton 4y ago
    You're right, and that's why I like my analogy -- Toyotas get you there, but they got you there a lot more dangerously before airbags or ABS were invented (Mercedes innovated those things). You don't need a Mercedes these days, and that's a result of other companies adopting things that and increase safety, etc. We should expect this of a healthy ecosystem!
richardjam73 4y ago
I really don't like the elitism coming off the title here. You don't need to be a genius or an academic to use languages like this. If people want to promote what the ML family can do they should concentrate on the problems that these languages solve and what tools the languages offer programmers.
- IncRnd 4y ago
  That's discussed inside the article.
ge96 4y ago
lol I'll get back to you when I finish casually learning from my book
epgui 4y ago
In my experience, people who ask questions like "why should I learn about X when I don't already see its practical applications" are just not people who learn a lot of things, relatively and generally speaking. That's not a value judgment, just an observation. I don't think it takes any special ability or particular intelligence to be drawn to a language like Haskell-- All you really need is real genuine curiosity, an inclination to learn something you don't already know, and that's something that "geniuses and academia" have a lot of.
- spion 4y ago
  There are many things competing for people's time and attention. Why should I learn this is a valid question when you have several dozen other potential things you're looking at learning.
  - epgui 4y ago
    While that's true, in practice I have not found that people tend to spend their time learning other unfamiliar things-- rather, they often either waste their time, or spend their time learning things they are already somewhat familiar with. There's nothing wrong with that, but going outside the comfort zone is how you maximize perspective. In other words, it's pretty much completely impossible to convince someone that it would be really worth their time to learn more maths (eg.: calculus, linear algebra, whatever)... The only way they'll see the practical value of doing so is if they actually do it.
    - spion 4y ago
      Yes, I think there is a culture in mathematics where people believe this to be the case, and I think its not correct. I can think of several ways to motivate software engineers to learn more category theory (e.g. "did you know that MapReduce is basically an application of monoids?" or "did you know you can solve fast document layout updates with monoids?"). One thing I wonder about though. You say "curiosity" - can you explain what this means to you? Why are you curious about a certain concept? There are thousands of things to learn in the world - are you curious about all of them?
bitwize 4y ago
I thought that was Rust now?
sidcool 4y ago
Yes, Haskell started as a pure academic endeavour. In fact I think the creators tried very hard not to compromise on its pure Math-y focus. But that exactly contributed to its success (ironic). I see Haskell being used by Big tech as well.
- deleted 4y ago
  [deleted]
roenxi 4y ago
There are two issues that are really hard to articulate in a language critique: 1) There is no easy way to learn the language. Try explaining that without looking ignorant. 2) The software written in this language is too hard to read and understand. Do either of these problems manifest in Haskell? No idea. But I've seen them manifest in other systems and once I know about them suddenly there is an obvious and suspicious silence of people talking about clear problems. When a group of developers see something they don't understand they go quiet because it is hard to tell if the thing is inherently too hard or if the developer themselves just doesn't get it. Happens a bit in the lisps, I think. There isn't any privileged syntax for loops and conditionals so there are no hints about what control flow constructs to use. People aren't about to stand up and say they don't really understand what control structures are should be used when. They'd just look silly. So the topic doesn't get a lot of discussion despite being important & people go use languages where loop statements get special syntax.
- spion 4y ago
  I've tried to articulate this through pointing out that the documentation culture of Haskell is lacking and indeed I've been called "willingly ignorant, and proud to state that fact publicly" IMO thats really the only remaining problem of Haskell. Most of its documentation is just plain terrible. Rust is probably more difficult to learn as a language, yet the documentation culture is so awesome that one can power through.
  - kqr 4y ago
    A large part of this (and why you will find it hard to find Haskell developers who admit the state of the documentation is lacking) is that documentation isn't bad -- it's specifically apprentice-level documentation for specific libraries/use-cases that is bad. In other words, journeyman users who are experienced in "following the types" will find plenty of really high-quality documentation. Total novices who need an introduction to the language will also find high-quality material (though this is more of a recent development). However, once you're past the novice stage and at the apprentice level where you want to accomplish something specific using some libraries, there's nothing for you there. You have to ask someone at the next journeyman level to sit with you and guide you through following the types. That is limiting, and under-recognised, I think.
galaxyLogic 4y ago
Laziness is "cool", but is it really needed? I don't know any other commonly known languages that have that as a feature. Is it needed in general, or is it needed in Haskell in particular? Same thing seems to apply to monads. Haskell programmers use them a lot but other languages seem to work just fine without them. So my guess is that many of the special features of Haskell are solutions to problems you will have if you insist that language is lazy and pure.
- nequo 4y ago
  There is the argument that lazy evaluation improves composability and thus code reuse.[1] Edward Kmett also described how he uses laziness on Reddit sometime ago.[2] [1] http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev... [2] https://www.reddit.com/r/haskell/comments/l98v73/comment/glgun65/ https://www.reddit.com/r/haskell/comments/l98v73/comment/glg...
- munchler 4y ago
  There are definitely scenarios where laziness is crucial. Haskell is the only mainstream language I know of where laziness is the default, but many languages offer laziness when needed. (E.g. IEnumerable interface in C#.) Monads are essential for "effectful" programming in a functional language. Imperative languages don't need monads, because everything they do is effectful (which leads to unnecessary side effects, and from there to a plethora of errors).
  - epgui 4y ago
    I believe clojure has laziness out of the box as well. While both languages are functional, in contrast to Haskell, clojure doesn't have functors or monads. My understanding is that the same problem is essentially solved in a different way with macros.
    - munchler 4y ago
      According to https://clojure-doc.org/articles/language/laziness/ https://clojure-doc.org/articles/language/laziness/, Clojure isn't lazy by default, but does support lazy sequences (like IEnumerable in C#).
munchler 4y ago
I think it's better to put aside the hype about "geniuses" and break this down into two separate questions: 1. Is functional programming really better than other approaches? (My opinion: Yes, for most applications, although it can sometimes feel more difficult.) 2. Is Haskell really better than other functional programming languages. (My opinion: Haskell has some powerful features that other FP languages lack, but it is often less practical.) Bottom line: The most important thing is to grok functional programming as a paradigm. There are several good functional programming languages to choose from. Personally, I'm a big fan of F#.
unixhero 4y ago
I for one could not learn it.
kazinator 4y ago
How do you do this in Haskell: read a variable number of lists from standard input, until the nil symbol is seen. The lists are heterogeneous: they can contain any mixture of numbers, symbols, strings or any other objects. Then zip them together (truncating them to the length of the shortest one). TXR Lisp: 1> [apply zip (gun (read))] (1 2 3) (a b c) ("foo" 3 :bar) nil [Ctrl-D][Enter] ((1 a "foo") (2 b 3) (3 c :bar)) CL: [2]> (apply #'mapcar #'list (loop for x = (read) while x collect x)) (1 2 3) (a b c) ("foo" 3 :bar) nil ((1 A "foo") (2 B 3) (3 C :BAR))
- kqr 4y ago
  How are you using this zipped list later? That could influence the design of the parsing function and the intermediary data structure.
  - kazinator 4y ago
    That's the sort of thing I worry about when I'm coding in C. Here, the parsing is done; the intermediate data structure is built in. For now, it's printed to the console and thrown away (becomes garbage), but if anything else is done with it, it will be in that same form.
    - kqr 4y ago
      If you want a language where the compiler does not care about how you use your data (and will not help you avoid silly mistakes) then Haskell is not the language for you. It's possible to ask the Haskell compiler to not care, but this would be so far from idiomatic Haskell that it wouldn't help you if I wrote that code here, I don't think.
      - tlavoie 4y ago
        Is the question not just one of defining the sets of "things" that are being accepted here? It's not that the compiler shouldn't care, but that you have defined an appropriate data structure and set of acceptable types that you would nicely pattern-match on when using them later. To @kazinator's point, it's not quite going to be just lists of random things, in that Haskell's list elements are all the same type, unlike what Common Lisp lets you do. I'd be more curious whether this could be lists of "Thing", where that Thing type is a typeclass that is inclusive of all the sorts of data you would expect to handle.
sys_64738 4y ago
Except for teaching what a functional programming language is, what use cases does Haskell actual provide for employers? I’ve never seen a functional language used in industry. Did I miss it?
kleingeld 4y ago
Until recently, learning Haskell for solving "real-world" problems is not at all easy. But there are now a lot more resources that one can consult. I think it is highly rewarding to learn to program in Haskell. It offers you another perspective of approaching a computational problem and has a great ecosystem for many applications. And if you ever want to get into theorem-proving with Coq or Agda, knowing Haskell is a huge bonus. My suggested learning path is as follows: 1. Read Get Programming with Haskell and do the Haskell MOOC at https://haskell.mooc.fi/ https://haskell.mooc.fi/ at the same time. 2. Read sections in Haskell Programming from First Principles not covered in 1. 3. Read Haskell in Depth. Many years ago, I tried to learn Haskell from Haskell Programming from First Principles but couldn't get to the point I could write meaningful applications. I gave up after about a year. Early this year, I completed the Haskell MOOC and read most of Haskell in Depth and now I have a much better command of the language. And doing exercises on CodeWars, Hackerrank, and Exercism really help. I would advise ignoring both the glowing praises and scathing criticisms. Learn it well enough and form your own judgement, assuming of course that you have time to do so.

41 points by synergy20 4y ago

A lot of Blub programmers exist. To them anything like Haskell is a weird language. Source: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

havercosine 4y ago

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.

hardwaresofton 4y ago

I’ve found this explanation to be useful and easy: Haskell is the Mercedes of programming languages. It has features you didn’t know you wanted or needed and eventually other languages will get there, and Haskell will seem average/harder to differentiate. I’ve written a more practical post on why Haskell is worth using[0], excuse the clickbait title. [0]: https://vadosware.io/post/how-and-why-haskell-is-better/ https://vadosware.io/post/how-and-why-haskell-is-better/

asciiresort 4y ago
There’s a reason Toyotas sell like hotcakes. It gets you from A-to-B reliably.
- whateveracct 4y ago
  But if you can afford more and enjoy the craft and skill of driving, you probably buy the Mercedes. Most SWE's brains can't afford more though, sadly.
- hardwaresofton 4y ago
  You're right, and that's why I like my analogy -- Toyotas get you there, but they got you there a lot more dangerously before airbags or ABS were invented (Mercedes innovated those things). You don't need a Mercedes these days, and that's a result of other companies adopting things that and increase safety, etc. We should expect this of a healthy ecosystem!

richardjam73 4y ago

I really don't like the elitism coming off the title here. You don't need to be a genius or an academic to use languages like this. If people want to promote what the ML family can do they should concentrate on the problems that these languages solve and what tools the languages offer programmers.

IncRnd 4y ago
That's discussed inside the article.

ge96 4y ago

lol I'll get back to you when I finish casually learning from my book

epgui 4y ago

In my experience, people who ask questions like "why should I learn about X when I don't already see its practical applications" are just not people who learn a lot of things, relatively and generally speaking. That's not a value judgment, just an observation. I don't think it takes any special ability or particular intelligence to be drawn to a language like Haskell-- All you really need is real genuine curiosity, an inclination to learn something you don't already know, and that's something that "geniuses and academia" have a lot of.

spion 4y ago
There are many things competing for people's time and attention. Why should I learn this is a valid question when you have several dozen other potential things you're looking at learning.
- epgui 4y ago
  While that's true, in practice I have not found that people tend to spend their time learning other unfamiliar things-- rather, they often either waste their time, or spend their time learning things they are already somewhat familiar with. There's nothing wrong with that, but going outside the comfort zone is how you maximize perspective. In other words, it's pretty much completely impossible to convince someone that it would be really worth their time to learn more maths (eg.: calculus, linear algebra, whatever)... The only way they'll see the practical value of doing so is if they actually do it.
  - spion 4y ago
    Yes, I think there is a culture in mathematics where people believe this to be the case, and I think its not correct. I can think of several ways to motivate software engineers to learn more category theory (e.g. "did you know that MapReduce is basically an application of monoids?" or "did you know you can solve fast document layout updates with monoids?"). One thing I wonder about though. You say "curiosity" - can you explain what this means to you? Why are you curious about a certain concept? There are thousands of things to learn in the world - are you curious about all of them?

bitwize 4y ago

I thought that was Rust now?

sidcool 4y ago

Yes, Haskell started as a pure academic endeavour. In fact I think the creators tried very hard not to compromise on its pure Math-y focus. But that exactly contributed to its success (ironic). I see Haskell being used by Big tech as well.

deleted 4y ago
[deleted]

roenxi 4y ago

There are two issues that are really hard to articulate in a language critique: 1) There is no easy way to learn the language. Try explaining that without looking ignorant. 2) The software written in this language is too hard to read and understand. Do either of these problems manifest in Haskell? No idea. But I've seen them manifest in other systems and once I know about them suddenly there is an obvious and suspicious silence of people talking about clear problems. When a group of developers see something they don't understand they go quiet because it is hard to tell if the thing is inherently too hard or if the developer themselves just doesn't get it. Happens a bit in the lisps, I think. There isn't any privileged syntax for loops and conditionals so there are no hints about what control flow constructs to use. People aren't about to stand up and say they don't really understand what control structures are should be used when. They'd just look silly. So the topic doesn't get a lot of discussion despite being important & people go use languages where loop statements get special syntax.

spion 4y ago
I've tried to articulate this through pointing out that the documentation culture of Haskell is lacking and indeed I've been called "willingly ignorant, and proud to state that fact publicly" IMO thats really the only remaining problem of Haskell. Most of its documentation is just plain terrible. Rust is probably more difficult to learn as a language, yet the documentation culture is so awesome that one can power through.
- kqr 4y ago
  A large part of this (and why you will find it hard to find Haskell developers who admit the state of the documentation is lacking) is that documentation isn't bad -- it's specifically apprentice-level documentation for specific libraries/use-cases that is bad. In other words, journeyman users who are experienced in "following the types" will find plenty of really high-quality documentation. Total novices who need an introduction to the language will also find high-quality material (though this is more of a recent development). However, once you're past the novice stage and at the apprentice level where you want to accomplish something specific using some libraries, there's nothing for you there. You have to ask someone at the next journeyman level to sit with you and guide you through following the types. That is limiting, and under-recognised, I think.

galaxyLogic 4y ago

Laziness is "cool", but is it really needed? I don't know any other commonly known languages that have that as a feature. Is it needed in general, or is it needed in Haskell in particular? Same thing seems to apply to monads. Haskell programmers use them a lot but other languages seem to work just fine without them. So my guess is that many of the special features of Haskell are solutions to problems you will have if you insist that language is lazy and pure.

nequo 4y ago
There is the argument that lazy evaluation improves composability and thus code reuse.[1] Edward Kmett also described how he uses laziness on Reddit sometime ago.[2] [1] http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html http://augustss.blogspot.com/2011/05/more-points-for-lazy-ev... [2] https://www.reddit.com/r/haskell/comments/l98v73/comment/glgun65/ https://www.reddit.com/r/haskell/comments/l98v73/comment/glg...
munchler 4y ago
There are definitely scenarios where laziness is crucial. Haskell is the only mainstream language I know of where laziness is the default, but many languages offer laziness when needed. (E.g. IEnumerable interface in C#.) Monads are essential for "effectful" programming in a functional language. Imperative languages don't need monads, because everything they do is effectful (which leads to unnecessary side effects, and from there to a plethora of errors).
- epgui 4y ago
  I believe clojure has laziness out of the box as well. While both languages are functional, in contrast to Haskell, clojure doesn't have functors or monads. My understanding is that the same problem is essentially solved in a different way with macros.
  - munchler 4y ago
    According to https://clojure-doc.org/articles/language/laziness/ https://clojure-doc.org/articles/language/laziness/, Clojure isn't lazy by default, but does support lazy sequences (like IEnumerable in C#).

munchler 4y ago

I think it's better to put aside the hype about "geniuses" and break this down into two separate questions: 1. Is functional programming really better than other approaches? (My opinion: Yes, for most applications, although it can sometimes feel more difficult.) 2. Is Haskell really better than other functional programming languages. (My opinion: Haskell has some powerful features that other FP languages lack, but it is often less practical.) Bottom line: The most important thing is to grok functional programming as a paradigm. There are several good functional programming languages to choose from. Personally, I'm a big fan of F#.

unixhero 4y ago

I for one could not learn it.

kazinator 4y ago

How do you do this in Haskell: read a variable number of lists from standard input, until the nil symbol is seen. The lists are heterogeneous: they can contain any mixture of numbers, symbols, strings or any other objects. Then zip them together (truncating them to the length of the shortest one). TXR Lisp: 1> [apply zip (gun (read))] (1 2 3) (a b c) ("foo" 3 :bar) nil [Ctrl-D][Enter] ((1 a "foo") (2 b 3) (3 c :bar)) CL: [2]> (apply #'mapcar #'list (loop for x = (read) while x collect x)) (1 2 3) (a b c) ("foo" 3 :bar) nil ((1 A "foo") (2 B 3) (3 C :BAR))

kqr 4y ago
How are you using this zipped list later? That could influence the design of the parsing function and the intermediary data structure.
- kazinator 4y ago
  That's the sort of thing I worry about when I'm coding in C. Here, the parsing is done; the intermediate data structure is built in. For now, it's printed to the console and thrown away (becomes garbage), but if anything else is done with it, it will be in that same form.
  - kqr 4y ago
    If you want a language where the compiler does not care about how you use your data (and will not help you avoid silly mistakes) then Haskell is not the language for you. It's possible to ask the Haskell compiler to not care, but this would be so far from idiomatic Haskell that it wouldn't help you if I wrote that code here, I don't think.
    - tlavoie 4y ago
      Is the question not just one of defining the sets of "things" that are being accepted here? It's not that the compiler shouldn't care, but that you have defined an appropriate data structure and set of acceptable types that you would nicely pattern-match on when using them later. To @kazinator's point, it's not quite going to be just lists of random things, in that Haskell's list elements are all the same type, unlike what Common Lisp lets you do. I'd be more curious whether this could be lists of "Thing", where that Thing type is a typeclass that is inclusive of all the sorts of data you would expect to handle.

sys_64738 4y ago

Except for teaching what a functional programming language is, what use cases does Haskell actual provide for employers? I’ve never seen a functional language used in industry. Did I miss it?

kleingeld 4y ago

Until recently, learning Haskell for solving "real-world" problems is not at all easy. But there are now a lot more resources that one can consult. I think it is highly rewarding to learn to program in Haskell. It offers you another perspective of approaching a computational problem and has a great ecosystem for many applications. And if you ever want to get into theorem-proving with Coq or Agda, knowing Haskell is a huge bonus. My suggested learning path is as follows: 1. Read Get Programming with Haskell and do the Haskell MOOC at https://haskell.mooc.fi/ https://haskell.mooc.fi/ at the same time. 2. Read sections in Haskell Programming from First Principles not covered in 1. 3. Read Haskell in Depth. Many years ago, I tried to learn Haskell from Haskell Programming from First Principles but couldn't get to the point I could write meaningful applications. I gave up after about a year. Early this year, I completed the Haskell MOOC and read most of Haskell in Depth and now I have a much better command of the language. And doing exercises on CodeWars, Hackerrank, and Exercism really help. I would advise ignoring both the glowing praises and scathing criticisms. Learn it well enough and form your own judgement, assuming of course that you have time to do so.