8 ms·

Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. The stateless nature of Haskell is someth

by cpa 2y ago

Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. The stateless nature of Haskell is something that many rediscover at different points in their careers. Eg in webdev, it's mostly about offloading state to the database and treating the application as "dumb nodes." That's what most K8s deployments do. The type system in Haskell, particularly union types, is incredibly powerful, easy to understand for the most part (you don't need to understand monads that deeply to use them), and highly useful. And I've had a lot of fun micro-optimizing Haskell code for Project Euler problems when I was studying. Give it a try. Especially, if you don't know what to expect, I can guarantee that you'll be surprised! Granted, the tooling is sh*t.

adastra22 2y ago
Haskell also changed the way I think about programming. But I wonder if it would have as much of an impact on someone coming from a language like Rust or even modern C++ which has adopted many of haskell’s features?
- mmoll 2y ago
  True. I often think of Rust as a best-of compilation of Haskell and C++ (although I read somewhere that OCaml had a greater influence on it, but I don’t know that language well enough) In real life, I find that Haskell suffers from trying too hard to use the most general concept that‘s applicable (no pun intended). Haskell programs happily use “Either Err Val” and “Left x” where other languages would use the more expressive but less general “Result Err Val” and “Error x”. Also, I don’t want to mentally parse nested liftM2s or learn the 5th effect system ;-)
  - hollerith 2y ago
    >I read somewhere that OCaml had a greater influence on it Whoever wrote that is wrong.
    - deleted 2y ago
      [deleted]
    - randomdata 2y ago
      If we could wave a magic wand and remove Haskell's influence on Rust, Rust would still exist in some kind of partial form. If we waved the same wand and removed OCaml's influence, Rust would no longer exist at all. You are the one who is wrong, I'm afraid.
      - lkitching 2y ago
        Which OCaml features exist in Rust but not Haskell? The trait system looks very similar to Haskell typeclasses, but I'm not aware of any novel OCaml influence on the language.
        randomdata 2y ago
        > Which OCaml features exist in Rust but not Haskell? Rust's most important feature! The bootstrapped implementation.
        lkitching 2y ago
        I'm not convinced the implementation language of the compiler counts as a feature of the Rust language. If the argument is that Rust wouldn't have been invented without the original author wanting a 'systems OCaml' then fine. But it's possible Rust would still look similar to how it does now in a counterfactual world where the original inspiration was Haskell rather than OCaml, but removing the Haskell influence from Rust as it is now would result in something quite different.
        randomdata 2y ago
        Rust isn't just a language, though. Additionally, unlike some languages that are formally specified before turning to implementation, Rust has subscribed to design-by-implementation. The implementation is the language.
- setopt 2y ago
  I think it does, actually. Python also has many of Haskell's features (list comprehensions, map/filter/reduce, itertools, functools, etc.). But I only started reaching for those features after learning about them in Haskell. In Python, it's very easy to just write out a for-loops to do these things, and you don't necessarily go looking for alternative ways to do these things unless you know the functional equivalents already. But in Haskell you're forced to do things this way since there is no for-loop available. But after learning that way of thinking, the result is then more compact code with arguably less risk of bugs.
  - z500 2y ago
    If anything, Python encourages you to use loops because the backwards arrangement of the arguments to map and filter makes it painful to chain them.
    - sgarland 2y ago
      map(function, iterable) That seems very logical to me, but then, I’m not a functional programmer, I just like map. It’s elegant, compact, and isn’t hard to understand. Not that list comps are hard to understand either, but they can sometimes get overly verbose. filter has also lost ground in favor of list comps, partially because Guido hates FP [0], and probably due to that, there has been a lot of effort towards optimizing list comps over the years, and they’re now generally faster than filter (or map, sometimes). [0]: https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196
      - BeetleB 2y ago
        Yes, but how do you chain them? map(func4, map(func3, map(func2, map(func1, iter)))) vs iter.map(f1).map(f2).map(f3).map(f4) I made up the syntax for the last one, but most functional languages have a nice syntax for it. Here's F#: iter |> f1 |> f2 |> f3 |> f4 Or plain shell: command | f1 | f2 | f3 | f4
        2y ago
- odyssey7 2y ago
  Check out Swift, too!
  - adastra22 2y ago
    Why would I use swift when more cross-platform solutions exist?
