Why GitHub used Haskell for Semantic • Hacker News Board

Re: Why GitHub used Haskell for Semantic

#81

Post by brianberns » Thu, Jun 06, 2019, 3:59 AM UTC

AnimalMuppet wrote: post #39

_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…

> 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 these cases, the FP answer is usually "recompute and replace" (generally with immutable data structures that make this efficient). It can get worse than that. My problem space has mutable state that is shared between multiple threads. FP's initial answer is "sha…

You might be interested in software transactional memory: https://en.m.wikipedia.org/wiki/Software_transactional_memor.... I believe it addresses some of the issues you mentioned in a functional programming way.

Re: Why GitHub used Haskell for Semantic

#82

Post by dmix » Thu, Jun 06, 2019, 4:06 AM UTC

hollerith wrote: post #74

dmix wrote: post #19

Earlier quoted context omitted.

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…

I agree Rust is similarily difficult to learn to the point of production real-life software people use (rather than toys). But it's still very much in early-adopter territory. Even today on HN was the first stable version of a web framework that seems to be the best of the pack in Rust.

Haskell has been around for 29 years. It's really not a fair comparison.

I never said you have to learn category theory or any math with Haskell either. My learning curves I mentioned were strictly practical (mutation/effects, state, lenses, more than basic types etc).

The quality and quantity of books, tutorials, community, libraries, etc plays a big role in any languages learning curve no doubt. I believe this is something that could still be greatly improved in Haskell.

But at the same time I don't think it's surprising that Rust was able to get those all up to Haskell's level of quality in a short time. Rust also has far more analogies and similarities to what most C/C++/Go/Python/Ruby users have been exposed to which makes the initial get-a-basic-script-working far easier.

So I'm not dismissing Haskell like it's destined to unpopularity just because it's hard. The larger investment in docs, websites, libraries, and similar languages like PureScript/Elm the more popular Haskell would be.

Rust had a bunch of smart marketing-friendly people join in over the last couple of years which took it from a niche systems language into something far more mainstream. Other successful languages had similar growth patterns early on while Haskell people were comfortable with it's fringe academic position for a long period (which it seems to have grown out of finally). Haskell could still achieve a similar trajectory but adoption by early-adopter non-academic developers will be critical for that growth. Even if that must include the trendy Ruby/JS they tend to look down upon that group knows how to sell a language to the public and make it practical.

Re: Why GitHub used Haskell for Semantic

#83

Post by AnimalMuppet » Thu, Jun 06, 2019, 4:15 AM UTC

brianberns wrote: post #81

AnimalMuppet wrote: post #39

Earlier quoted context omitted.

> 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 these cases, the FP answer is usually "recompute and replace" (generally with immutable data structures that make this efficient). It can get worse than that. My problem space has mutable state that is shared between multiple threads. FP's initial answer is "sha…

You might be interested in software transactional memory: https://en.m.wikipedia.org/wiki/Software_transactional_memor... . I believe it addresses some of the issues you mentioned in a functional programming way.

Interesting!

But in my world (embedded systems), those I/O writes aren't just writes to a file or a network socket. They're writes to device hardware, which has to be in the written-to state the next time that another thread interacts with it. That is, the I/O operation has to be part of the transaction, not queued up to run after the transaction commits.

Still, this approach goes farther than I thought possible to solve the problem...

Re: Why GitHub used Haskell for Semantic

#84

Post by dllthomas » Thu, Jun 06, 2019, 4:16 AM UTC

harry8 wrote: post #70

dllthomas wrote: post #65

Earlier quoted context omitted.

Turing Completeness is an important and interesting thing. It doesn't have very much to do with fitness-for-purpose of a programming language. Of course you can write * using +. That doesn't mean using one mightn't be significantly more appropriate to the problem at hand, or that returning error codes in a product type isn't the wrong call.

This is a discussion of the phrase "such a feature would be entirely impossible" You're now explaining to me in response to my previous post that some languages are a better fit in certain dimensions to perform a data transform? I think this is a discussion that needs to end now.

I'd been addressing the snarky finishing line. The feature that was called "entirely impossible" was resumable exceptions. The difficulties are practical not theoretical, but it's not the difference between (r, err) and (Either r err).

Re: Why GitHub used Haskell for Semantic

#85

Post by kartickv » Thu, Jun 06, 2019, 4:25 AM UTC

froogle wrote: post #57

kartickv wrote: post #38

Earlier quoted context omitted.

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…

> 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). I'd argue this has been happening for years and years now. If you want a pithy saying, you could say that over time languages become closer and closer to Haskell. Option…

This is a good point which I hadn't thought of, but I think there's a lot more opportunity to bring concepts from FP to mainstream languages. For example, why don't imperative languages have an immutable keyword to make a class immutable, given how error-prone it is otherwise? https://kartick-log.blogspot.com/2017/03/languages-should-le...

