8 ms·

Why Haskell Is Interesting? (2005)

55 points by dvfjsdhgfv 4y ago

okasaki 4y ago
Those points aren't exactly true. Haskell does have for and while loops (forM, whileM), they're just a bit more hidden and cumbersome than usual. etc.
- fkarg 4y ago
  1) They're not the same kind of loops though 2) They're not primitives. It's very much possible to build for and while loops from elements in the Haskell standard library, because you have more powerful primitives to work with. Most languages have loops as primitives.
  - benreesman 4y ago
    By the time you’re handy with forM and whileM you’re past caring how they got imported! Regular tail-recursion takes some getting used to coming from an imperative background, it’s arguably the fork point on whether someone is going to stick it out.
    - xdavidliu 4y ago
      So I came to Haskell from Scheme background, so the tail recursion was actually natural to me. In fact, about a month ago I did 2016 Advent of Code in Haskell, and toward the end, I felt like I was abusing tail recursion [1] to write iterative algorithms like breadth-first-search by essentially "repeatedly consing on to the params of tails calls", as Lispers would probably call it. The whole time I'm wondering if I'm just writing Haskell "with a heavy Scheme accent", since I see others' Haskell code make extensive use of state monads (which I still haven't attempted to understand), and I also found others' using way more of the monadic / applicative operators like "bind", etc than I have. I found the hard part of Haskell not the iteration, which from tail recursion was completely natural and straightforward, but rather worrying about the efficiency of the "repeatedly consing" part. For things like stacks, the cost is O(1), but for things like Data.Array, I wasn't sure how much shared structure there was; I mean it could totally be copying the entire array every time I "mutate" an element (not really, since it was still sort of "consing" onto the old array and not actually mutating it). [1] https://github.com/xdavidliu/advent-of-code/blob/main/2016/day24.hs https://github.com/xdavidliu/advent-of-code/blob/main/2016/d...
  - deleted 4y ago
    [deleted]