- TylerE 2y ago
  Heck, even coming from Python (2) it felt very underwhelming and hugely oversold. (Edit: To be fair, I'd done a bit of Ocaml years earlier so algebraic data types weren't some huge revelation). Laziness is mostly an anti-pattern.
- deleted 2y ago
  [deleted]
gtf21 2y ago
> Granted, the tooling is sh*t. I hear this a lot, but am curious about two things: (a) which bit(s) of the toolchain are you thinking about specifically -- I know HLS can be quite janky but I haven't really been blocked by any tooling problems myself; (b) have you done much Haskell in production recently -- i.e. is this scar tissue from some ago or have you tried the toolchain recently and still found it to be lacking?
- n_plus_1_acc 2y ago
  Everytime I use cabal and/or stack, it gives me a wall of errors and i just reinstall everyrhing all the time.
  - tome 2y ago
    If you share a transcript from a cabal session I'll look into this for you.
  - simonmic 2y ago
    And if you share stack transcripts I’ll look into those for you. I’ve experienced this too, the tools can certainly be improved, but also a little more understanding of what they do and how to interpret their error messages could help you (I am guessing).
moomin 2y ago
Sum types are finally coming to C#. That’ll make it the first “Mainstream” language to adopt them. Will it be as solid and simple as Haskell’s implementation? Of course not. Will having a backing ecosystem make up for that deficiency? Yes.
- n_plus_1_acc 2y ago
  Rust is mainstream, just not use in enterprise applications
  - gamegoblin 2y ago
    AWS uses Rust extensively
- SkiFire13 2y ago
  What counts as mainstream for you? Java has recently added sealed classes/interfaces which offer the same features as sum types, and I would argue that Java is definitely mainstream. Kotlin has a similar feature. It might be used less than Java, but it's the default language for Android. Swift has `enum` for sum types and is the default language for iOS and MacOS. Likewise for Rust, which is gaining traction recently. Typescript also has union/sum types and is gaining lot of traction.
  - zozbot234 2y ago
    For that matter, PASCAL has had variant records (i.e. sum types) since the 1970s.
    - iso8859-1 2y ago
      Did it have an ergonomic way to exhaustively match on all the variants? Since the 70s? How does the ABI work? If a library adds a new constructor, but I am still linking against the old version, I imagine that it could be reading the wrong fields, since the constructor it's reading is now at a different index?
  - 2y ago
setopt 2y ago
> Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. > And I've had a lot of fun micro-optimizing Haskell code for Project Euler problems when I was studying. Sounds a lot like my experience. I never really used Haskell for "real work", where I need support for high-performance numerical calculations that is simply better in other languages (Python, Julia, C/C++, Fortran). But learning functional programming through Haskell – mostly by following the "Learn you a Haskell" book and then spending time working through Project Euler exercises using it – had a quite formative effect on how I write code. I even ended up baking some functional programming concepts into my Fortran code later. For instance, I implemented the ability to "map" functions on my data structures, and made heavy use of "pure functions" which are supported by the modern Fortran standard (the compiler then checks for side effects). It's however hard to go all the way on functional programming in HPC contexts, although I wish there were better libraries available to enable this.
- nextos 2y ago
  > But learning functional programming through Haskell [...] had a quite formative effect on how I write code. I think it is a shame Haskell has gained a reputation of being hard, because it can be an enriching learning experience. Lots of its complexity is accidental, and comes from the myriad of language extensions that have been created for research purposes. There was an initiative to define a simpler subset of the language, which IMHO would have been great, but it didn't take off: https://www.simplehaskell.org https://www.simplehaskell.org. Ultimately, one can stick to Haskell 98 or Haskell 2010 plus some newer cherry-picked extensions.
  - gtirloni 2y ago
    Sounds a lot like the C++ experience. In my time learning Haskell a decade ago, it was rare to find some code that wasn't using an experimental extension.
  - bbkane 2y ago
    I think Elm is a fantastic "simplified Haskell" with pretty good beginner-friendly guides. It's unfortunate that Elm is mostly tied to the frontend and has been effectively abandoned for the last couple of years. Interestingly, Elm has inspired a host of "successors", including Gleam + Lustre, which look really great (I haven't had a chance to really try them yet).