Re: Why GitHub used Haskell for Semantic

#86

Post by Scarbutt » Thu, Jun 06, 2019, 4:26 AM UTC

AnimalMuppet wrote: post #39

_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…

> 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 these cases, the FP answer is usually "recompute and replace" (generally with immutable data structures that make this efficient). It can get worse than that. My problem space has mutable state that is shared between multiple threads. FP's initial answer is "sha…

Clojure's atom primitive solves exactly this problem.

Re: Why GitHub used Haskell for Semantic

#87

Post by dmix » Thu, Jun 06, 2019, 4:30 AM UTC

hardwaresofton wrote: post #66

phodge wrote: post #32

> An example of this is the concept of resumable exceptions. During Semantic's interpretation passes, invalid code (unbound variables, type errors, infinite recursion) is recognized and handled based on the pass's calling context. ... Porting this to Java would require tremendous abuse of the try/catch/finally mechanism, as Java provides no way to separate control flow's policy and mechanism. And given Go's lack of e…

> One of the main reasons I don't care much about Haskell is because without any side-by-side comparisons of Haskell vs I don't understand what the Haskell advantages are, and I don't know when I'm dealing with a problem space where Haskell would help me. This is one of haskell's biggest problems. It's just enough outside of the normal flow of imperative languages (yet usable for the same problems) that you can't tel…

> Also, people who write haskell are more inclined to share lofty/abstract/interesting-to-other-haskellers code rather than your normal day-to-day code that is massively improved/safer and benefited from haskell's features.

When Rust started getting flooded with the "web" crowd of ex-Rubyists and the like there was a lot of push back from the traditional systems people (for better or worse). But one of the benefits is that these guys are typically far better at communicating and selling languages to the general developer public.

I too have run into countless examples of these "beautiful" Haskell code examples but when it came down to doing real work I felt like I was left to either figure it out myself, try to connect a more abstract blog post to more practical applications, or left reading some auto-generated Haskell/library API documentation (75% was the last one).

Maybe Github and Facebook et al can lend some of these resources to teaching Haskell to the public and releasing well-documented libraries which set a standard for others to follow? It may have a high learning curve like Rust, but it's far from impenetrable for your average developer.

Re: Why GitHub used Haskell for Semantic

#88

Post by dmix » Thu, Jun 06, 2019, 4:38 AM UTC

almostdeadguy wrote: post #56

quickthrower2 wrote: post #41

Earlier quoted context omitted.

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 bei…

> 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 started using haskell at my last job after having done a couple years of functional programming in scala, but I honestly never found it required that much knowledge of categ…

+1 everything you said.

Do you think it would be dramatically improved if Haskell had a bigger community of people contributing user-friendly libraries and tutorials? That was something that made Ruby the perfect newbie language for me. And something I feel is downplayed in Haskell given it's more advanced user base who is a little too obsessed with it's power and demonstrating their knowledge as such, rather than help make it accessible to others.

I can't count the amount of times I came across a popular Haskell library with very little documentation rather than it's type/function API and general blurb about what it does. This is very different that most popular JS/Ruby/Python/etc libraries which include quick-start/getting started/usage examples/etc etc.

Re: Why GitHub used Haskell for Semantic

#89

Post by saghm » Thu, Jun 06, 2019, 4:45 AM UTC

nullwasamistake wrote: post #68

I don't understand why they didn't use Java with ANTLR. It can also generate parsers in many other languages, but Java version supports more advanced stuff. There's already parsing support for many languages, and the parser itself is world-class. It's used internally by tons of systems. https://en.m.wikipedia.org/wiki/ANTLR#Projects I mean, I guess Haskell is cool, but their critism of Java sounds like more of a desi…

> I don't mean to be dismissive, but when your plans are to open source something corporate sponsored, you should do it in a way that benefits the community significantly

This is a super weird objection to me; is your argument that open sourcing something that might not be useful to others is worse than just keeping it closed-source? Even if literally nobody else ever gets any use from this, I don't see why it's harmful for it to be open sourced. More generally, I feel like companies releasing everything that they don't have a strong business reason not to as open source is strictly positive.

Re: Why GitHub used Haskell for Semantic

#90

Post by mlazos » Thu, Jun 06, 2019, 4:49 AM UTC

The control flow section perplexed me a bit, just because you can embed a DSL in Haskell with monads doesn’t mean that “control flow isn’t embedded in the language”. You still have a main entry point and all functions are executed top to bottom albeit with lazy semantics. You could write a DSL and interpret it with C# with all of the properties they want. Haskell is better for this sort of task but their reasons seemed off. Am I misunderstanding that section?