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

121–130 of 214 posts

Re: Why GitHub used Haskell for Semantic

#121

Post by ookdatnog »

hardwaresofton wrote: post #71
_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…

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

> - abstract data types

I suppose you meant to say "algebraic data types"? (which have been adopted by Rust and Swift, and even the C++ stdlib)

Re: Why GitHub used Haskell for Semantic

#122

Post by weavie »

hardwaresofton wrote: post #98
dmix wrote: post #87

Earlier quoted context omitted.

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

> 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 100% agree -- this is the crowd that brings the hype (for better or for worse). I guess it's another one…

> Small shameless plug,

No point plugging if you don't provide a link for us! :-)

Re: Why GitHub used Haskell for Semantic

#123

Post by weavie »

ronanyeah wrote: post #58
_bxg1 wrote: post #24

Earlier quoted context omitted.

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

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.

Re: Why GitHub used Haskell for Semantic

#124

Post by weavie »

_bxg1 wrote: post #64
jhayward wrote: post #60

Earlier quoted context omitted.

The learning curve is one thing; dealing with purity and immutability is another. But the real stumbling block (besides the tooling issues) is the effect of lazy evaluation. Lazy evaluation can make it quite difficult to reason about the time and memory resource requirements of Haskell programs, and debugging those isn't a whole lot of fun. It is do-able, and like anything, gets better with experience, but it's hard…

Does it have trap-doors for optimization like Clojure's transient data structures?

There is unsafePerformIO, but it's generally considered a really bad idea unless you really know what you are doing, and even then it is probably a bad idea. It is useful for debugging though and putting trace statements in.

Re: Why GitHub used Haskell for Semantic

#125

Post by tasuki »

yakshaving_jgt wrote: post #105
solidsnack9000 wrote: post #79

Earlier quoted context omitted.

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

I have never read a CS paper. I do not know Category Theory. I failed high school maths. I run three business on Haskell.

Nice. Tell more?

Re: Why GitHub used Haskell for Semantic

#126

Post by wizzairflyer »

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…

This guy wrote 3 really short blog posts about doing Haskelly-stuff in C++. [1, 2, 3]

They are pretty concise and [2] especially did a good job of making me understand some of the power of Haskell.

[1] https://www.syrianspock.com/functional%20programming/softwar... [2] https://www.syrianspock.com/functional%20programming/softwar... [3] https://www.syrianspock.com/functional%20programming/softwar...

Re: Why GitHub used Haskell for Semantic

#127

Post by golergka »

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…

I'm only a Haskell beginner, but I have solved similar task, with parsing that may fail, in CIS 194 course. The solution was based on applicative functors, and I really don't think that Java or other languages have anything like it.

Here's the lecture: http://www.cis.upenn.edu/~cis194/spring13/lectures/10-applic... and PDF of the assignment: http://www.cis.upenn.edu/~cis194/spring13/hw/10-applicative.... Here's my solution of it: https://github.com/golergka/cis194/blob/master/Homework11/sr...

I hope it's readable enough to illustrate the overall concept - but please bear in mind that I'm a beginner and probably have made dumb mistakes. If you have any criticism or suggestions, I would love to hear and learn from them: learning Haskell is the first time in my software engineering self-education where I wish I had regular contact with instructor or a mentor.

Re: Why GitHub used Haskell for Semantic

#128

Post by lmm »

theamk wrote: post #91
hardwaresofton wrote: post #66

Earlier quoted context omitted.

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

It's interesting that any time I read about Haskell, I realize most of the features can be found in other languages. Functional programming and lazy evaluation are common in Apache Spark ("analytics engine for large-scale data processing."). You cannot write a good pipeline if you think in terms of imperative language. Non-nullable types can be found in Java (@NonNull) and in C++ (references). C++17 got std::optional…

This is a catch-22 of asking people to explain the advantages with simple side-by-side examples. If you want an example of something truly unique to Haskell, we'd have to talk about e.g. using the cataM function in a kind-polymorphic way. But you'd have to get a certain depth into the Haskell mentality before you could understand why that's useful or valuable. So we talk about the simple examples - but lots of languages solve those simple examples with limited/ad-hoc/special-case versions of things that Haskell does with more powerful general features. https://philipnilsson.github.io/Badness10k/escaping-hell-wit... has some examples of this phenomenon.

Apache Spark could probably never have been created without using the only other mainstream language with higher-kinded types (Scala) - now that the design has been proven a lot of it has been rewritten in a verbose Java style, but I doubt the work to come up with that design could have been done while thinking solely in Java.

Working without inheritance is only practical if you have typeclass derivation. Rust and Scala approximate this with macros. I don't think any other mainstream language has that functionality at all.

Non-nullable types and errors-as-values are only practical if you have higher-kinded types. (Rust has an ad-hoc macro that works for a handful of error-as-value types, but you can't write the general monadic library functions that you'd want to work with them properly).

Haskell is not entirely unique, but it's pretty close. The only other remotely mainstream language that has the combination of higher-kinded types and typeclass derivation (ish) is Scala, and even then you'll eventually get bitten by the lack of kind polymorphism.

Re: Why GitHub used Haskell for Semantic

#129

Post by lmm »

ookdatnog wrote: post #121
hardwaresofton wrote: post #71

Earlier quoted context omitted.

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

> - abstract data types I suppose you meant to say "algebraic data types"? (which have been adopted by Rust and Swift, and even the C++ stdlib)

C++ doesn't actually have ADTs. std::variant is not a true sum type (1 + 1 + 2 = 3, so to speak).

Re: Why GitHub used Haskell for Semantic

#130

Post by lmm »

AnimalMuppet wrote: post #83
brianberns wrote: post #81

Earlier quoted context omitted.

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

> That is, the I/O operation has to be part of the transaction, not queued up to run after the transaction commits.

That's the kind of thing Haskell excels at - explicitly sequencing things that need to happen before other things, so that you can have code that does stuff in the right order without getting into the trap of "can't ever refactor this in case I change the order something runs in".

(I can't believe that threads are actually part of the problem statement unless you're doing something strictly tied to C. Concurrency or even parallelism might be a requirement, but there are other ways to achieve it than OS-level shared-memory threads)

Post reply on HN