jillesvangurp 2y ago
I think the tooling being not ideal is a reflection of how mature/serious the community is about non academic usage. Haskell has been around for ages but it never really escaped its academic nature. I actually studied in Utrecht in the nineties where there was a lot of activity around this topic at the time. Eric Meyer who later created F# at MS was a teacher there and there was a lot of activity around doing stuff with Gopher which is a Haskell predecessor, which I learned and used at the time. All our compiler courses were basically fiddling with compiler generator frameworks that came straight out of the graduate program. Awesome research group at the time. My take on this is that this was all nice and interesting but a lot of this stuff was a bit academic. F# is probably the closest the community got to having a mature tooling and developer ecosystem. I don't use Haskell myself and have no strong opinions on the topic. But usually a good community response to challenges like this is somebody stepping up and doing something about it. That starts with caring enough. If nobody cares, nothing happens. Smalltalk kicked off a small tool revolution in the nineties with its refactoring browser. Smalltalk was famous for having its own IDE. That was no accident. Alan Kay, who was at Xerox PARC famously said that the best way to predict the future was to invent it. And of course he was (and is) very active in the Smalltalk community and its early development. Smalltalk was a language community that was from day one focused on having great tools. Lots of good stuff came out of that community at IBM (Visual Age, Eclipse) and later Jetbrains and other IDE makers. Rust is a good recent example of a community that's very passionate about having good tools as well. Down to the firmware and operating system and everything up. In terms of IDE support they could do better perhaps. But I think there are ongoing efforts on making the compiler more suitable for IDE features (which overlap with compiler features). And of course Cargo has a good reputation. That's a community that cares. I use Kotlin myself. Made by Jetbrains and heavily used in their IDEs and toolchains. It shows. This is a language made by tool specialists. Which is why I love it. Not necessarily for functional purists. Even though som Scala users have reluctantly switched to it. And the rest is flirting with things like Haskel and Elixir.
- odyssey7 2y ago
  “Greece, Rome’s captive, took Rome captive.” The languages of engineering-aligned communities may appear to have won the race, though they have been adopting significant ideas from Haskell and related languages in their victories.
cies 2y ago
> Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. Exactly the same for me. > Granted, the tooling is sh*t. Stack and Stackage (one of the package managers and library distribution systems in Haskell-land) is the best I found in any language. Other than that I also found some tools to be lacking.
- dario_od 2y ago
  What makes you say that stack is the best you found in any language? I use it daily, and in my experience I'd put it just a bit above PHP's composer
  - deleted 2y ago
    [deleted]
  - cies 2y ago
    In other package manager there is no guarantee that the libs work together. Stackage test the whole ecosystem. You use Stackage X.Y (not libA X.Y + libB X.Y, etc). All other ecosystems there are some libs that do not work together well, and usually you find out the hard way.
0x3444ac53 2y ago
Would you mind explaining what you mean by stateless?
- jgwil2 2y ago
  Haskell functions are pure, like mathematical functions: the same input to a function produces the same output every time, regardless of the state of the application. That means the function cannot read or write any data that is not passed directly to it as an argument. So the program is "stateless" in that the behavior does not depend on anything other than its inputs. This is valuable because you as the developer have a lot less stuff to think about when you're trying to reason about your program's behavior.
  - mrkeen 2y ago
    >>> The stateless nature of Haskell is something that many rediscover at different points in their careers. Eg in webdev, it's mostly about offloading state to the database >> Would you mind explaining what you mean by stateless? > the same input to a function produces the same output every time It's good that the question about 'stateless' was raised, but because these are two different things. Working with pure functions does indeed have the above benefits, but a dumb web node deferring its behaviour to a stateful database is not stateless in that sense, and so does not have the above benefits.
    - jgwil2 2y ago
      Maybe I've misunderstood what OP was getting at--can you elaborate on the distinction between these two meanings of statelessness?
      - mrkeen 2y ago
        In a stateless service in the OO sense, it is perfectly fine to GET something, and then GET something different the next time you run the same request. (Probably because someone POSTed between your two GETs.) Because of mutable state. FP statelessness means no mutable state, so two identical GETs will of course return the same result.
