Live data from Hacker News

Why GitHub used Haskell for Semantic

github.com

71–80 of 214 posts

Re: Why GitHub used Haskell for Semantic

#71
post #4

I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…

If you'll forgive the analogy, Haskell is kind of like the Mercedes of production-ready research-grade languages. You may not actually use haskell, but the features that haskell is pioneering are what you'll see trickling down into other languages, as language designers look over and borrow things. Some examples (though they're not all invented by haskell, but haskell has popularized them IMO):

- non-nullable types

- immutability as a default

- typeclassses + structs

- abstract data types

- errors-as-values

- monads

Haskell or any other ML language didn't come up with all these things of course, but Haskell is one of the best languages

Take a look at rust -- it's basically got a near haskell-grade type system (and there are lots of ML languages with more flexible type systems than Haskell as well), with C++ like performance. It would have been a lot harder for rust's designers to incorporate such a nice type system without the exploratory work haskell did and continues to do.

All that said, I'm pretty sure Haskell is seeing little adoption because of the learning curve.

> The most successful languages let you be pure-functional where it makes sense and then stateful where it makes sense. Haskell doesn't, really (from my cursory reading about it).

Haskell almost certainly does this, this is actually one of the best features of haskell -- it lets you do functional things and stateful things separately and encourages you to keep them separate.

Re: Why GitHub used Haskell for Semantic

#72
post #4

I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…

Cannot speak for industry, so speaking from experience in academia when we were learning functional programming (FP).

The key difficulty there is the paradigm shift in thinking. For most people our thinking matches imperative programming. Ask a person to do something like run an analysis of an accounting book using paper, pen, and a calculator, and you'll see them keep some tallies which they keep updating as they go along. Even if there was a way to convert their work into a method which just involves repeatedly tapping out the numbers into a calculator in a formulaic way, almost every time it's going to be easier to reason about the logic in terms of stored state and progressive steps.

When you get hit with the paradigm of functional programming, which is beautiful when it works btw, you need to switch your thinking from pure logic to formulae driven logic. That's an unnatural shift and given how poorly early schooling helps shift our thinking to that mindset when we do maths, it's a hell of a leap.

Anecdotally we had a couple of pros at math - people who understood the fundamental beauty of math and proofs - and they took to FP like ducks in water. Even when we built a library management system in Haskell.

Re: Why GitHub used Haskell for Semantic

#73

Earlier quoted context omitted.

How far can you go without monads and category theory? I was looking at Clean which developed in parallel with Haskell and uses uniqueness typing instead of IO/mutation monads. Seems like it would be less offputting for a newcomer. Clean lacks community and a package manager, I believe which makes it less attractive. The language itself seems like a sweet spot for me.

Not used Clean, but it sounds interesting. What i'd love is an imperative language where you declare what effects a method can have and the compiler enforces them. E.g. if it promises not to mutate any parameters, it can only call functions that make the same promise etc.

That sounds very similar to Rust. Mutations and even memory lifetime are specified in the type system.

Re: Why GitHub used Haskell for Semantic

#74
post #19
post #4

I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…

It's 100% the difficulty. Anyone saying otherwise is lying because they want Haskell to be popular, adopted it very early on in their career when they could really invest in it, or is a natural at this type of stuff and simply doesn't know any better. I've learned about 10 different languages now and Haskell easily had the highest learning curve. Most languages I was able to get semi-usable in within a couple days, a…

The problem with that explanation is that Haskell is no more difficult than Rust. (Someone who knows Rust well must learn about the IO monad and then can start being productive in Haskell. Unlike what one comment on this page implies, there is no need to learn any category theory to be productive in Haskell.) Yet Rust has been used in about as many successful projects as Haskell despite Haskell's having a head start of about 30 years on Rust.

Re: Why GitHub used Haskell for Semantic

#75

Earlier quoted context omitted.

Only in American English. Groups are plural in British English. "The police are corrupt" vs "the police is corrupt".

That second example is not valid in any English.

It could be valid if the subject is a British, new wave band, but otherwise, I agree with you.

Re: Why GitHub used Haskell for Semantic

#76
post #12

Earlier quoted context omitted.

I havr never noticed immutable data structures to be more difficult to deal with. For the most part, because of monads and effects and such you can essentially write better imperative code in haskell. Im noy sure why youve decided that haskell is incapable of the syntactic appearance of mutation.

To be fair I haven't really used it, only read the core of the guide, so I may be mistaken. But I've done a bit of Clojure, and I've done a bit of Immutable.js, and particularly when you have a deeply-structured piece of data, "mutating" something a few levels down gets really ugly. Now, maybe something about Haskell Enlightenment obviates this case entirely in a way I'm not seeing. But I also remember Haskell seemin…

But I've done a bit of Clojure, and I've done a bit of Immutable.js, and particularly when you have a deeply-structured piece of data, "mutating" something a few levels down gets really ugly.

As opposed to what languages?

Re: Why GitHub used Haskell for Semantic

#77
post #4

I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…

I think Haskell actually has a few qualities that can potentially turn people off at different points, all of which have been mentioned by others:

* Lazy Evaluation -- usually becomes an issue at some point if the project isn't trivial. * Lack of dependent types -- while Haskell's types system is great, this is a missing piece that proves a sore absence for some. It's not very surprising that several functional languages developed after haskell, inspired by haskell, and implemented in haskell (idris, agda, coq) * category theory -- While you can get by plenty well just knowing a few basic abstractions from category theory, it's true that many libraries rely on highly-theorectical concepts, and that a solid portion of haskell development efforts are still tinged with an academic flavor. Just take a look at some of Edward Kmett's coding videos--he typically has one (or several) mathematics/highly theoretical comp sci papers open in one window, while in the other he's implementing a hugely popular library like lens. This sort atmosphere of academism turns a lot of people off. It pegs the language as a theoretical exercise from the get go, and plenty of people are either don't believe in the value of theory or are far too busy to take the time to dive into how it applies to their situation.

I think the academic veneer around haskell is its biggest weakness when it comes to adoption, but that's said, it's still had more success than a lot of other academic, purely functional languages thanks to the efforts of core researchers/users/contributors to break it out of the ivory tower. The ideas are good. Almost every other modern programming language has stolen concepts from haskell at this point--so in some sense even though it's still somewhat niche its influence is practically ubiquitous (just take a look at the list of languages its noted as having influenced on wikipedia! https://en.wikipedia.org/wiki/Haskell_(programming_language)).

In a broader sense, the functional programming paradigm has proven not only that it's a viable one for industry applications, but often superior to object oriented or imperative techniques when it comes to fidelity of expression and preventing bugs. If nothing else, haskell is great because it provides a fairly rigorous environment in which you can explore functional programming concepts, which you can bring with you to almost any problem and any language and manage to derive some benefit.

Re: Why GitHub used Haskell for Semantic

#78
post #55
post #24

Earlier quoted context omitted.

You seem like someone who could answer this: why use PureScript over Elm?

I've worked in Elm a decent bit, and used PureScript a little. Elm is a very opinionated language - it's very deliberately missing some abstraction power (typeclasses), and some functions that are the bread-and-butter of every functional programmer have steadily been getting removed from the base libraries, so if you're used to Haskell, you'll find yourself falling back to duplicating code by hand a lot. Elm also mak…

While there was nothing particularly wrong with bower for PureScript use case, it's always failed to attract people for that reason sadly. However, you can use Spago now to great success.

Re: Why GitHub used Haskell for Semantic

#79
post #4

I'm really curious why Haskell has seen so little adoption in industry. Is it just the difficulty? Or a chicken-and-egg effect with tooling and libraries? One thing I've wondered is if it actually isn't ideal for a lot of cases. FP is beautiful for certain things. But in some domains (or pieces of domains), state and mutation aren't just unfortunate implementation details, but a core element of the problem space. For…

In fighting games, characters are sometimes described in terms of their “skill cap” and “skill floor”. The “skill cap” is how well you can play, if you really invest in this character. The “skill floor” is about how bad things can get if you don’t play that well.

Some characters are very approachable and easy to play. If you don’t know what you are doing, it’s alright — you can muddle through. If you play them in a really exceptional way, it doesn’t make all that much difference.

Some characters are really tough to play at all; and once you figure it out, they aren’t particularly exceptional and don’t reward further investment.

A “high skill cap” character is one where you can keep learning and learning and your performance at the game will actually get better and better. Some of these characters are also approachable — they have a gentle learning curve. Some of these characters are basically unplayable until you can play them really well — there is an inflection far to the right where you go from dying all the time to actually winning a fair number of matches.

Haskell is like one of these characters. Until you’re really good and know a lot, you’re basically going to ship nothing. This effect is sort of invisible to senior programmers learning Haskell because they are already so skillful and are used to having to skim a CS paper or two, once in awhile, to be able to get their work done. Once you are good at Haskell, vistas really open for you in terms of the kind of programs you can design and build. Many year after setting it aside, I still rely on what I learned about Haskell API design and effects modeling to design reliable, transparent and modular distributed systems (it all starts with the types).

“High skill cap” characters tend to be admired, but not frequently played.

Re: Why GitHub used Haskell for Semantic

#80
post #10

Earlier quoted context omitted.

Because in its current form the subject and verb don't agree.

Only in American English. Groups are plural in British English. "The police are corrupt" vs "the police is corrupt".

Good try but an errant example. American English treats "police" as a plural noun (although maybe not always in Baltimore).

In the British style, "Microsoft have released a press briefing"; in American, "Microsoft has released a press briefing."

Post reply on HN