11 ms·

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 s

by 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?

by jmfldn 5y ago

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?