BoiledCabbage 2y ago
> Give it a try. Especially, if you don't know what to expect, I can guarantee that you'll be surprised! And I will as strongly as possible emphasize the opposite you should not. If you are are already experienced in functional programming, as well as in statically typed functional programming or something lovely in the ML family of languages then only then does Haskell make sense to learn. If you are looking to learn about either FP in general, or staticly typed FP Haskell is about the single worst language anyone can start with. More people have been discouraged from using FP because they started with Haskell than is probably appreciated. The effort to insight ratio for Haskell is incredibly high. You can learn the majority of the concepts faster in another language with likely 1/10th the effort. For general FP learn clojure, Racket, or another scheme. For statically typed FP learn F# or Scala or OCAML or even Elm. In fact if you really want to learn Haskell is is faster to learn Elm and then Haskell than it is to just learn Haskel. Because the amout or weeds you have to navigate through to get to the concepts in Haskell are so high that you can first learn the concepts and approach in a tiny language like Elm and it will more than save the amount of time it would take to understand those approaches from trying to learn Haskell. It seems unbelievable but ai found it to be very try. You can learn two languages faster than just one because of how muddy Haskell is. Now that said FP is valuable and in my opinion a cleaner design and why in general our industry keeps shifting that way. Monoids, Functors, Applicative are nice design patterns. Pushing side effects to the edge of your code (which is enforced by types) is a great practice. Monads are way overhyped, thinking in types is way undervalued. But you can get all of these concepts without learning Haskell. So that's the end of my rant as I've grown tired of watching people dismiss FP because they confuse the great concepts of FP with the horrible warts that come with Haskell. Haskell is a great language, and I'm glad I learned it (and am in no way an expert at it)- but it is the single worst language for an introduction to FP concepts. If you're already deep in FP it's and awesome addition to your toolbox of concepts and for that specific purpose I highly recommend it. And finally, LYAH is a terrible resource.
- the_af 2y ago
  > And finally, LYAH is a terrible resource. Could you elaborate? I know LYAH doesn't teach enough to write real programs, and does not introduce necessary concepts such as monad transformers, but why is it so terrible as an introduction to Haskell and FP? (In my mind, incomplete/flawed != terrible... Terrible means "avoid at all costs"). As for your overall point, I remember articles posted here on HN about someone teaching Haskell to children (no prior exposure to any other prog lang) with great success.
deleted 2y ago
[deleted]

by cpa 2y ago

adastra22 2y ago

Haskell also changed the way I think about programming. But I wonder if it would have as much of an impact on someone coming from a language like Rust or even modern C++ which has adopted many of haskell’s features?

mmoll 2y ago
True. I often think of Rust as a best-of compilation of Haskell and C++ (although I read somewhere that OCaml had a greater influence on it, but I don’t know that language well enough) In real life, I find that Haskell suffers from trying too hard to use the most general concept that‘s applicable (no pun intended). Haskell programs happily use “Either Err Val” and “Left x” where other languages would use the more expressive but less general “Result Err Val” and “Error x”. Also, I don’t want to mentally parse nested liftM2s or learn the 5th effect system ;-)
- hollerith 2y ago
  >I read somewhere that OCaml had a greater influence on it Whoever wrote that is wrong.
  - deleted 2y ago
    [deleted]
  - randomdata 2y ago
    If we could wave a magic wand and remove Haskell's influence on Rust, Rust would still exist in some kind of partial form. If we waved the same wand and removed OCaml's influence, Rust would no longer exist at all. You are the one who is wrong, I'm afraid.
    - lkitching 2y ago
      Which OCaml features exist in Rust but not Haskell? The trait system looks very similar to Haskell typeclasses, but I'm not aware of any novel OCaml influence on the language.
      - randomdata 2y ago
        > Which OCaml features exist in Rust but not Haskell? Rust's most important feature! The bootstrapped implementation.
        lkitching 2y ago
        I'm not convinced the implementation language of the compiler counts as a feature of the Rust language. If the argument is that Rust wouldn't have been invented without the original author wanting a 'systems OCaml' then fine. But it's possible Rust would still look similar to how it does now in a counterfactual world where the original inspiration was Haskell rather than OCaml, but removing the Haskell influence from Rust as it is now would result in something quite different.
        randomdata 2y ago
        Rust isn't just a language, though. Additionally, unlike some languages that are formally specified before turning to implementation, Rust has subscribed to design-by-implementation. The implementation is the language.
