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

151–160 of 214 posts

Re: Why GitHub used Haskell for Semantic

#151

Post by pas »

lallysingh wrote: post #62
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…

Over time, I don't think the amount of stuff you have to learn in Haskell is more than in other major languages. Haskell requires that you learn some math, and that math had some large humps to get over. But it's a small number and you're actually just learning math, which is general and useful outside of one language. In C++, I had to learn a bunch of corner cases and committee decisions. In Java it's a huge library…

The Java experience is a vast vista of beautiful sci-fi-ish landscape, elegant industry laid out according to a master design. Big enterprises linked with glowing pipes and service buses, nice portals pulsating from the radiance of alien beans. Stylish OSGi towers reach to the sky in the background. And the Mavens offer everything that is good on the mvn-central plaza.

But as you get closer, as you try to set up your own factory, you find that you need to use that thing, that nobody uses anymore, from the dark side of the moon, and to interface with that you need to venture deep into the core, and it's factories all the way down. Layers and layers of boilerplate, and inventors screaming in horror at the banality of the gaping holes in the type system that holds the huge sphere of backward compatibility on its shoulders.

And then there's no way back. You are already versed in the dark arts, you have been to the MetaSpace, your heart is no longer yours, but it's a slightly patched G1GC and you dream with the lush murmur of cybernetic trees from Shenandoah.

Re: Why GitHub used Haskell for Semantic

#152

Post by ronanyeah »

weavie wrote: post #123
ronanyeah wrote: post #58

Earlier quoted context omitted.

PureScript has a (much) more advanced type system but that's about it. The tooling and general developer experience of Elm is probably as good as programming gets in 2019. (I've also quite enjoyed Rust.) That may sound like hyperbole but the combination of elm-graphql and elm-ui is something else. I'm from a JS background and the whole React/TS/CSS-in-JS soup just seems like a bad dream now.

Elm is a language + a framework whereas Purescript is just a language. There are a number of different frameworks you can use with Purescript from copies of the Elm architecture to wrappers over React to Halogen which can be thought of as a componentized Elm with multiple update loops. Halogen is awesome, really hits the sweet spot for me.

I wrote some Purescript and would definitely recommend anyone try it for themselves.

What eventually turned me off was tooling/workflow things like no accepted code formatter, poor graphql support, too many competing ways of doing basic tasks, too many libraries that were just JS wrappers.

Also I got a vibe from functionalprogramming.slack.com that there was more interest in the latest FP whitepaper than beginner friendliness and what the realities of making an app in Purescript are like. Which is fine, but will limit the adoption of the language in the face of Typescript (Microsoft) and ReasonML (Facebook).

It's funny, Elm gets criticised as a 'DSL for building SPAs', even though that's exactly what it is, and that focus is the reason it is so productive for that task, and has the smallest asset sizes of any front end solution.

And for all practical purposes, no runtime errors.

Re: Why GitHub used Haskell for Semantic

#153

Post by namelosw »

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.

I read a StackExchange question basically asking "Why formal method is not popular?"

A typical response is "Most of softwares is not building aircrafts".

And... After googled for a while, it turns out companies building aircraft don't use formal method.

Re: Why GitHub used Haskell for Semantic

#154

Post by jrockway »

bjt wrote: post #100
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…

"return foo, err" can return 4 kinds of responses: - foo, nil - nil, error - nil, nil - foo, error What's the right behavior when the function returns both a result and an error? What's the right behavior when it returns two nils? At best, you make everybody agree to language conventions to prevent that from happening. In Haskell (or even Swift and Kotlin with their optional types) the compiler guarantees those cases…

I think you just treat an error being returned as the value being ignored, which is what 99.9% of go programs do.

As for two nils being returned, I think it's reasonable for a program to run successfully without returning a result. Search for some work to do, return a list of tasks -- if there are none, the list is empty (nil) but there was no problem checking, so there is also no error. I don't see a problem.

