Why GitHub used Haskell for Semantic • Hacker News Board

Re: Why GitHub used Haskell for Semantic

#131

Post by yxhuvud » Thu, Jun 06, 2019, 10:23 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…

> changed what I expected from language was non-nullable types

I got the same revelation from the a lot more conventional [] looking Crystal, which don't solve it through optionals but through union types. Exposure to that kind of type safety to enforce non-nullability is really a watershed moment.

[] For values of convention that look like Ruby. Not everyone think that look is conventional enough.

Re: Why GitHub used Haskell for Semantic

#132

Post by lmm » Thu, Jun 06, 2019, 10:24 AM UTC

thrower123 wrote: post #22

garmaine wrote: post #20

Earlier quoted context omitted.

> 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). This is absolutely wrong. Sorry to be so direct, but I want to make sure other people not familiar with Haskell don’t get the wrong impression. Haskell is explicitly designed to separate purely functional and stateful code with a clear inte…

Whenever I've used Haskell, the monads infect things like a virus, similar to the way async/await metastasizes across a C# codebase. Note: I am not very good at Haskell.

That's what happens when you're working in a pervasive-mutability-by-default (or pervasive-IO-by-default) language as well - your whole codebase is full of hidden state mutations and hidden interactions with the outside world. You just don't have any idea where they're happening. You can write Haskell in the same style with monads everywhere and you're in essentially the same situation (just with more visibility into it) - but then you can actually start isolating the parts where mutation or outside interaction happen, and separating them from your core business logic. Which is the same thing you'd do in a high-quality codebase in any other language, but in Haskell you can do it in a way that's actually enforced and visible rather than just convention.

Re: Why GitHub used Haskell for Semantic

#133

Post by mbrock » Thu, Jun 06, 2019, 10:25 AM UTC

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 a bit skeptical of the difficulty ascribed to doing something like resumable conditions in a Java system.

You could have a per-thread singleton stack of handler objects. To raise a resumable condition you call a method on the stack that searches outward for an active handler to ask for a restart option and just returns it. If none is found an exception is thrown to unwind the call stack.

(Common Lisp has restartable conditions native to the language and this is essentially how it works. Conditions just don’t unwind the stack until no restart is available.)

Haskell monads can easily model other interesting control flow structures but this is basically just a syntax nicety of the do notation that lets you avoid writing nested lambdas to represent continuations. If you’re okay with heavy lambda nesting in Java you can do it all by just implementing whatever monad you like in Java—although the type system isn’t as glorious when it comes to higher-order polymorphism and inference.

Re: Why GitHub used Haskell for Semantic

#134

Post by pyrale » Thu, Jun 06, 2019, 10:31 AM UTC

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…

> Functional programming and lazy evaluation are common in Apache Spark

Spark ain't a language, it's an engine. Anyhow, you could make the point for lazy evaluation in stream libraries in many languages. It's not really comparable to having this as a first class citizen in the language, just like Guava didn't make Java7 equal to Java8.

> Non-nullable types can be found in Java (@NonNull) and in C++ (references). C++17 got std::optional type.

The reason people talk about it isn't about having non nullable types, it's about not having nullable types (or, at least, not having them as a default).

> We have languages without inheritance, like Go, Rust and so on.

I don't believe not having inheritance is a language feature. People may say that inheritance was a mistake and that languages without it are better off, but you will rarely hear about no inheritance being a feature of a language.