setopt 2y ago
I think it does, actually. Python also has many of Haskell's features (list comprehensions, map/filter/reduce, itertools, functools, etc.). But I only started reaching for those features after learning about them in Haskell. In Python, it's very easy to just write out a for-loops to do these things, and you don't necessarily go looking for alternative ways to do these things unless you know the functional equivalents already. But in Haskell you're forced to do things this way since there is no for-loop available. But after learning that way of thinking, the result is then more compact code with arguably less risk of bugs.
- z500 2y ago
  If anything, Python encourages you to use loops because the backwards arrangement of the arguments to map and filter makes it painful to chain them.
  - sgarland 2y ago
    map(function, iterable) That seems very logical to me, but then, I’m not a functional programmer, I just like map. It’s elegant, compact, and isn’t hard to understand. Not that list comps are hard to understand either, but they can sometimes get overly verbose. filter has also lost ground in favor of list comps, partially because Guido hates FP [0], and probably due to that, there has been a lot of effort towards optimizing list comps over the years, and they’re now generally faster than filter (or map, sometimes). [0]: https://www.artima.com/weblogs/viewpost.jsp?thread=98196 https://www.artima.com/weblogs/viewpost.jsp?thread=98196
    - BeetleB 2y ago
      Yes, but how do you chain them? map(func4, map(func3, map(func2, map(func1, iter)))) vs iter.map(f1).map(f2).map(f3).map(f4) I made up the syntax for the last one, but most functional languages have a nice syntax for it. Here's F#: iter |> f1 |> f2 |> f3 |> f4 Or plain shell: command | f1 | f2 | f3 | f4
      - 2y ago
odyssey7 2y ago
Check out Swift, too!
- adastra22 2y ago
  Why would I use swift when more cross-platform solutions exist?
TylerE 2y ago
Heck, even coming from Python (2) it felt very underwhelming and hugely oversold. (Edit: To be fair, I'd done a bit of Ocaml years earlier so algebraic data types weren't some huge revelation). Laziness is mostly an anti-pattern.
deleted 2y ago
[deleted]

gtf21 2y ago

> Granted, the tooling is sh*t. I hear this a lot, but am curious about two things: (a) which bit(s) of the toolchain are you thinking about specifically -- I know HLS can be quite janky but I haven't really been blocked by any tooling problems myself; (b) have you done much Haskell in production recently -- i.e. is this scar tissue from some ago or have you tried the toolchain recently and still found it to be lacking?

n_plus_1_acc 2y ago
Everytime I use cabal and/or stack, it gives me a wall of errors and i just reinstall everyrhing all the time.
- tome 2y ago
  If you share a transcript from a cabal session I'll look into this for you.
- simonmic 2y ago
  And if you share stack transcripts I’ll look into those for you. I’ve experienced this too, the tools can certainly be improved, but also a little more understanding of what they do and how to interpret their error messages could help you (I am guessing).

moomin 2y ago

Sum types are finally coming to C#. That’ll make it the first “Mainstream” language to adopt them. Will it be as solid and simple as Haskell’s implementation? Of course not. Will having a backing ecosystem make up for that deficiency? Yes.

n_plus_1_acc 2y ago
Rust is mainstream, just not use in enterprise applications
- gamegoblin 2y ago
  AWS uses Rust extensively
SkiFire13 2y ago
What counts as mainstream for you? Java has recently added sealed classes/interfaces which offer the same features as sum types, and I would argue that Java is definitely mainstream. Kotlin has a similar feature. It might be used less than Java, but it's the default language for Android. Swift has `enum` for sum types and is the default language for iOS and MacOS. Likewise for Rust, which is gaining traction recently. Typescript also has union/sum types and is gaining lot of traction.
- zozbot234 2y ago
  For that matter, PASCAL has had variant records (i.e. sum types) since the 1970s.
  - iso8859-1 2y ago
    Did it have an ergonomic way to exhaustively match on all the variants? Since the 70s? How does the ABI work? If a library adds a new constructor, but I am still linking against the old version, I imagine that it could be reading the wrong fields, since the constructor it's reading is now at a different index?