als0 4y ago
I wanted to love Haskell, but I've come to realise that a language is more than just expressivity and clean abstractions. UX quality of tools, library ecosystem and general support networks are equally important. I know I could spend some spare time to improve these things, but I can't shake the feeling that since nothing seems to have significantly improved in the last twenty years, Haskell might have just missed the boat. FWIW I'm not a particular fan of Go or Rust, but I really enjoy the overall development experience of using those languages.
- _query 4y ago
  In recent years the Haskell ecosystem has drastically improved. With Haskell Language Server (HLS) there's now great autocompletion and inline error reporting for e.g. VSCode and other editors. We've recently got dot-notation, so you can type `myRecord.myField` instead of `myField myRecord`, which makes Haskell code feel more familiar when switching from other languages. With IHP we now even have a Haskell version of Rails/Laravel. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) Check it out here: https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/ (I'm founder of IHP) Serokell also has a great blog section on people using Haskell in the industry, e.g. recently there was an interview with the CTO of Mercury. https://serokell.io/blog/haskell-in-production https://serokell.io/blog/haskell-in-production
  - protomikron 4y ago
    Having autocompletion and and a convenient syntax to access record fields is standard and expected by most developers. I think if Haskell wants to convince developers to jump ship (and they don't, according to the infamous marketing slogan) there must be a bigger benefit, I don't think better record Syntax cuts it.
  - lupire 4y ago
    > In recent years the Haskell ecosystem has drastically improved. And has been doing so for 20 years. But in the meantime, the other language ecosystems improve also, and new programmer expectations pop up.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
jstx1 4y ago
Any theories on why Haskell scores so low on stackoverflow's 'most loved' metric? It's only 56.44% which means that 43.56% of the polled Haskell users don't want to use it in the future. In the same chart you see a few other not-massively-popular languages that have very dedicated user-bases of people who are really into the language (Rust, Elixir, Clojure, Julia) and they understandably score very high on this metric. Why doesn't Haskell?
- benreesman 4y ago
  It’s a monster pain in the ass to learn well enough to see the benefits. The lightbulb moment can be arbitrarily bright (and it is) but if the path to it exceeds readable maximums around pre-return investment you’re going to get modest adoption.
- ObscureScience 4y ago
  I actually think it has a lot to do with the runtime and perhaps a little with compilation time. Compared to the JVM languages I would choose Haskell any time (if given the choice), but for most native tasks the "burden" of Haskell's type system and mediocre performance makes it hard to pass the "value return" threshold compared to Go, Nim, Rust or even C++. I'm sure that Haskell's performance is plenty for most applications, and the low level/unpure escape hatches are there, but they also raise the complexity significantly from that I have seen. To me Haskell still has an aura of language research. This may be a prejudice assumption, I have not done anything more than toys with it.
  - kaba0 4y ago
    I don’t know, Haskell and Go absolutely plays in the same field regarding performance from a surface level analysis (and also in benchmarks) - both are compiled to native code with in-built GC, whose usage they can heavily cut back on compared to a traditional OOP language due to strong FP and value types, respectively. Whether it means you should lower your expectations for Go or raise them for Haskell, is up to you but Haskell can be a quite performant language for many kinds of problems - even if laziness may make performance reasoning harder.
- 4y ago
p-e-w 4y ago
I've never understood the appeal of purely functional languages like Haskell. Mutability is an essential feature of the Universe we live in. Everything changes, internally and externally, all the time. A language that treats mutability like an afterthought (or worse, like a bad thing) is necessarily going to be a poor tool for modeling the world. Multi-paradigm languages dominate practical software engineering because we live in a multi-paradigm world. High-concept approaches like purely functional and declarative systems that attempt to coerce the programmer into a specific style of problem solving cannot compete when the problem space itself is so diverse.
- mojuba 4y ago
  It is true, however a lot of what we have today in multiparadigm languages originated from niche ones like Haskell. Jazz music had a lot of influence on musicians in other genres, say Pink Floyd, but PF is not exactly jazz.
- throwaway2294af 4y ago
  I think this is the wrong approach to understand purely functional languages. They don't try to get rid of mutability / side effects, just to isolate them. See [1] where the author thinks that "In short, Haskell is the world’s ﬁnest imperative programming language". [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf?from=https%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fmarktoberdorf%2Fmark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
- cfiggers 4y ago
  > Mutability is an essential feature of the Universe we live in. Everything changes, internally and externally, all the time. That's not obviously true, actually. From a certain standpoint, the Universe IS immutable. E = mc^2 means that matter and energy are never created or destroyed, just changed from one thing to something else. So if we abstract away the nitty-gritty details of what state it's all in at any given time, the total energy content of the universe is immutable. More than that, while the passage of time creates an -illusion- of things changing from one state to another, within each instant of Planck Time nothing changes at all. And there's no conclusive evidence that the apparent CORRELATION between each state of the universe at each successive instant and the one that came before it is NECESSARILY a direct CONSEQUENCE of the previous state. More than that, consider that the past cannot be altered once it has happened. And there is no conclusive evidence that the future is fundamentally different. Furthermore, while we only have access via sense perception to the state of the universe that we call "the present", that's no guarantee that "the present" is the only state of the universe with some sort of existence to it. Maybe the past and the future exist contemporaneously with the present, forever existing as they are without alteration. In that case "Mutability" stops seeming so fundamental after all. In short, if we conceive of the universe as a data structure with infinite capacity, running on hardware with infinite resources–that is, if God wrote the universe as a purely functional program free of side-effects—them there's no compelling reason at all why that data structure must be mutable. That you assert mutability as "an essential feature of the Universe we live in" is an artifact of the style of thinking YOU are used to. It's not at all obviously fundamental. That's just the paradigm you're comfortable with. Haskell is useful, if for no other reason, as a forcing function to make you realize a totally different way of conceptually framing problems, solutions, and the universe that both exist in. In my opinion, it's worth the exercise to grow as a thinker.
dustingetz 4y ago
Haskell is the "Periodic Table of Computation". You really can't advance to "organic chem" levels of complexity without first mapping out the elements and their key properties, and then further super-specializing in the structures of Carbon. Haskell's C/H/N/O is functor/applicative/monad/arrow and these are the elements of data/interpreters/evaluators/compilers. Software engineering is still in the alchemy stage – thousands of king-funded charlatans attempting to transmute lead into gold
- galfarragem 4y ago
  Great analogy. Poetical. Actually your first version (before editing) was more poetical but I understand that many of us may be too biased to find it funny: "king-funded javascript charlatans attempting to transmute lead into gold."
  - Buttons840 4y ago
    I appreciate a good JavaScript dig every time. But in fairness, when I was trying to learn FRP (functional reactive programming, different from React), JavaScript was the only other language where I could find some interesting FRP libraries. There's definitely a lot of exciting JavaScript libraries (and more likely to have documentation than Haskell) you just won't find them used in big corporations.
    - b0afc375b5 4y ago
      I'm interested to know what JavaScript libraries you looked at, and maybe some recommendations.
      - cultofmetatron 4y ago
        rxjs and immutablejs come to mind
      - Buttons840 4y ago
        bacon.js, most, and flyd. See also: https://github.com/stoeffel/awesome-frp-js https://github.com/stoeffel/awesome-frp-js What was most helpful was the tutorials and explanations these projects had. Haskell projects, if they have documentation at all, are often written for other Haskell users, and so hard for me to understand as a novice. These JavaScript projects had a unique perspective and a unique way of explaining FRP concepts I found helpful.
asplake 4y ago
Slightly ironic that it says you don't need variables, then in the example (and without comment) simulates one
WastingMyTime89 4y ago
Haskell as a research language was very successful. It taught us a lot things: - Monads work as a way to isolate side-effects; - Lazy by default is a bad idea; - Overly academic programming languages generate toxic community.
abrax3141 4y ago
I’m a long time lisper. Learned Haskell ... a couple of times now. It’s interesting and in some cases fun and elegant. But I just kept coming back to Lisp for actual work. Lisp just seems to be at the sweet spot between functional, extensible, and work-a-day, and the parens just make the refactoring experience so fluid that it’s like a drug. (Edit: I want to learn clojure, which should be easy from Lisp. I’ve avoided it bcs the JVM makes me nauseous. But I’m told by my cj-loving ex-lisp hacker friends that you don’t need the JVM. So maybe I’ll try again.)
- massysett 4y ago
  What lisp do you use?
  - abrax3141 4y ago
    Primarily SBCL.
- dsimmons 4y ago
  Clojure is hands-down the best programming language I've used. That said, I'm still holding out hope that it'll be hosted on top of something other than the JVM -- frankly, the JVM keeps me from using it more than I otherwise would.
- epgui 4y ago
  I really love Haskell but I can’t help but think it would be a better language if it was built in s-expressions.
anta40 4y ago
I learnt a bit Haskell many years ago as undergrad student, and would like to do it again. Perhaps it's just my impression, or it's generally true that there's not much efforts popularising Haskell for system programming (OS kernel, embedded devices, microcontroller, etc)? Maybe Rust (or Zig, or whatever) is better choice for this purpose...
mattgreenrocks 4y ago
My biggest issue with Haskell is the syntax. Things like the dot operator requiring functions to be chained in reverse from every other language, the ugliness of $ vs using parens, and needing to prefix struct fields to keep them unique. It is terse and fits the language well enough but it is not beautiful. I am ambivalent about pervasive laziness, lenses, and automatic currying. I really like controlled effects and think it is one of the most powerful tools for structuring programs.
- benrbray 4y ago
  I've come to appreciate function application / composition syntax and think it allows for much more clear and readable code, compared to e.g. Scala which can be quite verbose and obscure the compositional structure of functional code. On the other hand, I agree that lack of a good solution for record syntax is a huge wart on the language that regularly gets in the way.
- lupire 4y ago
  You can use a different combinator if you don't like . What other languages have a different behavior? Pipes in shell and python work the same way.
- deleted 4y ago
  [deleted]
epgui 4y ago
The problem with most (not all) criticism of Haskell is that most of it is written by people who have not learned FP beyond using it occasionally and inconsistently within a multi-paradigm language, or who have not achieved Haskell fluency. People find Haskell challenging in novel ways, are frustrated that their java patterns aren’t working, and end up wrongly believing that Haskell is “not practical”. One must learn to conform and go along with the grain, and acquire some threshold of proficiency, before one can judge.
yodsanklai 4y ago
I'd say Haskell is much more challenging that Scheme/OCaml but it's also what makes it interesting. It's very rewarding to understand all the abstractions. I'd recommend anyone interested in programming languages to learn it seriously. Now, I wonder if it's worth using Haskell for real world projects. People have been using it for all types of things, so it's definitely possible, but the bar of entry is very high and most programmers will be more productive in different languages. Non-experts usually have a hard time maintaining existing codebases, including experienced programmers. Besides, type safety isn't unique to Haskell. There are other languages more easily approachable which provide strong guarantees as well.
kleingeld 4y ago
Haskell is one of those things that people either passionately love or hate. Because of its uncompromising philosophy, programming in Haskell (or in any other purely functional programming language for that matter) has to pay an upfront cost of structuring side-effects. Type-driven development turns out to be a very useful approach to programming for those who have acquired a sufficient degree of proficiency in typed functional programming. Granted, the world is messy and computational solutions will therefore have to deal with this messiness which often doesn't fit the neatness of purely functional programming right away. However, what I find interesting is that research into abstractions and ways to manage side-effects have led to insights and knowledge and into computing that couldn't have been readily obtained if the strait-jacket of pure functions was not put on. Such abstractions and connections with algebra of computations all help develop tools for building reliable software. IMHO, the fact that Haskell is actually used in production is somewhat an accident. I think it began with people who programmed in Haskell for fun decided to try it out on solving real-world problems. And then gradually, when monad transformers came around, using Haskell in production became a real option. I don't think the time commitment to learning Haskell is much more (if at all) than that to learn C++. In fact, after having programmed in C++ for quite a few years, I have pretty much given up on it. Obviously, if one needs to put food on the table, learning Haskell at the expense of other languages du jour would be a mistake. But being able to approach computing from the functional paradigm could be deeply rewarding.

55 points by dvfjsdhgfv 4y ago

Those points aren't exactly true. Haskell does have for and while loops (forM, whileM), they're just a bit more hidden and cumbersome than usual. etc.

fkarg 4y ago
1) They're not the same kind of loops though 2) They're not primitives. It's very much possible to build for and while loops from elements in the Haskell standard library, because you have more powerful primitives to work with. Most languages have loops as primitives.
- benreesman 4y ago
  By the time you’re handy with forM and whileM you’re past caring how they got imported! Regular tail-recursion takes some getting used to coming from an imperative background, it’s arguably the fork point on whether someone is going to stick it out.
  - xdavidliu 4y ago
    So I came to Haskell from Scheme background, so the tail recursion was actually natural to me. In fact, about a month ago I did 2016 Advent of Code in Haskell, and toward the end, I felt like I was abusing tail recursion [1] to write iterative algorithms like breadth-first-search by essentially "repeatedly consing on to the params of tails calls", as Lispers would probably call it. The whole time I'm wondering if I'm just writing Haskell "with a heavy Scheme accent", since I see others' Haskell code make extensive use of state monads (which I still haven't attempted to understand), and I also found others' using way more of the monadic / applicative operators like "bind", etc than I have. I found the hard part of Haskell not the iteration, which from tail recursion was completely natural and straightforward, but rather worrying about the efficiency of the "repeatedly consing" part. For things like stacks, the cost is O(1), but for things like Data.Array, I wasn't sure how much shared structure there was; I mean it could totally be copying the entire array every time I "mutate" an element (not really, since it was still sort of "consing" onto the old array and not actually mutating it). [1] https://github.com/xdavidliu/advent-of-code/blob/main/2016/day24.hs https://github.com/xdavidliu/advent-of-code/blob/main/2016/d...
