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

91–100 of 214 posts

Re: Why GitHub used Haskell for Semantic

#91

Post by theamk »

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…

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

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

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)

Even monads find themselves in other languages -- using org.apache.spark.rdd.RDD is pretty close to IO monad.

I find this an unfortunate downside of many Haskell tutorials -- they often claim there are unique features that are present in Haskell only, but on the closer inspection, it turns out those features are present / can be trivially added in many other languages as well

Re: Why GitHub used Haskell for Semantic

#92

Post by chas »

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 wrote a something[0] that demonstrates Haskell programs side-by-side with a Java program for a super toy problem. It goes on to explore more complex Haskell abstractions which implement the same simple program using less approachable techniques.

It is primarily meant for helping people understand how the abstractions work, rather than make an argument for when they are good to use, but it might give you enough background to understand the discussion around Haskell abstractions.

[0] http://reduction.io/essays/rosetta-haskell.html

Re: Why GitHub used Haskell for Semantic

#93

Post by brianberns »

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…

Yeah, embedded systems isn't a domain where functional programming is going to work well. Good luck with those locks! :)

Re: Why GitHub used Haskell for Semantic

#94

Post by mbrock »

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…

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

https://simonmar.github.io/pages/pcph.html

Of course that's not to say that Haskell is optimal for your work in embedded systems!

Re: Why GitHub used Haskell for Semantic

#95

Post by kyberias »

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…

There are no tutorials that claim these features are unique to Haskell or that they cannot be added to other languages.

Re: Why GitHub used Haskell for Semantic

#96

Post by nullwasamistake »

saghm wrote: post #89
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 harm…

More if you're going to open source something that widely useful you should write it in a common language.

Otherwise the public benefit to open sourcing it is less. In this case, the project is almost as useful as binaries. It's unlikely that many will able to integrate into existing systems or even have the Haskell skills to work with it

Re: Why GitHub used Haskell for Semantic

#97

Post by chas »

karmakaze wrote: post #51
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…

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 work through the typeclassopedia[0] while solving problems the naive or clunky way and then start to use the fancy-name abstractions (e.g. Functor, Applicative) as you see how they could be useful.

On that front, the Monad typeclass is far more general and useful than just for IO and State, so if you are thinking of it as primarily a hack to deal with those, you probably won't get the hype. In addition, it's really useful to work with a large number of examples of different Monad instances (IO, State, Maybe, List, STM[1] if want to get a bit further into the deep end) instead of just staring at the methods in the typeclass and hoping it make sense. It's a pretty broad abstraction, so it will only make sense if you are familiar with what it's abstracting.

[0] https://wiki.haskell.org/Typeclassopedia

[1] http://book.realworldhaskell.org/read/software-transactional...

Re: Why GitHub used Haskell for Semantic

#98

Post by hardwaresofton »

dmix wrote: post #87
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…

> 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 of those life lessons, but projects need both types of crowds (and to be honest it's not like there's a strict separation, lots of people fit in both camps).

I think Rust is actually going to eat a ton of what could have been Haskell's lunch -- it's a great typesystem for the traditional imperative language crowd and awesome performance for the ML crowd, and a completely new paradigm of data safety that neither of those crowds had before. These days I struggle to choose Haskell, but have settled on Rust for "performance critical" things (I don't really write truly low level software so take that with a grain of salt), and Haskell for everything else.

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

Hugely agree, but I think it's gotta be a community effort. FPComplete is out there doing stuff, and there are lots of individual bloggers, but Haskell needs more people writing "pedestrian" programs. I think it's one of the main ways of contributing to a language that is often overlooked. I don't have any numbers, but learn you a haskell for great good has probably lead to thousands of new haskell devs over it's lifetime, even if the information in it is outdated (and some consider it not a good starting point).

To compound all this, haskell also has a documentation problem -- the machinery is there but it often doesn't get written, or people don't include the "getting started" use cases. Most popular libraries are workable but some others aren't, so it's intimidating until you really start to see the types as sufficient for understanding.

Small shameless plug, I try to write about haskell and am in the middle of a post where I make a CountMin data sketch right now, I'm not quite done with it but hope to have it done this weekend. I feel in that way I'm at least doing something to help the haskell community.

Re: Why GitHub used Haskell for Semantic

#99

Post by namelosw »

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 equivalent idea is quite easy to express.

The thing I found disturbing is typical static typed languages limit our expression of imagination. Every now and then I work in Java or C# project, when I tried to express some abstract I would mostly face some difficulties. When I tried to express those ideas to colleagues they mostly didn't think about those things ever.

On the other hand, the dynamic nature of JavaScript (of course Ruby and Python, etc) make things easier to express and try new ideas. I can express new ideas to dynamically typed languages programmer much easier. There's definitely "box" for programming languages which prevents people from thinking "out of the box".

A lot of people tend to think of Haskell as a Perlis language. And I think statically typed languages without a flexible design makes Anti-Perlis languages.

Re: Why GitHub used Haskell for Semantic

#100

Post by bjt »

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 cannot happen. In Go, you just hope they never happen because almost no code handles them.

I code in Go every day. But I can't defend its decision here. I'd much rather have a richer type system where the compiler can guarantee that I'll get an error or a result, but not both or neither.

Post reply on HN