> Errors-as-values are pretty common as well (C++'s boost had boost::error code for a while now, and of course there is Go again)

Haskell has an error system. Errors as values are a pattern enabled by other things of the language (ADTs, functors/monads), but not having errors is not a Haskell feature. Elm would be a better example of this.

> Even monads find themselves in other languages

See above point about first-class things in a language.

Your analysys about features is misguided because languages aren't things that can be compared feature by feature. They are a coherent set of things that produce a specific dev experience. Haskell is offering a specific experience that people enjoy, and therefore, people talk about it, and some other languages tend to adopt some of the features in an attempt to reproduce the experience.

Re: Why GitHub used Haskell for Semantic

#135

Post by lmm » Thu, Jun 06, 2019, 10:31 AM UTC

_slyo wrote: post #63

simplecomplex wrote: post #29

Earlier quoted context omitted.

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.

Software engineering is all about trade-offs and making sure stakeholders are fully informed thereof. Pressure to deliver is one of the most challenging problems an engineer can face, because it stands in opposition to every ideal. Yet it's about as normal as death and taxes. Haskell sounds amazing. I would be thrilled to learn it, and I hope the ecosystem flourishes. I hope there will eventually be millions of jobs…

Haskell is useful whatever your priorities are (unless you have a really low quality requirement, like a script that fits on a single page and gets run only once). If you think of the project management triangle, switching to Haskell gets you a bonus that you can distribute between the points as you wish: you can produce higher-quality code for the same scope/cost/time, wider-scoped code at the same quality/cost/time, code at the same quality/scope/cost in less time, or so on.

IME a lot of Haskell advocates spend this windfall in a way that's poorly aligned to business requirements: we spend it all on increasing the code quality (and perhaps even overshoot, taking more time than users of another language to produce code of the same scope). But that's not an inevitability. (I would speculate that it tends to happen because most people in the software industry claim to value quality a lot more than they actually do, and a lot of Haskell programmers take them at their word).

Re: Why GitHub used Haskell for Semantic

#136

Post by lmm » Thu, Jun 06, 2019, 10:35 AM UTC

namelosw wrote: post #99

This week I need to do some crazy validation in C#. I wrote a bunch of plain imperative code. Then I thought I could use applicative validation with LinQ. I tried to wrote Maybe, Either and Validation, and wanted to extract an applicative and monadic interface. Then I found there are huge pitfalls and difficulties to do it properly. I also tried the same thing in JavaScript, while it's not a safe language, but the eq…

It sounds like you're trying to judge Haskell based on your experience of Java and C#? Don't do that. The Java/C# type systems have substantial limitations, but that's not a problem of type systems in general, it's a problem of C++-family languages specifically.

Re: Why GitHub used Haskell for Semantic

#137

Post by PaulAJ » Thu, Jun 06, 2019, 10:37 AM UTC

namelosw wrote: post #102

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 think it's hard to do just side-by-side comparison. Just imagine you just go back to 90s and convince C++ fans using Java. They are all general purpose programming languages, just with some better/different design decisions to make things safer or relatively more/less expressive. Similarly, the difficulty to explain Monad is Monad itself is pretty abstract and general. You can describe what it is, but it's hard to…

The "Monad" typeclass in Haskell is a unification of a bunch of things that are treated separately in other programming languages. By "unification" I mean the same kind of thing that physicists mean when they say that Maxwell unified light and electrical phenomena, or that Newton unified physics and astronomy.

It is this unification that makes monads so powerful; one abstraction handles sequencing, exceptions, non-determinism, parsing, IO, transactions, asynchronous state machines and tons of other stuff.

Re: Why GitHub used Haskell for Semantic

#138

Post by lmm » Thu, Jun 06, 2019, 10:37 AM UTC

mlazos wrote: post #90

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

> all functions are executed top to bottom albeit with lazy semantics.

No? There is no "top to bottom" execution, that's the whole point of the lazy semantics.

Re: Why GitHub used Haskell for Semantic

#139

Post by PaulAJ » Thu, Jun 06, 2019, 10:39 AM UTC

james_s_tayler wrote: post #114

namelosw wrote: post #102

Earlier quoted context omitted.

I think it's hard to do just side-by-side comparison. Just imagine you just go back to 90s and convince C++ fans using Java. They are all general purpose programming languages, just with some better/different design decisions to make things safer or relatively more/less expressive. Similarly, the difficulty to explain Monad is Monad itself is pretty abstract and general. You can describe what it is, but it's hard to…

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

For the non-Haskell readers, I should point out that this is just an old joke in the Haskell community. If you want it explained, see here:https://stackoverflow.com/questions/3870088/a-monad-is-just-...

Re: Why GitHub used Haskell for Semantic

#140

Post by 59nadir » Thu, Jun 06, 2019, 10:41 AM UTC

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.

> PureScript has a (much) more advanced type system but that's about it.

There's a lot in "... but that's about it.". Elm has a very low upper bound on abstraction by choice.

As an additional note: like many other communities in programming it has a very cult-like feeling to it and like others noted in these threads the mere mention that maybe this low upper bound on abstraction could be bad usually draws people a lot of fire.

In my experience most of the community in Elm is made up of people who don't really know what type classes can give you, for example, but they'll happily argue that it's too advanced or not needed. Most of that comes from parroting the popular in-community opinion instead of informing themselves.

This kind of inbred opinion is not unique to Elm: you can find it in Elixir, Clojure and pretty much every other community that relies too much on the benevolent dictator or the prominent founder/inventor paradigm.

In my opinion this is something that PureScript got right: Phil Freeman actually left the community to some extent and is not involved in the compiler anymore. He also does not flood the community with opinions that people give too much weight and so there is no cult of personality formed around him. The same cannot be said for the aforementioned languages.

I also find it interesting that a lot of these languages that rely on this paradigm have leaders that constantly complain that it's hard to run this kind of community. The reason it's so hard is because they've made themselves a benevolent dictator and they keep that status quo because presumably they like that they can sort of control opinion in the community that way as well.

I have absolutely zero sympathy for people who do that kind of thing because there is a very clear solution to it and they're just unwilling to commit to it. You can't have your cake and eat it too. If you enjoy this cult of personality you'll have to take the bad parts of it as well. I find it interesting that a lot of these people end up being babies about it as well, but I guess you have to be somewhat immature to end up in this position from the beginning.