Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding space leaks at all costs

kodimensional.dev

Post reply on HN
Print view View original

41–47 of 47 posts

Re: Avoiding space leaks at all costs

#41

Post by Brian_K_White »

mrkeen wrote: post #6
eptcyka wrote: post #4

> Fortunately, this is easily possible with Haskell. You need to enable the BangPatterns feature and use exclamations ! in front of patterns for variables where you want the evaluation to be performed eagerly. Of course, this is simple - you just enable a language extension so that the language you are referring to Haskell is no longer really Haskell. I think Haskell is a fine language, but given the amount of variou…

If our arguments can be so pedantic, then I can say: sure, Haskell is forever a research language. But that's irrelevant to me, because I use no-longer-really-Haskell.

I agree with the original critique more than this defense, but I had to upvote the perfection of the expression of the point I don't agree with.

Re: Avoiding space leaks at all costs

#42

Post by MauranKilom »

shirogane86x wrote: post #28
MauranKilom wrote: post #27

Earlier quoted context omitted.

Counterpoint: C++ expression templates have existed for a long time, and require no explicit work on the user side. They are incredibly unwieldy to write and debug though.

I am gonna be completely honest, I have never quite been able to understand expression templates properly. is it possible to use them to get hassle-free laziness? is there any example of a library that does this (just to look at it and see how it's done)?

Define hassle-free. In readability of user code? Yes. In getting clean compiler errors? No.

One example would be Eigen: https://eigen.tuxfamily.org/index.php?title=Main_Page

See also their page on lazy evaluation: https://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html

Of course, C++ is powerful enough that using specific tools can make the expression template abstraction fall apart (e.g. auto), but fundamentally you can write matrix code very cleanly and get great lazy-evaluated performance.

Re: Avoiding space leaks at all costs

#43

Post by Quekid5 »

Joker_vD wrote: post #40
Quekid5 wrote: post #34

Earlier quoted context omitted.

In OCaml lazy data is fundamentally incompatible with strict data -- you have to explicitly evaluate it, e.g. when passing to a function which takes strict data. This means you end up with two disjoint 'worlds' where you need to write algorithms twice, etc. (In fact you'd have to do that for every possible variant of where exactly the laziness lies.) The ergonomics become incredibly bad, unfortunately. (Also see my l…

The same split exists in Haskell as well: Data.Text.Text vs Data.Text.Lazy.Text, etc. And in LISP IIRC lazy data are type-compatible with strict data.

Yes, it's true, and the split is also painful in Haskell. The split exists in Haskell for a choice few data structures where it truly matters for performance -- it also exists for Set/Map. (And I'd argue it is actually a bad thing from a purely language perspective, but sometimes practicality does win out, even in Haskell.)

I think it might actually have been a mistake to have the lazy variants of these data structures, esp. Text/ByteString. IME it's extremely rare to want laziness for these... and it's usually just when building output strings (where there are better solutions like Builders). Anyway, I digress...

IME the same applies to lazy Map/Set, but I'm less familiar with uses for the lazy versions of these. (IIRC they're only spine-lazy, which is rarely what you want, tho.)

> And in LISP IIRC lazy data are type-compatible with strict data.

LISP is dynamically typed -- it's trivial to do there. Also not the directionality: You can go from lazy to strict (that's just evaluation which the runtime will do for you), but you can NOT go the other way automatically. Recovering laziness from strictness is impossible.

The problem with the split happens when you have mismatching types that your compiler will shout at you for.

Re: Avoiding space leaks at all costs

#44

Post by ParetoOptimal »

eptcyka wrote: post #4

> Fortunately, this is easily possible with Haskell. You need to enable the BangPatterns feature and use exclamations ! in front of patterns for variables where you want the evaluation to be performed eagerly. Of course, this is simple - you just enable a language extension so that the language you are referring to Haskell is no longer really Haskell. I think Haskell is a fine language, but given the amount of variou…

> I think Haskell is a fine language, but given the amount of various language extensions that are needed for it to be usable in production without friction, it seems it will forever be a research language - and there is nothing wrong with that.

This isn't really a problem in the real world, only in theory.

Re: Avoiding space leaks at all costs

#45

Post by ParetoOptimal »

skywhopper wrote: post #9

I have tried and failed to comprehend Haskell for my own uses. Certainly most of the examples in this article are meaningless gibberish to my smooth, practical brain. So kudos to those who grok the underlying math and find it a useful language. That said, I am a fan of lazy evaluation in the right circumstances, and often find myself implementing lazy data structures (particularly in my Ruby programs). Ultimately, th…

> Certainly most of the examples in this article are meaningless gibberish to my smooth, practical brain

My smooth practical brain struggles in languages that aren't Haskell.

Re: Avoiding space leaks at all costs

#46

Post by ParetoOptimal »

daniel-cussen wrote: post #15
skywhopper wrote: post #9

I have tried and failed to comprehend Haskell for my own uses. Certainly most of the examples in this article are meaningless gibberish to my smooth, practical brain. So kudos to those who grok the underlying math and find it a useful language. That said, I am a fan of lazy evaluation in the right circumstances, and often find myself implementing lazy data structures (particularly in my Ruby programs). Ultimately, th…

I've never heard of or met a circumstance that actually warranted Haskell. Not even in finance, those guys are totally wasting their time. It's an attractive (I'm going to say "it seems" though you ought to take that for granted) intellectual rathole. Like some forms of philosophy, like many things. Thank GOD (despite being unbelieving at the time) I went with Lisp instead. And I got real speedups.

> I've never heard of or met a circumstance that actually warranted Haskell.

Sounds like you are biased to conclude it has no purpose to begin with.

Re: Avoiding space leaks at all costs

#47

Post by ParetoOptimal »

cvoss wrote: post #14
mrkeen wrote: post #7

Earlier quoted context omitted.

In all languages, sometimes you want eager evaluation and sometimes you want lazy evaluation. If things are lazy by default, you simply need to put a "!" before the term to evaluate in order to get eagerness. If things are eager by default, you need to rewrite the algorithm as a streaming algorithm.

There's no inherent reason why doing lazy evaluation in an eager-by-default language should be any harder than the reverse. I can imagine a language that is eager by default but has a '#' operator that holds expressions in unevaluated form until terms are requested.

> There's no inherent reason why doing lazy evaluation in an eager-by-default language should be any harder than the reverse.

lazy by default enables better composition and local reasoning.

https://publish.obsidian.md/paretooptimaldev/Advantages+of+l...

Post reply on HN