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

201–210 of 214 posts

Re: Why GitHub used Haskell for Semantic

#201

Post by Ixiaus »

_bxg1 wrote: post #34
Ixiaus wrote: post #27

Earlier quoted context omitted.

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

Have you used it for anything interactive? All of the above seem to me like natural fits for a pure functional style

I think you mean, by interactive, something with a user interface like a gui. First, see functional reactive programming.

The only project I used it for that was interactive in that sense was an interactive CLI tool. However Oskar Wikstrom wrote a screen cast editing tool so he could make his Haskell screen casts.

I don't think functional style prohibits interactivity (see: purescript which is strongly influenced by Haskell, we use it for all frontend web work now).

Re: Why GitHub used Haskell for Semantic

#202

Post by hardwaresofton »

weavie wrote: post #197
hardwaresofton wrote: post #176

Earlier quoted context omitted.

I hear you! I was going to try and get the CountMin post done this weekend and update this but I guess I gotta let it roll with what I have already done: One of my better Haskell posts is a series on writing REST APIs. It kind of gets off the rails type wise as I try to get more and more clever, but I rein it in: https://vadosware.io/post/rest-ish-services-in-haskell-part-...

Nice, I will have a read. I think you need to get rid of the margin-left and margin-right styles on '.article-content pre' for '@media screen and (min-width: 989px)'. It pushes the code off the bounds of the page on my screen.

Thanks so much, I will get that fixed this weekend!

Re: Why GitHub used Haskell for Semantic

#203

Post by mwcampbell »

lmm wrote: post #196
mwcampbell wrote: post #194

Earlier quoted context omitted.

Can you please explain further why std::variant is not a true sum type?

If you form a variant with multiple copies of the same type they will "collapse". E.g. std::variant behaves like std::variant .

Why would you want to list int more than once in a variant? I must be missing a use case here; my variants have consisted mostly of structs.

Re: Why GitHub used Haskell for Semantic

#204

Post by Ixiaus »

j88439h84 wrote: post #104
Ixiaus wrote: post #27

Earlier quoted context omitted.

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?

Real-time applications and really low-level systems software (however, there are some EDSLs that enable you to write real-time applications with Haskell's type-safety guarantees that can generate C-code: Haskell's Ivory library https://ivorylang.org/ivory-introduction.html).

Cross-compilation of GHC used to be a huge pain in the ass but that's improved significantly these days, on a project a few years ago I had to choose another language/ecosystem due to that limitation but I wouldn't have to now.

Re: Why GitHub used Haskell for Semantic

#205

Post by senderista »

AnimalMuppet wrote: post #39
_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…

> 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 these cases, the FP answer is usually "recompute and replace" (generally with immutable data structures that make this efficient). It can get worse than that. My problem space has mutable state that is shared between multiple threads. FP's initial answer is "sha…

That’s a classic example of a problem that can be trivially solved with another level of indirection (reference to a reference).

Re: Why GitHub used Haskell for Semantic

#206

Post by PeterisP »

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

For me, the reason why I abandoned Haskell (for a couple years I was writing about half of third projects in it) is the complexity associated with laziness. FP and immutable data structures and monads are cool and mostly understandable once you grasp the concepts, but laziness is a double-edged sword. Laziness is cool, it enables a lot of nice things, but it makes me unable to easily reason about space complexity of any nontrivial algorithms, and that repeatedly bites me when I have to write such code.

In imperative code, space complexity is obvious and explicit, time complexity is intuitive for me, and correctness is shaky and needs to be tested.

In Haskell, correctness tends to be obvious (if there are no typos causing syntax to fail, it almost always gets the exact result I intended 100% correctly in the first try), but the space and time taken by the algorithm may be and often is surprising to me; If I make tiny modifications to the code, the execution may suddenly explode from 0.001 second to an hour because suddenly processing n entries involves creating and disposing n^2 thunks, taking all available memory and extreme amounts of time.

And despite trying a bunch to wrap my head about it, it keeps happening to me, it's just not intuitive to me - for me, eyeballing efficiency and exact time/space execution of a nontrivial Haskell function is just as hard as eyeballing whether random C code does everything correctly without a memory leak or overwriting being possible in an edge case. I also have trouble with Prolog for the same reason.

Re: Why GitHub used Haskell for Semantic

#207

Post by karmakaze »

karmakaze wrote: post #193
chas wrote: post #190

Earlier quoted context omitted.

I think it's important to be precise about how the monad abstraction and type system features interact in order to combine pure and impure code. I wrote a comment elsewhere in the thread ( https://news.ycombinator.com/item?id=20112333 ) where I conclude that while the monad abstraction is useful for making a usable interface and writing programs which are agnostic to how their state is implemented, the fundamental wo…

This is want I needed to hear. I haven't used either Clean nor Haskell other than playing with them and my introduction to Clean seemed more lightweight where there some syntax to make uniqueness seem easier than the same in Haskell. On further reading, when seeing the u:[...] syntax rather than * I can see they're really quite the same. They way the uniqueness attributes are described seems like a separate axis than…

Finally think I get monads. And I don't believe it's hard to explain or hard to understand just that almost all the explanations are bad and you have to go through so many of them to put the pieces together.

Re: Why GitHub used Haskell for Semantic

#208

Post by lmm »

mwcampbell wrote: post #203
lmm wrote: post #196

Earlier quoted context omitted.

If you form a variant with multiple copies of the same type they will "collapse". E.g. std::variant behaves like std::variant .

Why would you want to list int more than once in a variant? I must be missing a use case here; my variants have consisted mostly of structs.

It's less that you specifically want an int/int case and more that you want consistent behaviour in a generic context - you might have some logic in a template that uses variant and treats the int case specially (e.g. the int is an error code), but then you get a nasty surprise when it gets used in a case where T=int.

A common example is validation/result types, which often look like string (error message) or valid result. So e.g. you might have a username validator that returns Result and then various other user creation validation things that return e.g. Result and in the end you compose them all together to get Result. That's a very powerful style that has the advantages of exceptions (the "happy path" through the code is obvious and not obscured by all the failure handling) without their disadvantages ("magic" control flow, seemingly trivial refactors changing the behaviour). But it's less practical if you can't have Result at the base level.

Re: Why GitHub used Haskell for Semantic

#209

Post by solidsnack9000 »

yakshaving_jgt wrote: post #195
solidsnack9000 wrote: post #192

Earlier quoted context omitted.

No one is arguing that you need to be a genius to use Haskell. How does my argument come across that way?

> No one is arguing that you need to be a genius to use Haskell. I’ve come across this sentiment so many times. Haskell definitely has a reputation for being an “ivory tower” language. > How does my argument come across that way? I’m not too familiar with Zelda, but it sounded like you were saying “some people are just able to do these things that most others can’t.” If that isn’t what you were saying, then I am sorr…

I think anybody can write Haskell and anybody can play Zelda or similar characters in fighting games.

What the skill-cap / skill-floor thing is about, is how often do people bother. When the base level of skill required to play at all -- not necessarily play well -- is really high, often those characters don't get used as much. People find a character that demands less up front investment and play that character instead. It's not about ability, it's about time.

Post reply on HN