News for hackers. Stuff that matters.
Re:On Marketing Haskell by lambdasquirrel on Saturday May 30, 2020 @02:25PM (#23363377)
> 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.

Re:On Marketing Haskell by exdsq on Saturday May 30, 2020 @04:40PM (#23364504)
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...
Re:On Marketing Haskell by shivasword on Saturday May 30, 2020 @11:05PM (#23366817)
Hostility toward beginners is a poor strategy if growth is the goal.
Re:On Marketing Haskell by a1369209993 on Saturday May 30, 2020 @03:31PM (#23363906)
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.
Re:On Marketing Haskell by markstos on Saturday May 30, 2020 @04:11PM (#23364224)
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.

Re:On Marketing Haskell by yakshaving_jgt on Saturday May 30, 2020 @11:46PM (#23367011)
What’s wrong with single letter variable names? Were those variable names not associated with types that themselves have descriptive names?
Re:On Marketing Haskell by markstos on Monday June 08, 2020 @01:53PM (#23458874)
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.
Re:On Marketing Haskell by yakshaving_jgt on Monday June 08, 2020 @02:05PM (#23459001)
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.

Re:On Marketing Haskell by gowld on Saturday May 30, 2020 @06:45PM (#23365504)
That same issue hasn't slowed Go down, so something else is getting in the way.
Re:On Marketing Haskell by derefr on Saturday May 30, 2020 @03:32PM (#23363907)
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.

Re:On Marketing Haskell by mrkeen on Saturday May 30, 2020 @06:25PM (#23365348)
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)
Re:On Marketing Haskell by spekcular on Saturday May 30, 2020 @04:15PM (#23364265)
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.

Re:On Marketing Haskell by danielscrubs on Sunday May 31, 2020 @09:48AM (#23369568)
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...

Re:On Marketing Haskell by goatinaboat on Saturday May 30, 2020 @05:50PM (#23365082)
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!

Re:On Marketing Haskell by spekcular on Saturday May 30, 2020 @07:53PM (#23365927)
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.

Re:On Marketing Haskell by BeetleB on Saturday May 30, 2020 @09:06PM (#23366316)
> 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?

Re:On Marketing Haskell by throwaway518365 on Saturday May 30, 2020 @09:42PM (#23366500)
Not much afaict. For mathematics, it's usually Coq, maybe Lean or Agda. For scientific computing it's Python or Julia.
Re:On Marketing Haskell by danielscrubs on Sunday May 31, 2020 @08:57AM (#23369284)
To be fair, Agda is a fusion of Martin-Löf type theory and Haskell if my memory serves me.
Re:On Marketing Haskell by ghostwriter on Sunday May 31, 2020 @01:40AM (#23367472)
You can use HaskellR (https://tweag.github.io/HaskellR/) for everything scientific that is being written in Python and Julia.
Re:On Marketing Haskell by gowld on Saturday May 30, 2020 @06:44PM (#23365494)
Everything in computers is math. Floating point numbers are math. Java generics with inheritance are math. It's not a point of distinction.
Re:On Marketing Haskell by a1369209993 on Saturday May 30, 2020 @03:39PM (#23363945)
> 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.
Re:On Marketing Haskell by derefr on Sunday May 31, 2020 @01:25PM (#23370994)
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.
Re:On Marketing Haskell by a1369209993 on Sunday May 31, 2020 @03:38PM (#23372033)
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.

Re:On Marketing Haskell by pron on Saturday May 30, 2020 @03:36PM (#23363928)
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!
Re:On Marketing Haskell by dddbbb on Saturday May 30, 2020 @04:38PM (#23364487)
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.
Re:On Marketing Haskell by pron on Monday June 01, 2020 @08:16AM (#23377651)
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.