- 2y ago

setopt 2y ago

> Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. > And I've had a lot of fun micro-optimizing Haskell code for Project Euler problems when I was studying. Sounds a lot like my experience. I never really used Haskell for "real work", where I need support for high-performance numerical calculations that is simply better in other languages (Python, Julia, C/C++, Fortran). But learning functional programming through Haskell – mostly by following the "Learn you a Haskell" book and then spending time working through Project Euler exercises using it – had a quite formative effect on how I write code. I even ended up baking some functional programming concepts into my Fortran code later. For instance, I implemented the ability to "map" functions on my data structures, and made heavy use of "pure functions" which are supported by the modern Fortran standard (the compiler then checks for side effects). It's however hard to go all the way on functional programming in HPC contexts, although I wish there were better libraries available to enable this.

nextos 2y ago
> But learning functional programming through Haskell [...] had a quite formative effect on how I write code. I think it is a shame Haskell has gained a reputation of being hard, because it can be an enriching learning experience. Lots of its complexity is accidental, and comes from the myriad of language extensions that have been created for research purposes. There was an initiative to define a simpler subset of the language, which IMHO would have been great, but it didn't take off: https://www.simplehaskell.org https://www.simplehaskell.org. Ultimately, one can stick to Haskell 98 or Haskell 2010 plus some newer cherry-picked extensions.
- gtirloni 2y ago
  Sounds a lot like the C++ experience. In my time learning Haskell a decade ago, it was rare to find some code that wasn't using an experimental extension.
- bbkane 2y ago
  I think Elm is a fantastic "simplified Haskell" with pretty good beginner-friendly guides. It's unfortunate that Elm is mostly tied to the frontend and has been effectively abandoned for the last couple of years. Interestingly, Elm has inspired a host of "successors", including Gleam + Lustre, which look really great (I haven't had a chance to really try them yet).

jillesvangurp 2y ago

I think the tooling being not ideal is a reflection of how mature/serious the community is about non academic usage. Haskell has been around for ages but it never really escaped its academic nature. I actually studied in Utrecht in the nineties where there was a lot of activity around this topic at the time. Eric Meyer who later created F# at MS was a teacher there and there was a lot of activity around doing stuff with Gopher which is a Haskell predecessor, which I learned and used at the time. All our compiler courses were basically fiddling with compiler generator frameworks that came straight out of the graduate program. Awesome research group at the time. My take on this is that this was all nice and interesting but a lot of this stuff was a bit academic. F# is probably the closest the community got to having a mature tooling and developer ecosystem. I don't use Haskell myself and have no strong opinions on the topic. But usually a good community response to challenges like this is somebody stepping up and doing something about it. That starts with caring enough. If nobody cares, nothing happens. Smalltalk kicked off a small tool revolution in the nineties with its refactoring browser. Smalltalk was famous for having its own IDE. That was no accident. Alan Kay, who was at Xerox PARC famously said that the best way to predict the future was to invent it. And of course he was (and is) very active in the Smalltalk community and its early development. Smalltalk was a language community that was from day one focused on having great tools. Lots of good stuff came out of that community at IBM (Visual Age, Eclipse) and later Jetbrains and other IDE makers. Rust is a good recent example of a community that's very passionate about having good tools as well. Down to the firmware and operating system and everything up. In terms of IDE support they could do better perhaps. But I think there are ongoing efforts on making the compiler more suitable for IDE features (which overlap with compiler features). And of course Cargo has a good reputation. That's a community that cares. I use Kotlin myself. Made by Jetbrains and heavily used in their IDEs and toolchains. It shows. This is a language made by tool specialists. Which is why I love it. Not necessarily for functional purists. Even though som Scala users have reluctantly switched to it. And the rest is flirting with things like Haskel and Elixir.

odyssey7 2y ago
“Greece, Rome’s captive, took Rome captive.” The languages of engineering-aligned communities may appear to have won the race, though they have been adopting significant ideas from Haskell and related languages in their victories.

cies 2y ago

> Haskell has had a profound impact on the way I think about programming and how I architect my code and build services. Exactly the same for me. > Granted, the tooling is sh*t. Stack and Stackage (one of the package managers and library distribution systems in Haskell-land) is the best I found in any language. Other than that I also found some tools to be lacking.

