8 ms·

> Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a s

> Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. To elaborate further, some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane. We are just trying to build things here. These are very boring implementation issues that just need to get done.

a1369209993 6y ago
I admittedly don't engage with the Haskell community much myself, but I'd speculate that part of the problem is the fact that C++/Java/Python/etc-style exceptions (as opposed to things like Either Excep t or SomeMonadFail t) are very boring implementation issues that specifically need to not get done. I'd also speculate that whoever you talked to did a poor job of articulating that.
derefr 6y ago
Not a Haskeller, but I'd like to try to change your mind about this point: > We are just trying to build things here. Some languages are built to do engineering first-and-foremost. Languages like Haskell are built to do mathematics in first-and-foremost. This doesn't mean that such languages aren't also well-engineered, or that they aren't also tuned to do engineering in; but the engineering concerns must be subordinated to not breaking the model that mathematicians rely upon to do math in the language. So you can't just e.g. change whether a particular kind of function can emit IO or not; or change what values exist as part of the lattice of a type; or any number of other things visible within the language's abstraction; because those very properties/constraints are also syllogisms which are relied upon in mathematics done in the language. And before you say "why not just break the runtime model", by e.g. having special debug functions that can do IO while presenting to the runtime as pure functions—well, it's not impossible, in theory, but it's a Hard Problem, because those properties that a function presents to the runtime are also used by the compiler to optimize (or memoize, or fuse, or eliminate) code. You can't really declare something as a pure function without the runtime thinking it can do all sorts of things that result in the function being called less. In theory, Haskell could have something like a "volatile" qualifier for functions, sort of like C's volatile qualifier for data, to tell the runtime that while the function has type X, all optimization opportunities that would normally apply to type X are off the table. Then you could have special debug functions of type X. It's just that getting this working would require a lot of re-work throughout the compiler, since the compiler mostly deduces optimization opportunities from the type (and marks something as having more optimization opportunities by proving that it has an extra applicable type), rather than just tracking some separate metadata that can be arbitrarily written to.
- pron 6y ago
  And in theory, Haskell could be exceptionally fast, or exceptionally correct, or exceptionally maintainable while in practice it is none of those things. It is, however, a relatively elegant language that explores interesting ideas and that some people enjoy, and that's great!
  - dddbbb 6y ago
    I honestly think that Haskell's combined speed/correctness/maintainability is exceptional, none is in isolation, but I can't think of any reasonably production-ready language that has such a great combination of all three.
    - deleted 6y ago
      [deleted]
    - pron 6y ago
      I honestly think it's well behind some of the most popular mainstream languages in that combination, and that that's why we haven't seen a proliferation of Haskell even at companies where it is already actively used for some years alongside other languages.
- a1369209993 6y ago
  > In theory, Haskell could have something like a "volatile" qualifier for functions foo :: IO X Haskell already has that, it just shoves the compiler re-work off on the programmer.
  - derefr 6y ago
    The point of what I said is that in many cases, lifting a function into a monad means that the code that uses said function can no longer be used to prove what you set out to prove by writing it.
    - a1369209993 6y ago
markstos 6y ago
I used to contribute to the Darcs project, which is written in Haskell. It read like a series of math equations, with frequent single letter variable names. It was concise and elegant in it's own way, but hard to follow in some cases due the lack of readable variable names. I like the language but this cultural aspect made it harder to get up to speed and contribute.
- gowld 6y ago
  That same issue hasn't slowed Go down, so something else is getting in the way.
- yakshaving_jgt 6y ago
  What’s wrong with single letter variable names? Were those variable names not associated with types that themselves have descriptive names?
  - markstos 6y ago
    I randomly opened a file in the Darcs code base and picked a line: mReadFilePS p = B.concat `fmap` BL.toChunks `fmap` TM.readFile p To understand this, you need to know what "m", "PS", "B", "BL" and "TM" mean. In Node.js, the convention is that classes are named after the modules they import-- they are full words: const config = require('config') In Darcs, we find this: import qualified Data.ByteString as B import qualified Data.ByteString.Lazy as BL import qualified Data.Map as M import qualified Darcs.Util.Tree.Monad as TM I guess you get used to it, but it's a steeper learning curve for contributors to memorize more items to get up to speed.
    - yakshaving_jgt 6y ago
      I don't understand. There is no memorisation necessary. The modules are imported, qualified by an alias. I'll accept the learning curve for Haskell is at least longer (rather than steeper) than in most languages, but to hold this up as an example to me is just bizarre. And I say this is someone who only knew JavaScript and PHP for some years before learning a bunch of other languages including Haskell. Moreover, you've conveniently left out the type signature which I expect would normally accompany this function, which would tell the reader what the `p` variable is.
exdsq 6y ago
I've found the opposite - I work with quite a few 'prominent' figures in the Haskell community and they are very approachable and friendly. The most hostile I've experienced was Stack Overflow as a beginner...
- shivasword 6y ago
  Hostility toward beginners is a poor strategy if growth is the goal.