- deleted 4y ago
  [deleted]

als0 4y ago

I wanted to love Haskell, but I've come to realise that a language is more than just expressivity and clean abstractions. UX quality of tools, library ecosystem and general support networks are equally important. I know I could spend some spare time to improve these things, but I can't shake the feeling that since nothing seems to have significantly improved in the last twenty years, Haskell might have just missed the boat. FWIW I'm not a particular fan of Go or Rust, but I really enjoy the overall development experience of using those languages.

_query 4y ago
In recent years the Haskell ecosystem has drastically improved. With Haskell Language Server (HLS) there's now great autocompletion and inline error reporting for e.g. VSCode and other editors. We've recently got dot-notation, so you can type `myRecord.myField` instead of `myField myRecord`, which makes Haskell code feel more familiar when switching from other languages. With IHP we now even have a Haskell version of Rails/Laravel. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) Check it out here: https://ihp.digitallyinduced.com/ https://ihp.digitallyinduced.com/ (I'm founder of IHP) Serokell also has a great blog section on people using Haskell in the industry, e.g. recently there was an interview with the CTO of Mercury. https://serokell.io/blog/haskell-in-production https://serokell.io/blog/haskell-in-production
- protomikron 4y ago
  Having autocompletion and and a convenient syntax to access record fields is standard and expected by most developers. I think if Haskell wants to convince developers to jump ship (and they don't, according to the infamous marketing slogan) there must be a bigger benefit, I don't think better record Syntax cuts it.
- lupire 4y ago
  > In recent years the Haskell ecosystem has drastically improved. And has been doing so for 20 years. But in the meantime, the other language ecosystems improve also, and new programmer expectations pop up.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

jstx1 4y ago

Any theories on why Haskell scores so low on stackoverflow's 'most loved' metric? It's only 56.44% which means that 43.56% of the polled Haskell users don't want to use it in the future. In the same chart you see a few other not-massively-popular languages that have very dedicated user-bases of people who are really into the language (Rust, Elixir, Clojure, Julia) and they understandably score very high on this metric. Why doesn't Haskell?

benreesman 4y ago
It’s a monster pain in the ass to learn well enough to see the benefits. The lightbulb moment can be arbitrarily bright (and it is) but if the path to it exceeds readable maximums around pre-return investment you’re going to get modest adoption.
ObscureScience 4y ago
I actually think it has a lot to do with the runtime and perhaps a little with compilation time. Compared to the JVM languages I would choose Haskell any time (if given the choice), but for most native tasks the "burden" of Haskell's type system and mediocre performance makes it hard to pass the "value return" threshold compared to Go, Nim, Rust or even C++. I'm sure that Haskell's performance is plenty for most applications, and the low level/unpure escape hatches are there, but they also raise the complexity significantly from that I have seen. To me Haskell still has an aura of language research. This may be a prejudice assumption, I have not done anything more than toys with it.
- kaba0 4y ago
  I don’t know, Haskell and Go absolutely plays in the same field regarding performance from a surface level analysis (and also in benchmarks) - both are compiled to native code with in-built GC, whose usage they can heavily cut back on compared to a traditional OOP language due to strong FP and value types, respectively. Whether it means you should lower your expectations for Go or raise them for Haskell, is up to you but Haskell can be a quite performant language for many kinds of problems - even if laziness may make performance reasoning harder.
4y ago

p-e-w 4y ago

I've never understood the appeal of purely functional languages like Haskell. Mutability is an essential feature of the Universe we live in. Everything changes, internally and externally, all the time. A language that treats mutability like an afterthought (or worse, like a bad thing) is necessarily going to be a poor tool for modeling the world. Multi-paradigm languages dominate practical software engineering because we live in a multi-paradigm world. High-concept approaches like purely functional and declarative systems that attempt to coerce the programmer into a specific style of problem solving cannot compete when the problem space itself is so diverse.

mojuba 4y ago
It is true, however a lot of what we have today in multiparadigm languages originated from niche ones like Haskell. Jazz music had a lot of influence on musicians in other genres, say Pink Floyd, but PF is not exactly jazz.
throwaway2294af 4y ago
I think this is the wrong approach to understand purely functional languages. They don't try to get rid of mutability / side effects, just to isolate them. See [1] where the author thinks that "In short, Haskell is the world’s ﬁnest imperative programming language". [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf?from=https%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Fsimonpj%2Fpapers%2Fmarktoberdorf%2Fmark.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
cfiggers 4y ago
> Mutability is an essential feature of the Universe we live in. Everything changes, internally and externally, all the time. That's not obviously true, actually. From a certain standpoint, the Universe IS immutable. E = mc^2 means that matter and energy are never created or destroyed, just changed from one thing to something else. So if we abstract away the nitty-gritty details of what state it's all in at any given time, the total energy content of the universe is immutable. More than that, while the passage of time creates an -illusion- of things changing from one state to another, within each instant of Planck Time nothing changes at all. And there's no conclusive evidence that the apparent CORRELATION between each state of the universe at each successive instant and the one that came before it is NECESSARILY a direct CONSEQUENCE of the previous state. More than that, consider that the past cannot be altered once it has happened. And there is no conclusive evidence that the future is fundamentally different. Furthermore, while we only have access via sense perception to the state of the universe that we call "the present", that's no guarantee that "the present" is the only state of the universe with some sort of existence to it. Maybe the past and the future exist contemporaneously with the present, forever existing as they are without alteration. In that case "Mutability" stops seeming so fundamental after all. In short, if we conceive of the universe as a data structure with infinite capacity, running on hardware with infinite resources–that is, if God wrote the universe as a purely functional program free of side-effects—them there's no compelling reason at all why that data structure must be mutable. That you assert mutability as "an essential feature of the Universe we live in" is an artifact of the style of thinking YOU are used to. It's not at all obviously fundamental. That's just the paradigm you're comfortable with. Haskell is useful, if for no other reason, as a forcing function to make you realize a totally different way of conceptually framing problems, solutions, and the universe that both exist in. In my opinion, it's worth the exercise to grow as a thinker.

dustingetz 4y ago

Haskell is the "Periodic Table of Computation". You really can't advance to "organic chem" levels of complexity without first mapping out the elements and their key properties, and then further super-specializing in the structures of Carbon. Haskell's C/H/N/O is functor/applicative/monad/arrow and these are the elements of data/interpreters/evaluators/compilers. Software engineering is still in the alchemy stage – thousands of king-funded charlatans attempting to transmute lead into gold

galfarragem 4y ago
Great analogy. Poetical. Actually your first version (before editing) was more poetical but I understand that many of us may be too biased to find it funny: "king-funded javascript charlatans attempting to transmute lead into gold."
- Buttons840 4y ago
  I appreciate a good JavaScript dig every time. But in fairness, when I was trying to learn FRP (functional reactive programming, different from React), JavaScript was the only other language where I could find some interesting FRP libraries. There's definitely a lot of exciting JavaScript libraries (and more likely to have documentation than Haskell) you just won't find them used in big corporations.
  - b0afc375b5 4y ago
    I'm interested to know what JavaScript libraries you looked at, and maybe some recommendations.
    - cultofmetatron 4y ago
      rxjs and immutablejs come to mind
    - Buttons840 4y ago
      bacon.js, most, and flyd. See also: https://github.com/stoeffel/awesome-frp-js https://github.com/stoeffel/awesome-frp-js What was most helpful was the tutorials and explanations these projects had. Haskell projects, if they have documentation at all, are often written for other Haskell users, and so hard for me to understand as a novice. These JavaScript projects had a unique perspective and a unique way of explaining FRP concepts I found helpful.

asplake 4y ago

Slightly ironic that it says you don't need variables, then in the example (and without comment) simulates one

WastingMyTime89 4y ago

Haskell as a research language was very successful. It taught us a lot things: - Monads work as a way to isolate side-effects; - Lazy by default is a bad idea; - Overly academic programming languages generate toxic community.

abrax3141 4y ago

I’m a long time lisper. Learned Haskell ... a couple of times now. It’s interesting and in some cases fun and elegant. But I just kept coming back to Lisp for actual work. Lisp just seems to be at the sweet spot between functional, extensible, and work-a-day, and the parens just make the refactoring experience so fluid that it’s like a drug. (Edit: I want to learn clojure, which should be easy from Lisp. I’ve avoided it bcs the JVM makes me nauseous. But I’m told by my cj-loving ex-lisp hacker friends that you don’t need the JVM. So maybe I’ll try again.)

massysett 4y ago
What lisp do you use?
- abrax3141 4y ago
  Primarily SBCL.
dsimmons 4y ago
Clojure is hands-down the best programming language I've used. That said, I'm still holding out hope that it'll be hosted on top of something other than the JVM -- frankly, the JVM keeps me from using it more than I otherwise would.
epgui 4y ago
I really love Haskell but I can’t help but think it would be a better language if it was built in s-expressions.

anta40 4y ago

I learnt a bit Haskell many years ago as undergrad student, and would like to do it again. Perhaps it's just my impression, or it's generally true that there's not much efforts popularising Haskell for system programming (OS kernel, embedded devices, microcontroller, etc)? Maybe Rust (or Zig, or whatever) is better choice for this purpose...

mattgreenrocks 4y ago

My biggest issue with Haskell is the syntax. Things like the dot operator requiring functions to be chained in reverse from every other language, the ugliness of $ vs using parens, and needing to prefix struct fields to keep them unique. It is terse and fits the language well enough but it is not beautiful. I am ambivalent about pervasive laziness, lenses, and automatic currying. I really like controlled effects and think it is one of the most powerful tools for structuring programs.

benrbray 4y ago
I've come to appreciate function application / composition syntax and think it allows for much more clear and readable code, compared to e.g. Scala which can be quite verbose and obscure the compositional structure of functional code. On the other hand, I agree that lack of a good solution for record syntax is a huge wart on the language that regularly gets in the way.
lupire 4y ago
You can use a different combinator if you don't like . What other languages have a different behavior? Pipes in shell and python work the same way.
deleted 4y ago
[deleted]

epgui 4y ago

The problem with most (not all) criticism of Haskell is that most of it is written by people who have not learned FP beyond using it occasionally and inconsistently within a multi-paradigm language, or who have not achieved Haskell fluency. People find Haskell challenging in novel ways, are frustrated that their java patterns aren’t working, and end up wrongly believing that Haskell is “not practical”. One must learn to conform and go along with the grain, and acquire some threshold of proficiency, before one can judge.

yodsanklai 4y ago

I'd say Haskell is much more challenging that Scheme/OCaml but it's also what makes it interesting. It's very rewarding to understand all the abstractions. I'd recommend anyone interested in programming languages to learn it seriously. Now, I wonder if it's worth using Haskell for real world projects. People have been using it for all types of things, so it's definitely possible, but the bar of entry is very high and most programmers will be more productive in different languages. Non-experts usually have a hard time maintaining existing codebases, including experienced programmers. Besides, type safety isn't unique to Haskell. There are other languages more easily approachable which provide strong guarantees as well.

kleingeld 4y ago

Haskell is one of those things that people either passionately love or hate. Because of its uncompromising philosophy, programming in Haskell (or in any other purely functional programming language for that matter) has to pay an upfront cost of structuring side-effects. Type-driven development turns out to be a very useful approach to programming for those who have acquired a sufficient degree of proficiency in typed functional programming. Granted, the world is messy and computational solutions will therefore have to deal with this messiness which often doesn't fit the neatness of purely functional programming right away. However, what I find interesting is that research into abstractions and ways to manage side-effects have led to insights and knowledge and into computing that couldn't have been readily obtained if the strait-jacket of pure functions was not put on. Such abstractions and connections with algebra of computations all help develop tools for building reliable software. IMHO, the fact that Haskell is actually used in production is somewhat an accident. I think it began with people who programmed in Haskell for fun decided to try it out on solving real-world problems. And then gradually, when monad transformers came around, using Haskell in production became a real option. I don't think the time commitment to learning Haskell is much more (if at all) than that to learn C++. In fact, after having programmed in C++ for quite a few years, I have pretty much given up on it. Obviously, if one needs to put food on the table, learning Haskell at the expense of other languages du jour would be a mistake. But being able to approach computing from the functional paradigm could be deeply rewarding.