dario_od 2y ago
What makes you say that stack is the best you found in any language? I use it daily, and in my experience I'd put it just a bit above PHP's composer
- deleted 2y ago
  [deleted]
- cies 2y ago
  In other package manager there is no guarantee that the libs work together. Stackage test the whole ecosystem. You use Stackage X.Y (not libA X.Y + libB X.Y, etc). All other ecosystems there are some libs that do not work together well, and usually you find out the hard way.

0x3444ac53 2y ago

Would you mind explaining what you mean by stateless?

jgwil2 2y ago
Haskell functions are pure, like mathematical functions: the same input to a function produces the same output every time, regardless of the state of the application. That means the function cannot read or write any data that is not passed directly to it as an argument. So the program is "stateless" in that the behavior does not depend on anything other than its inputs. This is valuable because you as the developer have a lot less stuff to think about when you're trying to reason about your program's behavior.
- mrkeen 2y ago
  >>> The stateless nature of Haskell is something that many rediscover at different points in their careers. Eg in webdev, it's mostly about offloading state to the database >> Would you mind explaining what you mean by stateless? > the same input to a function produces the same output every time It's good that the question about 'stateless' was raised, but because these are two different things. Working with pure functions does indeed have the above benefits, but a dumb web node deferring its behaviour to a stateful database is not stateless in that sense, and so does not have the above benefits.
  - jgwil2 2y ago
    Maybe I've misunderstood what OP was getting at--can you elaborate on the distinction between these two meanings of statelessness?
    - mrkeen 2y ago
      In a stateless service in the OO sense, it is perfectly fine to GET something, and then GET something different the next time you run the same request. (Probably because someone POSTed between your two GETs.) Because of mutable state. FP statelessness means no mutable state, so two identical GETs will of course return the same result.

BoiledCabbage 2y ago

> Give it a try. Especially, if you don't know what to expect, I can guarantee that you'll be surprised! And I will as strongly as possible emphasize the opposite you should not. If you are are already experienced in functional programming, as well as in statically typed functional programming or something lovely in the ML family of languages then only then does Haskell make sense to learn. If you are looking to learn about either FP in general, or staticly typed FP Haskell is about the single worst language anyone can start with. More people have been discouraged from using FP because they started with Haskell than is probably appreciated. The effort to insight ratio for Haskell is incredibly high. You can learn the majority of the concepts faster in another language with likely 1/10th the effort. For general FP learn clojure, Racket, or another scheme. For statically typed FP learn F# or Scala or OCAML or even Elm. In fact if you really want to learn Haskell is is faster to learn Elm and then Haskell than it is to just learn Haskel. Because the amout or weeds you have to navigate through to get to the concepts in Haskell are so high that you can first learn the concepts and approach in a tiny language like Elm and it will more than save the amount of time it would take to understand those approaches from trying to learn Haskell. It seems unbelievable but ai found it to be very try. You can learn two languages faster than just one because of how muddy Haskell is. Now that said FP is valuable and in my opinion a cleaner design and why in general our industry keeps shifting that way. Monoids, Functors, Applicative are nice design patterns. Pushing side effects to the edge of your code (which is enforced by types) is a great practice. Monads are way overhyped, thinking in types is way undervalued. But you can get all of these concepts without learning Haskell. So that's the end of my rant as I've grown tired of watching people dismiss FP because they confuse the great concepts of FP with the horrible warts that come with Haskell. Haskell is a great language, and I'm glad I learned it (and am in no way an expert at it)- but it is the single worst language for an introduction to FP concepts. If you're already deep in FP it's and awesome addition to your toolbox of concepts and for that specific purpose I highly recommend it. And finally, LYAH is a terrible resource.

the_af 2y ago
> And finally, LYAH is a terrible resource. Could you elaborate? I know LYAH doesn't teach enough to write real programs, and does not introduce necessary concepts such as monad transformers, but why is it so terrible as an introduction to Haskell and FP? (In my mind, incomplete/flawed != terrible... Terrible means "avoid at all costs"). As for your overall point, I remember articles posted here on HN about someone teaching Haskell to children (no prior exposure to any other prog lang) with great success.

deleted 2y ago

[deleted]