11 ms·

Is this argument here just that it's memory safe and has static typing? What am I missing? I think any advocate for Haskell has to justify, at minimum, why it

Is this argument here just that it's memory safe and has static typing? What am I missing? I think any advocate for Haskell has to justify, at minimum, why it should be preferred to all of Rust/Go/Java/Python for a given use case. These all have way better tooling, developer ergonomics, and library support. (I don't really like Haskell and think it gets a disproportionate amount of buzz here – but I think most Haskell devs would agree with that last sentence. See all the complaints about stack and cabal on reddit, for example.)

jmfldn 5y ago
Agree on tooling and library support. Not sure what developer ergonomics are? Ease of writing code, expressiveness? That's entirely subjective I would say. My subjective take is that, once you know a language like Haskell, it's hyper-productive and simple to express things that would be much harder and error prone in, say, an imperative language. Tradeoff is that it takes a while to get to this point. There is a steep learning curve. It's an amazing tool in the right hands / for the right problems. Tooling etc is such a pain point though.
- spekcular 5y ago
  "Ergonomics" is super vague, so let me give one concrete example. From reddit [0]: "I'm running Ubuntu so I installed ghc and cabal-install, then installed stack (since people are recommending that) by running their script. Then I found out that haskell-platform is the blessed route (and contains stack) so I uninstalled ghc, cabal, stack and installed that instead. Stack was not installed along with haskell-platform (what? why? ugh... whatever), so I reinstalled it manually. Great, now I have the tooling all set up! Slightly more irritating than other languages, but it's there. Now to build my app; I want to give websockets a whirl so I grabbed the server example and stuck it in a newly created stack project (stack new foo worked well) as app/Main.lhs and re-pointed foo.cabal to look at the .lhs extension. Ok, next step is to build it, stack build - it complains that I don't have websockets installed, ok, stack install websockets - it whirrs away for a while downloading stuff and then finishes. That was easy. stack build - same error, still no websockets (???). I take a look through the stack.yml and foo.cabal files and can't find websockets mentioned anywhere (in NodeJS I'd have done npm install --save websockets and it would have both installed the lib local to the project and updated the packages.json file appropriately - same sort of thing with Python via pip + freeze). Presumably I missed the '--save' or equivalent, but I don't see anything like this in the stack install -h docs. I hop onto irc for help, and am informed that you don't stack install project dependencies; that installs global packages (huh? I thought stack was supposed to help in keeping things local... whatever). Then I find that I have to edit the foo.cabal file manually to add my deps - seriously? Wow. Ok... So I do that (in the wrong place, then eventually in the right place) and finally my stack build works. Awesome! But also grrrr! Why are there two config files talking about libs and how am I supposed to know which one I'm meant to add stuff to? As an aside there's also the expectation that I should figure out which versions of libs are snapshotted on stackage, but searching on the website funnels me through to hackage (via hoogle) and gives me no indication on the way as to what snapshots they have. I ended up finding the snapshot listings on stackage and using ctrl+f in the browser to figure that out - after checking my stack.yaml to work out what snapshot list I should be looking at. Seriously. These leaps are crazy :)" I should point out this is from 5 years ago. Probably things are better now. But some things are not, e.g. installing Haskell on Arch Linux [1]. [0] https://www.reddit.com/r/haskell/comments/4sihcv/comment/d5aewx7/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/haskell/comments/4sihcv/comment/d5a... [1] https://dixonary.co.uk/blog/haskell/cabal-2020 https://dixonary.co.uk/blog/haskell/cabal-2020
  - jmfldn 5y ago
    The situation is improving from what I can see but what you're describing is hard to dispute. It's such a shame. As I say though, I think things are moving in a better direction now (I haven't taken a look at Haskell for a while).
  - stonemetal12 5y ago
    It is not unusual to not know what you are doing if you refuse to RTFM. The stack user guide existed 5 years ago, and explains exactly what to do for all the problems your example ran into. While I get not everyone has the same background, stack works very similarly to how C#, java, rust and just about every other compiled language with its own dependency management system works. His being surprised says more about him that it does stack.
  - the_af 5y ago
    > Great, now I have the tooling all set up! Slightly more irritating than other languages, but it's there. Python, which you mentioned in your other comment, is super irritating re: tooling -- yet people seldom find the need to "justify" using it. Sure, the simplest (and mostly wrong) way of setting Python up is seemingly trivial, just like Haskell's. You'll soon run into all kinds of trouble with pip and dependencies and environments and typechecking and linting and the myriad of confusing and slightly incompatible tools that form Python's wider ecosystem.
  - valcron1000 5y ago
    Yeah, that's very outdated and no longer the case. The tooling has improved a lot the last few years (I was there!). Today you would install 'ghcup', which manages compilers and build tools. Default installation includes the compiler (GHC) and build tool (cabal). Then you create a folder, run 'cabal init', add 'websockets' to your '.cabal' file ('build-depends'), and you're good to go (run 'cabal build/run'). I think it's pretty reasonable now, far better than other alternatives.
- spekcular 5y ago
  Could you give an example of something that is simple to express in Haskell, but harder and error prone to express in Go/Rust/[other imperative languages]? Honestly curious!
  - the_af 5y ago
    Just about anything written in Java requires more boilerplate and rituals than the same function in Haskell. (Or used to, of course: Java has slowly evolved and adopted FP idioms too). An example: you cannot express in Java "this function does not write to disk", its type system simply doesn't allow it. In order to make sure, you'd have to inspect the code of the function, and the libraries it uses. In Haskell, this is trivial because just by looking at the type of the function you can tell if it's even possible for it to do I/O. Go requires tons of boilerplate and didn't have generics until recently; there's your answer. Rust is a bizarre comparison. Haskell predates Rust and Rust takes some (many?) ideas from it or from languages within the same pedigree. Also, I don't know anyone who thinks Rust is "simple", so why ask about this comparison? Write Rust if you want to, no Haskeller is going to complain about your choice.
    - spekcular 5y ago
      Rust isn't a bizarre comparison at all. Suppose I have before me some programming task. I can choose Rust, Haskell, or something else. Anyone arguing for Haskell in 2021 (2022?) has to justify why it's a better tool for the job than Rust.
      - the_af 5y ago
        Why? I'm not trying to be dense. Are you saying for every programming language you choose, you make an strict ordering of every existing language and then decide which one you'll pick? Do you think there is a strict ordering of "is better than" between Haskell and Rust?
        spekcular 5y ago
        I'm saying that programming languages are tools for completing programming tasks. So, yes, when faced with a task I think about which one is best. Examples: Need to copy a bunch of files? Use bash. Need to do a quick Monte Carlo simulation? Probably use Python since it allows me to write it the fastest (based on my familiarity). Need to write drivers? Use C. I don't think there is a strict ordering of "is better than" between Haskell and Rust. I think for many purposes they are roughly equivalent, and for some one or the other is more suited to the task. But, if I can't identify any problem for which Haskell is a better tool than Rust, why would I ever learn Haskell?
nicoburns 5y ago
> Is this argument here just that it's memory safe and has static typing? What am I missing? I think the argument is that it provides stronger static typing than any of those languages, with only Rust being close out of the other languages that you list. This allows you to encode business logic (incl. security logic) invariants into the type system and catch a lot more errors/bugs at compile time. The step up from Java to Rust/Haskell in terms of static typing capabilities is at least as big as the step up from python to Java.
- spekcular 5y ago
  Sure. So I would like to know: What is a use case where strong static typing is a major advantage, and where Haskell is clearly better than Rust from a language design/feature perspective? edit: Another question. Is there a language that has stronger static typing than Rust without the weird performance pitfalls and subpar tooling that Haskell has? I can imagine a project for which such features would be useful, but getting over those two issues is difficult.
  - deleted 5y ago
    [deleted]
  - the_af 5y ago
    > What is a use case where strong static typing is a major advantage Writing correct code with fewer bugs. Catching bugs earlier. Not having to write unit tests for things the compiler can figure out for you, leaving you free to write the actual meaningful tests. Making code self-documenting with types, leading to less puzzlement. ... just to name a few.
    - simiones 5y ago
      While there may be some correlation between some static typing and less bugs, there definitely isn't a linear relationship: stronger type system => fewer bugs. In particular, strong types past some point start exploding code complexity for any kind of polymorphic code. My favorite example is adding strong typing to linear algebra operations, via units of measure for each element of a matrix. Try to find a library that can multiply matrices where each element can be a different physical quantity (of course, validating first that the two matrices can actually be multiplied) - say, multiplying (1m 2s⁻¹) * (2s⁻¹ 1m)ᵀ = 2m/s + 2m/s = 4m/s; but not allowing (1m 2s⁻¹) * (2m 1s⁻¹)ᵀ, since it would be 2m² + 2s⁻². Even if you can find such a library, it will be significantly more complex than an equivalent linear algebra library that is less strongly typed (one that only handles matrices of numbers, without units of measure).
stank345 5y ago
I'm not a seasoned Haskell dev by any means, having only played around with it for parsing and then more recently for Advent of Code, but tooling has come a long way in the past 6 months. I was able to use ghcup to very easily install and manage versions of GHC, cabal, and HLS (Haskell Language Server), the LSP server that the community has thrown all of its energy into. All I had to do then was configure the LSP client for my editor and everything just worked. I had function signatures/docs on hover, go to definition, and symbol renaming working in about a half hour.
the_af 5y ago
> I think any advocate for Haskell has to justify, at minimum, why it should be preferred to all of Rust/Go/Java/Python for a given use case At least the preference of Haskell vs Python is easy to justify: Haskell has a top-of-class static typing system and Python doesn't, which if you believe static types lead to better code (which I do), makes it clear why you'd prefer former. Whole classes of mistakes which are easy to create inadvertently using Python simply go away (or are very difficult to commit) using Haskell. If you care about code that is correct and with fewer bugs (on a continuum, of course) then that's your justification.
- AnimalMuppet 5y ago
  You might - might - be able to create those same bugs in Haskell. But you'd probably have to deliberately try. (They might be impossible even if you deliberately try to create them.)
  - the_af 5y ago
    You might indeed, but you'd have to go out of your way. Whereas with Python I write those bugs as easily as I breathe. Maybe I'm just a bad programmer; static types are definitely good for those like me. If that's not a practical, non-ivory tower reason to prefer Haskell, I don't know what is!
    - AnimalMuppet 5y ago
      Yeah. My memory's not good enough to not use static types.
whateveracct 5y ago
> I think any advocate for Haskell has to justify, at minimum, why it should be preferred to all of Rust/Go/Java/Python for a given use case. These all have way better tooling, developer ergonomics, and library support. Here's some justification: - All those languages force me to think imperatively, therefore hamstringing my mind. I don't want to waste time thinking in those languages. - Haskell has more universal potential. It's obviously a smaller community. BUT I can use Haskell to program FPGAs (clash), embedded systems (Ivory, CoPilot), frontend (ghcjs), write music (tidal, csound-expression, euterpea), shaders & graphics (GPipe, Hylogen), on top of general purpose computing (with a best-in-class FFI to boot.) The nature of the language is such that you can use Haskell for anything and have it still be Haskell - Rust, Go, etc can't get close to that capability. - None of those languages have tooling at the level of ghci. I've used both Go and Rust extensively and ghci blows their tooling out the water. Cabal is also just excellent nowadays. Haskell also has some of the best testing libraries out there too. - Haskell has better library support for its community size than those languages. It's substantially easier to find a quality Haskell library on Hackage than a Go one on GitHub. Haskell wins on the quality front, and most gaps imo can be filled easily (API bindings, for instance, are trivial.) - Developer ergonomics? Haskell's parametric & ad-hoc polymorphism alone combined with its RTS outclass all those languages imo. Go's RTS is worse. All those languages' parametric polymorphism is worse. ^ all this is true IF you have put in a good amount of time becoming a Haskell pro. For beginners, there are arguments against it. But I'm no beginner so why waste my time using that as my litmus test?

jmfldn 5y ago

Agree on tooling and library support. Not sure what developer ergonomics are? Ease of writing code, expressiveness? That's entirely subjective I would say. My subjective take is that, once you know a language like Haskell, it's hyper-productive and simple to express things that would be much harder and error prone in, say, an imperative language. Tradeoff is that it takes a while to get to this point. There is a steep learning curve. It's an amazing tool in the right hands / for the right problems. Tooling etc is such a pain point though.

spekcular 5y ago
"Ergonomics" is super vague, so let me give one concrete example. From reddit [0]: "I'm running Ubuntu so I installed ghc and cabal-install, then installed stack (since people are recommending that) by running their script. Then I found out that haskell-platform is the blessed route (and contains stack) so I uninstalled ghc, cabal, stack and installed that instead. Stack was not installed along with haskell-platform (what? why? ugh... whatever), so I reinstalled it manually. Great, now I have the tooling all set up! Slightly more irritating than other languages, but it's there. Now to build my app; I want to give websockets a whirl so I grabbed the server example and stuck it in a newly created stack project (stack new foo worked well) as app/Main.lhs and re-pointed foo.cabal to look at the .lhs extension. Ok, next step is to build it, stack build - it complains that I don't have websockets installed, ok, stack install websockets - it whirrs away for a while downloading stuff and then finishes. That was easy. stack build - same error, still no websockets (???). I take a look through the stack.yml and foo.cabal files and can't find websockets mentioned anywhere (in NodeJS I'd have done npm install --save websockets and it would have both installed the lib local to the project and updated the packages.json file appropriately - same sort of thing with Python via pip + freeze). Presumably I missed the '--save' or equivalent, but I don't see anything like this in the stack install -h docs. I hop onto irc for help, and am informed that you don't stack install project dependencies; that installs global packages (huh? I thought stack was supposed to help in keeping things local... whatever). Then I find that I have to edit the foo.cabal file manually to add my deps - seriously? Wow. Ok... So I do that (in the wrong place, then eventually in the right place) and finally my stack build works. Awesome! But also grrrr! Why are there two config files talking about libs and how am I supposed to know which one I'm meant to add stuff to? As an aside there's also the expectation that I should figure out which versions of libs are snapshotted on stackage, but searching on the website funnels me through to hackage (via hoogle) and gives me no indication on the way as to what snapshots they have. I ended up finding the snapshot listings on stackage and using ctrl+f in the browser to figure that out - after checking my stack.yaml to work out what snapshot list I should be looking at. Seriously. These leaps are crazy :)" I should point out this is from 5 years ago. Probably things are better now. But some things are not, e.g. installing Haskell on Arch Linux [1]. [0] https://www.reddit.com/r/haskell/comments/4sihcv/comment/d5aewx7/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/haskell/comments/4sihcv/comment/d5a... [1] https://dixonary.co.uk/blog/haskell/cabal-2020 https://dixonary.co.uk/blog/haskell/cabal-2020
- jmfldn 5y ago
  The situation is improving from what I can see but what you're describing is hard to dispute. It's such a shame. As I say though, I think things are moving in a better direction now (I haven't taken a look at Haskell for a while).
- stonemetal12 5y ago
  It is not unusual to not know what you are doing if you refuse to RTFM. The stack user guide existed 5 years ago, and explains exactly what to do for all the problems your example ran into. While I get not everyone has the same background, stack works very similarly to how C#, java, rust and just about every other compiled language with its own dependency management system works. His being surprised says more about him that it does stack.
- the_af 5y ago
  > Great, now I have the tooling all set up! Slightly more irritating than other languages, but it's there. Python, which you mentioned in your other comment, is super irritating re: tooling -- yet people seldom find the need to "justify" using it. Sure, the simplest (and mostly wrong) way of setting Python up is seemingly trivial, just like Haskell's. You'll soon run into all kinds of trouble with pip and dependencies and environments and typechecking and linting and the myriad of confusing and slightly incompatible tools that form Python's wider ecosystem.
- valcron1000 5y ago
  Yeah, that's very outdated and no longer the case. The tooling has improved a lot the last few years (I was there!). Today you would install 'ghcup', which manages compilers and build tools. Default installation includes the compiler (GHC) and build tool (cabal). Then you create a folder, run 'cabal init', add 'websockets' to your '.cabal' file ('build-depends'), and you're good to go (run 'cabal build/run'). I think it's pretty reasonable now, far better than other alternatives.
spekcular 5y ago
Could you give an example of something that is simple to express in Haskell, but harder and error prone to express in Go/Rust/[other imperative languages]? Honestly curious!
- the_af 5y ago
  Just about anything written in Java requires more boilerplate and rituals than the same function in Haskell. (Or used to, of course: Java has slowly evolved and adopted FP idioms too). An example: you cannot express in Java "this function does not write to disk", its type system simply doesn't allow it. In order to make sure, you'd have to inspect the code of the function, and the libraries it uses. In Haskell, this is trivial because just by looking at the type of the function you can tell if it's even possible for it to do I/O. Go requires tons of boilerplate and didn't have generics until recently; there's your answer. Rust is a bizarre comparison. Haskell predates Rust and Rust takes some (many?) ideas from it or from languages within the same pedigree. Also, I don't know anyone who thinks Rust is "simple", so why ask about this comparison? Write Rust if you want to, no Haskeller is going to complain about your choice.
  - spekcular 5y ago
    Rust isn't a bizarre comparison at all. Suppose I have before me some programming task. I can choose Rust, Haskell, or something else. Anyone arguing for Haskell in 2021 (2022?) has to justify why it's a better tool for the job than Rust.
    - the_af 5y ago
      Why? I'm not trying to be dense. Are you saying for every programming language you choose, you make an strict ordering of every existing language and then decide which one you'll pick? Do you think there is a strict ordering of "is better than" between Haskell and Rust?
      - spekcular 5y ago
        I'm saying that programming languages are tools for completing programming tasks. So, yes, when faced with a task I think about which one is best. Examples: Need to copy a bunch of files? Use bash. Need to do a quick Monte Carlo simulation? Probably use Python since it allows me to write it the fastest (based on my familiarity). Need to write drivers? Use C. I don't think there is a strict ordering of "is better than" between Haskell and Rust. I think for many purposes they are roughly equivalent, and for some one or the other is more suited to the task. But, if I can't identify any problem for which Haskell is a better tool than Rust, why would I ever learn Haskell?

nicoburns 5y ago

> Is this argument here just that it's memory safe and has static typing? What am I missing? I think the argument is that it provides stronger static typing than any of those languages, with only Rust being close out of the other languages that you list. This allows you to encode business logic (incl. security logic) invariants into the type system and catch a lot more errors/bugs at compile time. The step up from Java to Rust/Haskell in terms of static typing capabilities is at least as big as the step up from python to Java.

spekcular 5y ago
Sure. So I would like to know: What is a use case where strong static typing is a major advantage, and where Haskell is clearly better than Rust from a language design/feature perspective? edit: Another question. Is there a language that has stronger static typing than Rust without the weird performance pitfalls and subpar tooling that Haskell has? I can imagine a project for which such features would be useful, but getting over those two issues is difficult.
- deleted 5y ago
  [deleted]
- the_af 5y ago
  > What is a use case where strong static typing is a major advantage Writing correct code with fewer bugs. Catching bugs earlier. Not having to write unit tests for things the compiler can figure out for you, leaving you free to write the actual meaningful tests. Making code self-documenting with types, leading to less puzzlement. ... just to name a few.
  - simiones 5y ago
    While there may be some correlation between some static typing and less bugs, there definitely isn't a linear relationship: stronger type system => fewer bugs. In particular, strong types past some point start exploding code complexity for any kind of polymorphic code. My favorite example is adding strong typing to linear algebra operations, via units of measure for each element of a matrix. Try to find a library that can multiply matrices where each element can be a different physical quantity (of course, validating first that the two matrices can actually be multiplied) - say, multiplying (1m 2s⁻¹) * (2s⁻¹ 1m)ᵀ = 2m/s + 2m/s = 4m/s; but not allowing (1m 2s⁻¹) * (2m 1s⁻¹)ᵀ, since it would be 2m² + 2s⁻². Even if you can find such a library, it will be significantly more complex than an equivalent linear algebra library that is less strongly typed (one that only handles matrices of numbers, without units of measure).

stank345 5y ago

I'm not a seasoned Haskell dev by any means, having only played around with it for parsing and then more recently for Advent of Code, but tooling has come a long way in the past 6 months. I was able to use ghcup to very easily install and manage versions of GHC, cabal, and HLS (Haskell Language Server), the LSP server that the community has thrown all of its energy into. All I had to do then was configure the LSP client for my editor and everything just worked. I had function signatures/docs on hover, go to definition, and symbol renaming working in about a half hour.

the_af 5y ago

> I think any advocate for Haskell has to justify, at minimum, why it should be preferred to all of Rust/Go/Java/Python for a given use case At least the preference of Haskell vs Python is easy to justify: Haskell has a top-of-class static typing system and Python doesn't, which if you believe static types lead to better code (which I do), makes it clear why you'd prefer former. Whole classes of mistakes which are easy to create inadvertently using Python simply go away (or are very difficult to commit) using Haskell. If you care about code that is correct and with fewer bugs (on a continuum, of course) then that's your justification.

AnimalMuppet 5y ago
You might - might - be able to create those same bugs in Haskell. But you'd probably have to deliberately try. (They might be impossible even if you deliberately try to create them.)
- the_af 5y ago
  You might indeed, but you'd have to go out of your way. Whereas with Python I write those bugs as easily as I breathe. Maybe I'm just a bad programmer; static types are definitely good for those like me. If that's not a practical, non-ivory tower reason to prefer Haskell, I don't know what is!
  - AnimalMuppet 5y ago
    Yeah. My memory's not good enough to not use static types.

whateveracct 5y ago

> I think any advocate for Haskell has to justify, at minimum, why it should be preferred to all of Rust/Go/Java/Python for a given use case. These all have way better tooling, developer ergonomics, and library support. Here's some justification: - All those languages force me to think imperatively, therefore hamstringing my mind. I don't want to waste time thinking in those languages. - Haskell has more universal potential. It's obviously a smaller community. BUT I can use Haskell to program FPGAs (clash), embedded systems (Ivory, CoPilot), frontend (ghcjs), write music (tidal, csound-expression, euterpea), shaders & graphics (GPipe, Hylogen), on top of general purpose computing (with a best-in-class FFI to boot.) The nature of the language is such that you can use Haskell for anything and have it still be Haskell - Rust, Go, etc can't get close to that capability. - None of those languages have tooling at the level of ghci. I've used both Go and Rust extensively and ghci blows their tooling out the water. Cabal is also just excellent nowadays. Haskell also has some of the best testing libraries out there too. - Haskell has better library support for its community size than those languages. It's substantially easier to find a quality Haskell library on Hackage than a Go one on GitHub. Haskell wins on the quality front, and most gaps imo can be filled easily (API bindings, for instance, are trivial.) - Developer ergonomics? Haskell's parametric & ad-hoc polymorphism alone combined with its RTS outclass all those languages imo. Go's RTS is worse. All those languages' parametric polymorphism is worse. ^ all this is true IF you have put in a good amount of time becoming a Haskell pro. For beginners, there are arguments against it. But I'm no beginner so why waste my time using that as my litmus test?