4 ms·

> There isn't really any evidence that Haskell is more productive than Go. Go appears to be a network services language. Although Haskell has equally good for-

> There isn't really any evidence that Haskell is more productive than Go. Go appears to be a network services language. Although Haskell has equally good for-loops and channels, it does not have an incremental garbage collector or fast build times. So Go has its place. For general purpose programming, Go is lacking so many features and provides such verbose syntax for what little it does have (worse than modern Java, e.g Lambdas and conditionals), that one can certainly say it is starting from a disadvantaged point with regard to productivity. It sounds like you've had some bad experiences with some of Haskells libraries and tooling. The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. With regard to complex abstractions, the Haskell community usually likes to formalise and reuse them. Learning an abstraction usually results in a big payoff. EDIT: > Do monad transformers make me more productive? Monad transformers are specific to pure functional programming, but yes they aid productivity. For example, I can build an effectful streaming type with resource management and other desired features by stacking existing transformers. In Go I would be solving such problems with for loops. > Do functional dependencies make me more productive? Functional dependences are specific to Haskell type classes, but yes they can aid productivity. For example, you want to express arithmetic ops on matrices and scalars and have the compiler figure out the correct dispatch and return type depending on the type of the values. In Go I can't overload operators or do multiple dispatch.

foldr 9y ago
>The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. Hmm, that's what people have been telling me since I first learned Haskell in 2002. Your brush this off as if it's a minor point ("some bad experiences with Haskell's libraries and tooling"), but libraries, tooling and compile times are a major, major influence on productivity. If you're at leisure to wait for decent libraries and tools to become available, then good for you! I was kind of hoping to get stuff done now, though. Abstractions have both positive and negative payoffs. Take MTL as an example. It certainly increases code reuse and makes code more concise. On the other hand, it's also partly responsible for Haskell having a gazillion different techniques for handling errors, with little community consensus on what the best techniques are (see e.g. https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_best_practices_in_haskell/ https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_...). I spend at least some time thinking about this stuff when I write Haskell code. I spend no time thinking about it when I write go code -- I just write the same error handling boilerplate that every go programmer uses. It's not pretty, and I don't get to pat myself on the back for understanding something complicated. But does it make me less productive? Not sure. Response to edits: I think you're misunderstanding my comment. I use these features and know what they are. I'm telling you that I do not see any clear productivity benefit from them in practice. Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice.
- willtim 9y ago
  > If you're at leisure to wait for decent libraries and tools to become available, then good for you! As I said, it depends on the area you are working in. Haskell does have some good libraries. > Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice Please don't take it personally, I was attempting to explain those features that you mentioned to others who might read our posts (perhaps wishful thinking). I try to promote Haskell whenever I can because it has been enormously successful in everything I have applied it to and needs all the help it can get. It doesn't have a billion dollar company behind it, just a small community of mostly volunteers.
  - tome 9y ago
    > I was attempting to explain those features that you mentioned to others who might read our posts (perhaps wishful thinking). /waves from the gallery
  - foldr 9y ago
    Tool quality and compile times are an issue whatever area you are working in, however.
    - willtim 9y ago
      Compile times are often mitigated by just using the runHaskell interpreter, or turning off optimisations. What sort of tools does Go have that Haskell doesn't? From what I can see, most Go projects just use Makefiles and text editors. The package manager is described as "experimental". In Haskell land we have many good choices, with my favourite (for deterministic reproducible builds), being nix and cabal new-build. I've also seen Haskell Shake replace C++ Makefiles at work for a huge speedup. Haskell has good API search (Hoogle), docgen (Haddock), lint (HLint) and graphical profiling tools (Threadscope). Refactoring tools like HaRe and others, are also starting to appear.
      - foldr 9y ago

foldr 9y ago

>The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. Hmm, that's what people have been telling me since I first learned Haskell in 2002. Your brush this off as if it's a minor point ("some bad experiences with Haskell's libraries and tooling"), but libraries, tooling and compile times are a major, major influence on productivity. If you're at leisure to wait for decent libraries and tools to become available, then good for you! I was kind of hoping to get stuff done now, though. Abstractions have both positive and negative payoffs. Take MTL as an example. It certainly increases code reuse and makes code more concise. On the other hand, it's also partly responsible for Haskell having a gazillion different techniques for handling errors, with little community consensus on what the best techniques are (see e.g. https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_best_practices_in_haskell/ https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_...). I spend at least some time thinking about this stuff when I write Haskell code. I spend no time thinking about it when I write go code -- I just write the same error handling boilerplate that every go programmer uses. It's not pretty, and I don't get to pat myself on the back for understanding something complicated. But does it make me less productive? Not sure. Response to edits: I think you're misunderstanding my comment. I use these features and know what they are. I'm telling you that I do not see any clear productivity benefit from them in practice. Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice.

willtim 9y ago
> If you're at leisure to wait for decent libraries and tools to become available, then good for you! As I said, it depends on the area you are working in. Haskell does have some good libraries. > Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice Please don't take it personally, I was attempting to explain those features that you mentioned to others who might read our posts (perhaps wishful thinking). I try to promote Haskell whenever I can because it has been enormously successful in everything I have applied it to and needs all the help it can get. It doesn't have a billion dollar company behind it, just a small community of mostly volunteers.
- tome 9y ago
  > I was attempting to explain those features that you mentioned to others who might read our posts (perhaps wishful thinking). /waves from the gallery
- foldr 9y ago
  Tool quality and compile times are an issue whatever area you are working in, however.
  - willtim 9y ago
    Compile times are often mitigated by just using the runHaskell interpreter, or turning off optimisations. What sort of tools does Go have that Haskell doesn't? From what I can see, most Go projects just use Makefiles and text editors. The package manager is described as "experimental". In Haskell land we have many good choices, with my favourite (for deterministic reproducible builds), being nix and cabal new-build. I've also seen Haskell Shake replace C++ Makefiles at work for a huge speedup. Haskell has good API search (Hoogle), docgen (Haddock), lint (HLint) and graphical profiling tools (Threadscope). Refactoring tools like HaRe and others, are also starting to appear.
    - foldr 9y ago