As for the compiler checking, try running "func f() (value, error)" like "foo := f()". It blows up. What you do with the error is up to you; all Haskell adds with the Error monad is that it short-circuits to the end of the do {} block with the error value. No different than a Java exception; all of the upsides, all of the downsides.

Regardless, I stand by my original point that if you want to handle runtime errors, Haskell doesn't really add anything over any other language. Semantic has cases that handle errors. So would the program written in any other language.

The author should have just said, "I wrote it in Haskell because I felt like it" instead of making up reasons that simply aren't true.

Re: Why GitHub used Haskell for Semantic

#155

Post by ronanyeah »

neslinesli93 wrote: post #115
comex wrote: post #53

Earlier quoted context omitted.

Despite being functional, Elm is quite minimalist when it comes to type system features. For example, functions can have generic type parameters, but there's no good way to require that the type be able to support certain operations, e.g. being printable as a string. Haskell's solution to this is "typeclasses", which are the same thing as Rust "traits" and Swift "protocols", and somewhat similar to Java "interfaces".…

I'm currently using Elm at my day job, and I agree 100% with what you are saying. Elm lacks extensibility, tooling, and documentation is not that great. The biggest pain point however is the people who run the Elm language. The design decisions they took hurt the language and the users a lot, breaking more and more with every version bump, restricting freedom and creating a walled garden that people are getting tired…

Always liked this post on Elm in production: https://www.pivotaltracker.com/blog/Elm-pivotal-tracker

Re: Why GitHub used Haskell for Semantic

#156

Post by alexanderdmitri »

mikojan wrote: post #117
james_s_tayler wrote: post #114

Earlier quoted context omitted.

>Similarly, the difficulty to explain Monad is Monad itself is pretty abstract and general. A Monad is just a Monoid in the Category of Endofunctors.

This. What's so hard to understand about that?

Would I be correct in saying you just encapsulated the monad state type `this` in an identity `that` by creating a monad transformer out of `understand`?

Re: Why GitHub used Haskell for Semantic

#157

Post by karmakaze »

chas wrote: post #97
karmakaze wrote: post #51

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.

If you want to be productive in Haskell, the Monad typeclass is an important tool to familiarize yourself with. That said, unless you are working on the internals of a few libraries, you don't really ever need to know serious category theory in order to be very productive. If you don't already have a background in abstract algebra or category theory, I think a better approach to learning these abstractions is slowly…

Thanks for this info. What I really want to know is the value prop for learning/using monads etc. The examples of IO, State, Maybe, List, STM given seem like they'd be dealt with just fine in Clean.

Re: Why GitHub used Haskell for Semantic

#158

Post by karmakaze »

merijnv wrote: post #113
karmakaze wrote: post #51

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.

> How far can you go without monads and category theory? Without monads? Not pretty far, but they're far simpler than the wide web would have you believe. Without category theory? Sky's the limit. I say this as experienced Haskell programmer occasionally dabbling in category theory for funsies. The practical impact on "how easy is it to program Haskell" of category theory is basically zero.

I didn't mean how far in Haskell without monads. I meant how far in something else like Clean that uses uniqueness typing to handle some of the same aspects where monads would be used with Haskell.

Re: Why GitHub used Haskell for Semantic

#159

Post by karmakaze »

chas wrote: post #97
karmakaze wrote: post #51

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.

If you want to be productive in Haskell, the Monad typeclass is an important tool to familiarize yourself with. That said, unless you are working on the internals of a few libraries, you don't really ever need to know serious category theory in order to be very productive. If you don't already have a background in abstract algebra or category theory, I think a better approach to learning these abstractions is slowly…

The other partial reason for not wanting to know is that I can't then unknow. Willfull ignorance it is. Can those who know say they're happy using languages on the daily without the features you miss and think in?

Re: Why GitHub used Haskell for Semantic

#160

Post by hesselink »

dev_dull wrote: post #50
_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.

It isn't, I don't understand where this comment comes from. You can derive the entire thing without writing a line of parsing code.
Post reply on HN