Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why GitHub used Haskell for Semantic

github.com

Post reply on HN
Print view View original

41–50 of 214 posts

Re: Why GitHub used Haskell for Semantic

#41

Post by quickthrower2 »

dmix wrote: post #19
_bxg1 wrote: 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…

I agree. You master monads and IO, but then you want to use a web framework and there a bunch of other category theoretical concepts and/or Haskell advanced features you need to understand to serve up "Hello World". Compare that to expressjs. I love functional programming, but given the free choice of what to use to knock up a side project, I chose JS at home. Nothing like grabbing some data from a server, and it being an object you can use immediately in your code and access using indexers, properties etc (rather than some strange lens operator like ~~!!#).

Typescript cures most of the JS ills. Sure TS is more akin to Java/C# and not the much better Haskell type system. But it is good enough and catches 99% of the real world problems of naked JS.

To me Haskell is training for your brain. Once trained you are a better JS/C#/Java/C++ programmer.

I could go on about the economics of getting a Haskell job:. Haskell and Elm developers are taking a paycut compared to what they would earn if they used any language. Even if they are paid well they could get paid more. Supply/demand at work there.

Re: Why GitHub used Haskell for Semantic

#42

Post by rbonvall »

jerf wrote: post #18
_bxg1 wrote: post #12

Earlier quoted context omitted.

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…

"Now, maybe something about Haskell Enlightenment obviates this case entirely in a way I'm not seeing." Many times the answer is that with a different structure you don't need deep mutation to be a critical part of your program. After all, "deep mutation" isn't considered a great idea in object-oriented languages either, where it constitutes a violation of the Law of Demeter [1], either in letter or in spirit (i.e.,…

Let me add that lenses are not just a Haskell thing. It's a simple (and beautiful IMHO) concept from functional programming that can be introduced in many languages. Also, you can have lenses without the cryptic operators.

Re: Why GitHub used Haskell for Semantic

#43

Post by thrower123 »

kartickv wrote: post #38
_bxg1 wrote: 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…

My theory is that the FP folks would have seen more success had they figured out ways to bring their features to mainstream languages, rather than asking people to adopt wholesale their weird languages (from an average programmer's point of view). For example, why can't I annotate functions as lazy? Swift takes one step in that direction, with lazy var, but why not a lazy func or lazy class? Even the lazy var can't b…

This seems to be the path that the C# language team is on, one step at a time, boiling the frog slowly.

Re: Why GitHub used Haskell for Semantic

#44

Post by whateveracct »

thrwayxyz wrote: post #23
tathougies wrote: post #6

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.

You're lucky enough if you can find a developer who knows mutable data structures outside of SF. If you want immutable ones you need to add a zero to their wage. Most shops aren't prepared for that.

I've had random interns enter a purely functional codebase with 0 FP background. With a normal amount of onboarding, they were using immutable data structures with ease.

Re: Why GitHub used Haskell for Semantic

#45

Post by whateveracct »

jrockway wrote: post #3

> given Go's lack of exceptions, such a feature would be entirely impossible. Haskell is a nice programming language, but ultimately if a program written in language A can run on your computer, a program can be written in language B that can run on your computer and do the same things. If you think "return foo, err" is a lot different than return "Left foo" or "Right err", then you might want to think more about how…

If you think those two things are the same, you're just in the wrong. This isn't an opinion thing - I can easily prove that the Haskell way is strictly more precise than the Go way!

Not all Turing complete languages are the same. Curry-Howard shows that. Haskell's type system subsumes Go's and allows you to express richer propositions about program behavior.

Re: Why GitHub used Haskell for Semantic

#46

Post by zzzeek »

kartickv wrote: post #38
_bxg1 wrote: 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…

My theory is that the FP folks would have seen more success had they figured out ways to bring their features to mainstream languages, rather than asking people to adopt wholesale their weird languages (from an average programmer's point of view). For example, why can't I annotate functions as lazy? Swift takes one step in that direction, with lazy var, but why not a lazy func or lazy class? Even the lazy var can't b…

Python has tons of functional features [1] while not being a purist FP by any means. This article liked to say quite often that "X would be impossible in Go or Java!" and I kept thinking, "I bet it's possible in Python, just not as academically wonderfully as you were hoping".

As it turns out, Python continues to be one of the top three languages in terms of popularity. It's not clear if this has helped feed a bigger userbase into purist FP languages though.

[1] https://docs.python.org/3/howto/functional.html

Re: Why GitHub used Haskell for Semantic

#47

Post by dev_dull »

> Semantic is a singular project and we often find ourselves at the edges of modern computer science research.

This is exactly where I DONT’T want to be when creating production software. If that’s thrilling to you then by all means. As for me, I like my software boring.

Re: Why GitHub used Haskell for Semantic

#48

Post by baroffoos »

simplecomplex wrote: post #29
_bxg1 wrote: 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…

Very few programmers are proficient in Haskell, and operating systems and language tooling are built around imperative C-style semantics. Combine that with the fact that most of the software industry does not care about correctness or stable software and generally lacks professionalism. "Just ship this half-assed software as soon as possible" is the attitude at the majority of software companies.

Honestly this is true. Most of the world doesn't give a shit if a page on their web store is broken. They get an exception email and then fix it, no real loss. While switching over to haskell may make your software more stable, at the end of the day the amount of extra time spent writing it in a more stable language is going to cost the business a lot more than a slightly buggy website will.

Re: Why GitHub used Haskell for Semantic

#49

Post by harry8 »

theli0nheart wrote: post #14
StavrosK wrote: post #11

Earlier quoted context omitted.

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

I have no idea if what you're saying is generally true, but I can say with certainty that no one would ever say "the police is corrupt" in American English.

The police force are corrupt vs the police force is corrupt.

Re: Why GitHub used Haskell for Semantic

#50

Post by dev_dull »

_bxg1 wrote: 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…

> even getting it to parse some complex data coming from a JSON feed into a usable form requires a good understanding of the type system.

This is a good litmus test for the usability of a language. There’s no reason parsing json should be difficult.

Post reply on HN