Live data from Hacker News

Dependent Haskell

serokell.io

31–40 of 92 posts

Re: Dependent Haskell

#31
post #20

Earlier quoted context omitted.

That "explainabrag" pissed me off too. I feel like that kind of thing is super typical among Haskell bloggers.

especially when "performant" means "11.5 average FPS when making a breakout game clone with 12 bricks on Android" https://www.youtube.com/watch?v=t5-dFlt7iyc ... and being happy that it then can run at 450 fps on a desktop computer with non-negligible manual optimization work https://www.youtube.com/watch?v=PXxwYYNZhU8

Experiments with running Haskell on Android using idealised FRP frameworks such as Yampa are not representative of Haskell performance in general.

Haskell allows you to write fast code, it doesn't safeguard you from writing slow code.

Re: Dependent Haskell

#32

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes. This happens to be just the right combination of features to allow us to write clean, maintainable code that also runs fast. This is an explainabrag which is also wrong: langu…

> This is an explainabrag

It's not. Maybe it seems that way because you're not familiar with the terms, so it seems like someone trying to name drop all the stuff they know? But if you are familiar with the terms, it's just informative, and serves to situate you in the space of possible language designs. It's a lambda calculus as opposed to a process calculus, polymorphic as opposed to simply typed, lazy as opposed to strict etc.

Re: Dependent Haskell

#33
post #3

I really do think Haskell is a wonderful tool, but: "Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes." In a different context, I would have interpreted that as a sarcastic parody of Haskell evangelists. Really, I feel like everyone who is going to read that article will either already know that, or will have no idea what that se…

> Really, I feel like everyone who is going to read that article will either already know that, or will have no idea what that sentence means.

Yeah, that seems to explain the reaction to it here. But I'm not sure writing things you expect your audience to understand is such a bad thing. This is probably just the wrong audience for the post.

Re: Dependent Haskell

#35

Does anybody care to explain dependent types? I’ve heard the term used in FP conversations but not sure I get it.

Most typed programming languages will allow you to form a pair of type (Integer, Integer), and reject programs which try to return something like (Integer, Float).

Dependently typed languages might allow you to declare a type (n, m) where n and m are integers, and n m.

The key step here is that this rejection is done during compilation, and so while your program is running you can be absolutely sure that n < m.

Re: Dependent Haskell

#36

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes. This happens to be just the right combination of features to allow us to write clean, maintainable code that also runs fast. This is an explainabrag which is also wrong: langu…

> This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more.

You're not the only one:

https://old.reddit.com/r/programmingcirclejerk/comments/a76b...

Re: Dependent Haskell

#37

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes. This happens to be just the right combination of features to allow us to write clean, maintainable code that also runs fast. This is an explainabrag which is also wrong: langu…

> This is an explainabrag My goal here was to show that standard Haskell boils down to a small set of features, therefore it's a simple language. Surely, "simple" does not imply "good" (Brainfuck is also simple), so I then assert that the combination of features that Haskell consists is fertile soil for writing maintainable and performant code. > languages without these features can also have "clean, maintainable cod…

> I have a hard time imagining a clean codebase in a language without some form of polymorphism, first class functions, and algebraic data types

You don't have any definition of 'clean', so maybe you mean something precise or maybe you don't, but I have seen clean codebases in all kinds of languages - C, C++, Go, Java. The language doesn't dictate whether your code is clean or not, the programmer does.

Re: Dependent Haskell

#38
post #20

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes. This happens to be just the right combination of features to allow us to write clean, maintainable code that also runs fast. This is an explainabrag which is also wrong: langu…

That "explainabrag" pissed me off too. I feel like that kind of thing is super typical among Haskell bloggers.

At first I thought it was a joke along the lines of "A monad is just a monoid in the category of endofunctors, what's the problem?", but no, it seems to be being said non-ironically.

Re: Dependent Haskell

#39

This read like a troll piece. Every line rubbed me in some wrong way until I couldn't take it any more. > Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes. This happens to be just the right combination of features to allow us to write clean, maintainable code that also runs fast. This is an explainabrag which is also wrong: langu…

If you want to engage productively, remember that people tend to say things they think are true, so look for a way to read it that makes sense rather than going out of your way to find a way to read it that makes it false. (I guess nitpicking the phrasing for a "middlebrow dismissal" is the best way to get upvotes here nowadays).

> nothing about this list implies "runs fast."

It doesn't imply it, but it enables it; read "allow" that way.

> Is a memory leak meant to be the "worst sort of bug" or a "security vulnerability?"

Maybe the one that makes sense rather than the one that doesn't make sense.

> The implication is that memory-safe languages do not have memory leaks, which is completely false.

There's no such implication, only that memory-unsafety leads to memory leaks, which is true.

> Or is Swift meant to be included in "garbage collected languages?"

Yes it is.

> No these are not the same and this is an absurdly wrong conflation.

They are the same; traditional dynamic typing is exactly unityping. That it's possible to combine dynamic typing with other things just means that alternatives are possible, not that dynamic typing is something different.

Re: Dependent Haskell

#40
post #3

I really do think Haskell is a wonderful tool, but: "Haskell, at its core, is simple: it is just a polymorphic lambda calculus with lazy evaluation plus algebraic data types and type classes." In a different context, I would have interpreted that as a sarcastic parody of Haskell evangelists. Really, I feel like everyone who is going to read that article will either already know that, or will have no idea what that se…

I was almost 100% certain it was a joke until I read the paragraph that quote is from. I want to reassure you that most Haskell evangelists (myself included) that say stuff like that usually mean it as a joke. Most people who seek to evangelize haskell do not lose sight of the fact that it's pretty daunting at first and has a relatively steep learning curve. That said, Haskell is simple, but it's simple in an unintui…

> Haskell is simple

That it might be, but it sure as hell isn't easy. Brainfuck is simple, but nobody would choose to write a real project in it.

Most programmers struggle trying to understand what a monad is. That's not easy.

The free monad is not easy.

Monad transformers are not easy.

Understanding foldable/traversable/arrows/applicate is not east.

Lens is/are not easy.

I have personally worked with dozens of programmers that would never be able to write "proper" Haskell.

Post reply on HN