Hacker News Reader

Comment by lambdasquirrel | Hacker News Reader

> 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.

View on HN

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...

Hostility toward beginners is a poor strategy if growth is the goal.

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.

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.

What’s wrong with single letter variable names? Were those variable names not associated with types that themselves have descriptive names?

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.

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.

That same issue hasn't slowed Go down, so something else is getting in the way.

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.

You say you're not a Haskeller, so I'm going to take what you say about the compiler internals with a grain of salt.

> 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.

  import Debug.Trace

  square x = 
      trace "I'm a Hard Problem" (x * x)

  main =
      print (square 3)

What do you mean by, "Languages like Haskell are built to do mathematics in first-and-foremost"?

It's hard for me to find a reasonable interpretation of this sentence that is true. I'm not sure much serious mathematics is done is Haskell, beyond the usual arithmetic operations present in most programs, especially relative to other programming languages. It hasn't taken off in the numerical computating market, for example.

Historically, it also seems like Haskell was built as a research language.

He probably mean a heavy focus on type theory. It has been used in formal verification as a prototype tool [1].

[1]: https://en.wikipedia.org/wiki/L4_microkernel_family#High_ass...

I'm not sure much serious mathematics is done is Haskell, beyond the usual arithmetic operations present in most programs, especially relative to other programming languages. It hasn't taken off in the numerical computating market, for example.

All that stuff about types and categories and monads and so on is maths too. Arithmetic or numerical work is only a subset of that field. Lots of maths doesn’t even involve numbers!

So let me ask again: in what sense do people "do mathematics" in Haskell?

They don't really "do" category theory, for example; simply noting that something forms a category is mathematics only in the most trivial sense.

> All that stuff about types and categories and monads and so on is maths too.

I think the question he's asking is: What papers have been published in math journals where the work was done in Haskell? Which mathematicians use Haskell to do mathematics work?

Not much afaict. For mathematics, it's usually Coq, maybe Lean or Agda. For scientific computing it's Python or Julia.

To be fair, Agda is a fusion of Martin-Löf type theory and Haskell if my memory serves me.

You can use HaskellR (https://tweag.github.io/HaskellR/) for everything scientific that is being written in Python and Julia.

Everything in computers is math. Floating point numbers are math. Java generics with inheritance are math. It's not a point of distinction.

> 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.

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.

Yes, exactly: a function that requires a volatile (or IO) annotation is one for which (some of) the things you could use a non-volatile function to prove are not actually true. If you want to lie to the compiler[0], unsafePerformIO, seq, and other unsound primitives are available and documented. Contrariwise, if you want to not lie to compiler, the primitives for that are also available and documented.

0: Which is a completely resonable thing to do, and the basis of any language's standard library, the ability to recapitulate which in normal code separates good languages from Go-like special-cases-for-me-but-not-for-thee languages.

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!

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.

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.

Reply on news.ycombinator.com