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

101–110 of 214 posts

Re: Why GitHub used Haskell for Semantic

#101

Post by hardwaresofton »

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…

Hey that was kind of my point -- but I think you have it in reverse, Haskell has had a lot of this stuff for a long time (as in most of them since it's inception), and it's trickling down to other languages now.

But to make some concrete counter points:

- Apache Spark is not a general purpose programing language (you're totally right about FP and lazy evaluation being important in DAG-land of course)

- "Non-nullable types can be found in Java", yeah except them being the default is the big innovation, along with the recognition of the problem, and facilitation of the worldview that recognizes the issue. Optional didn't show up until a few years ago (Java 8?), first class functions weren't a thing without subclassing till around then too, Function references, Functional interfaces, etc. I'm less familiar with C++ and it's commendable that it's adopting new things and people are moving forward, but it's basically the gold standard of footguns with type-system scopes attached (again I don't write C++ on a daily basis and haven't felt just how much better the new editions are).

- Go and Rust learned from Haskell, Rust heavily so. BTW these days I'm more and more of the opinion that Rust is the one more worth praising of the two

- What go does is kind of error as values, but it's also kind of not -- I mean a near complete lack of use of exceptions at all. The distinction is subtle, but coding to always handle the error case (because it is the result) is different from having a sometimes-present error code that you sometimes check.

- Again, you're right that Monads are everywhere -- Haskell didn't invent the concept, but it is one of the places you can go to see it actually used functionally and learn from what people are doing with it (never mind all the novel papers).

Haskell is one of the few places that all these features come together to form a coherent whole.

Re: Why GitHub used Haskell for Semantic

#102

Post by namelosw »

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 guarantee what the audience get from you. Someone says it can solve asynchronous programming issues, then someone will think it's something just for solving this kind of issues. Same as solving null pointer exceptions. After all, it's an abstract representation of sequencing computations with effectful context. But the last one is much harder to understand than the formers.

An equivalent thing is expressing the concept of the "variable" to a mathematical audience who never heard of a computer. They can definitely understand part of it, but not what you want to express.

Re: Why GitHub used Haskell for Semantic

#103

Post by willtim »

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…

Using C# as an example, foreach and IEnumerable are baked into the language as is try/catch and more recently Async/Await. These are all just library functions in Haskell and often more general (e.g. forM in Haskell works for any Monad not just IO). Because they are library functions they can be changed/customized very easily. In C#, how could foreach be made to support a different stream type, exceptions be made checked or Async/Await be made to suspend across stack frames?

For this reason, Haskell is probably closer to a general purpose language than many of the imperative systems programming languages (especially Go).

Re: Why GitHub used Haskell for Semantic

#104

Post by j88439h84 »

Ixiaus wrote: post #27
_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…

I actually think it's seeing quite a bit of adoption in industry. What I'm seeing is a class of developer that won't learn it or thinks they can't learn it, of course "to each their own", but I truly think Haskell/PureScript/Idris/Agda are onto something remarkable: making the software industry more like an engineering discipline and less of a craft (i.e. like the difference between civil engineering and carpentry).…

Very encouraging.

Could you discuss the niche exceptions you mentioned?

Re: Why GitHub used Haskell for Semantic

#105

Post by yakshaving_jgt »

solidsnack9000 wrote: post #79
_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…

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.

Re: Why GitHub used Haskell for Semantic

#106

Post by stevejb »

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…

This is an interesting perspective. I write Haskell for fun, and sometimes for profit. My first language that I wrote in professionally was Perl 5, so I definitely understand what you are saying about the dynamic types. However, in practice I have come to the opposite conclusion. When I use a dynamically typed language, I can't escape the looming fear that I am creating a mess for myself that, if I want to use for anything non-trival, I will have to clean up later. In Haskell, I find it very freeing because I can keep writing and as long as the types work out, the "mess" is contained and my play code has a much better path to maturing.

Re: Why GitHub used Haskell for Semantic

#107

Post by yakshaving_jgt »

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

Hi. I run three startups on Haskell.

One of them is VC funded. We have the stakeholders. We have the pressure to deliver.

Haskell is making this easier, not harder. We can maintain pace as the software grows because the language is generally well-principled, and the compiler keeps us in check rather than us having to rely on human discipline.

Re: Why GitHub used Haskell for Semantic

#108

Post by doctorcroc »

dmix wrote: post #28
_bxg1 wrote: post #24

Earlier quoted context omitted.

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

Honestly I've never fully given Elm enough of a run-through to say yet (ditto with OCaml). I remember 2yrs ago I was evaluating it but decided to learn React/Vue.js for professional reasons. Additionally I wasn't convinced that Elm would be an ideal long-term commitment and more of a compromise between JS, FP, FRP (functional reactive programming) and more of a framework competitor than a full-blown language. While I…

ReasonML is a much more reasonable (pun intended) approach to FP from the front-end side that doesn't appear to be as dogmatic as Elm. By making some concessions over interoperability (namely supporting raw JS and npm libraries), Reason thinks it will be easier to win existing JS devs over. Check it out - https://reasonml.github.io/

Re: Why GitHub used Haskell for Semantic

#109

Post by yakshaving_jgt »

baroffoos wrote: post #48
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.

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.

Completely false. Many “real world” businesses are shipping web apps in Haskell. Anecdotally, they take less time to write than the equivalent Rails app.

Re: Why GitHub used Haskell for Semantic

#110

Post by jinfiesto »

mbrock wrote: post #94
AnimalMuppet wrote: post #83

Earlier quoted context omitted.

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…

The Haskell philosophy is easily misunderstood. It's not really that shared mutable state is evil but that it's difficult and so should be treated seriously and explicitly. The language still supports it—quite well. GHC's green thread scheduler is top-shelf. The main author of the GHC runtime wrote an excellent O'Reilly book called "Parallel and Concurrent Programming in Haskell" (which you can read for free online).…

Was going to say exactly this. Major common misunderstanding about even Haskell. Mutable state has to eventually be a part of basically every program that does something useful. The Haskell philosophy is more about having an explicit and predictable boundary between the pure and effectful parts of your code/system.

Though you'd be surprised at how much you can do while forgoing mutable state entirely.

Post reply on HN