a1369209993 6y ago

I admittedly don't engage with the Haskell community much myself, but I'd speculate that part of the problem is the fact that C++/Java/Python/etc-style exceptions (as opposed to things like Either Excep t or SomeMonadFail t) are very boring implementation issues that specifically need to not get done. I'd also speculate that whoever you talked to did a poor job of articulating that.

derefr 6y ago

Not a Haskeller, but I'd like to try to change your mind about this point: > We are just trying to build things here. Some languages are built to do engineering first-and-foremost. Languages like Haskell are built to do mathematics in first-and-foremost. This doesn't mean that such languages aren't also well-engineered, or that they aren't also tuned to do engineering in; but the engineering concerns must be subordinated to not breaking the model that mathematicians rely upon to do math in the language. So you can't just e.g. change whether a particular kind of function can emit IO or not; or change what values exist as part of the lattice of a type; or any number of other things visible within the language's abstraction; because those very properties/constraints are also syllogisms which are relied upon in mathematics done in the language. And before you say "why not just break the runtime model", by e.g. having special debug functions that can do IO while presenting to the runtime as pure functions—well, it's not impossible, in theory, but it's a Hard Problem, because those properties that a function presents to the runtime are also used by the compiler to optimize (or memoize, or fuse, or eliminate) code. You can't really declare something as a pure function without the runtime thinking it can do all sorts of things that result in the function being called less. In theory, Haskell could have something like a "volatile" qualifier for functions, sort of like C's volatile qualifier for data, to tell the runtime that while the function has type X, all optimization opportunities that would normally apply to type X are off the table. Then you could have special debug functions of type X. It's just that getting this working would require a lot of re-work throughout the compiler, since the compiler mostly deduces optimization opportunities from the type (and marks something as having more optimization opportunities by proving that it has an extra applicable type), rather than just tracking some separate metadata that can be arbitrarily written to.

pron 6y ago
And in theory, Haskell could be exceptionally fast, or exceptionally correct, or exceptionally maintainable while in practice it is none of those things. It is, however, a relatively elegant language that explores interesting ideas and that some people enjoy, and that's great!
- dddbbb 6y ago
  I honestly think that Haskell's combined speed/correctness/maintainability is exceptional, none is in isolation, but I can't think of any reasonably production-ready language that has such a great combination of all three.
  - deleted 6y ago
    [deleted]
  - pron 6y ago
    I honestly think it's well behind some of the most popular mainstream languages in that combination, and that that's why we haven't seen a proliferation of Haskell even at companies where it is already actively used for some years alongside other languages.
a1369209993 6y ago
> In theory, Haskell could have something like a "volatile" qualifier for functions foo :: IO X Haskell already has that, it just shoves the compiler re-work off on the programmer.
- derefr 6y ago
  The point of what I said is that in many cases, lifting a function into a monad means that the code that uses said function can no longer be used to prove what you set out to prove by writing it.
  - a1369209993 6y ago

markstos 6y ago

I used to contribute to the Darcs project, which is written in Haskell. It read like a series of math equations, with frequent single letter variable names. It was concise and elegant in it's own way, but hard to follow in some cases due the lack of readable variable names. I like the language but this cultural aspect made it harder to get up to speed and contribute.

gowld 6y ago
That same issue hasn't slowed Go down, so something else is getting in the way.
yakshaving_jgt 6y ago
What’s wrong with single letter variable names? Were those variable names not associated with types that themselves have descriptive names?
- markstos 6y ago
  I randomly opened a file in the Darcs code base and picked a line: mReadFilePS p = B.concat `fmap` BL.toChunks `fmap` TM.readFile p To understand this, you need to know what "m", "PS", "B", "BL" and "TM" mean. In Node.js, the convention is that classes are named after the modules they import-- they are full words: const config = require('config') In Darcs, we find this: import qualified Data.ByteString as B import qualified Data.ByteString.Lazy as BL import qualified Data.Map as M import qualified Darcs.Util.Tree.Monad as TM I guess you get used to it, but it's a steeper learning curve for contributors to memorize more items to get up to speed.
  - yakshaving_jgt 6y ago
    I don't understand. There is no memorisation necessary. The modules are imported, qualified by an alias. I'll accept the learning curve for Haskell is at least longer (rather than steeper) than in most languages, but to hold this up as an example to me is just bizarre. And I say this is someone who only knew JavaScript and PHP for some years before learning a bunch of other languages including Haskell. Moreover, you've conveniently left out the type signature which I expect would normally accompany this function, which would tell the reader what the `p` variable is.

exdsq 6y ago

I've found the opposite - I work with quite a few 'prominent' figures in the Haskell community and they are very approachable and friendly. The most hostile I've experienced was Stack Overflow as a beginner...

shivasword 6y ago
Hostility toward beginners is a poor strategy if growth is the goal.