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

11–20 of 47 posts

Re: Avoiding space leaks at all costs

#11

Post by kzrdude »

eptcyka wrote: post #8
nequo wrote: post #5

Earlier quoted context omitted.

It is Haskell, just not Haskell2010. It is included in GHC2021. Would you say that a company that uses a subset of C++ as a policy is not using C++? Their definition of the subset is as arbitrary as another’s that uses BangPatterns.

Sure, this language feature is mainstream now. But most real-world haskell codbases vary greatly in which language extensions they've chosen to use.

Is this a C++ benefit, that the competing implementations GCC and LLVM give each other's extensions to the language more legitimacy by having a second implementation? It doesn't seem like language extensions get so much attention in C++ codebases (but maybe I'm mistaken)?

Re: Avoiding space leaks at all costs

#12

Post by kleingeld »

nequo wrote: post #5
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…

It is Haskell, just not Haskell2010. It is included in GHC2021. Would you say that a company that uses a subset of C++ as a policy is not using C++? Their definition of the subset is as arbitrary as another’s that uses BangPatterns.

I believe one could avoid BangPatterns by using seq.

Re: Avoiding space leaks at all costs

#13

Post by ufo »

Traubenfuchs wrote: post #10

> all mainstream languages have eager evaluation models That is incorrect, e.g. Java Streams (Javas built in library for functional processing of data) are lazy, which can surprise beginners. You say it's just an std lib and not a lazy programming language? Ok, the much older (but just as lazy) C# linq is directly integrated in the C# language, making the C# language both eager and lazy by default, depending on which…

Arguably Java streams aren't really lazy evaluation at the language level, because the programmer must use explicit lambdas around the lazy bits. Java itself is still eager.

Re: Avoiding space leaks at all costs

#14

Post by cvoss »

mrkeen wrote: post #7
MauranKilom wrote: post #2

Wait, the first suggested fix for "lazy evaluation consumes too much memory" is "make it eager"? I'm sure I'm missing some nuance here, but that seems backwards.

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.

Re: Avoiding space leaks at all costs

#15

Post by daniel-cussen »

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.

Re: Avoiding space leaks at all costs

#16

Post by benreesman »

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…

GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically the ones that worked out make it into a new “standard”.

It’s not really all the different from Python PEPs or Rust’s various proposals / nightly stuff.

Just about every language has some form of this.

Re: Avoiding space leaks at all costs

#17

Post by Joker_vD »

MauranKilom wrote: post #2

Wait, the first suggested fix for "lazy evaluation consumes too much memory" is "make it eager"? I'm sure I'm missing some nuance here, but that seems backwards.

Yes. Which is my main criticism of Haskell: sure, sometimes laziness is very handy, sometimes it's even indispensable... but most of the time, eager is what you want, with judicious sprinkles of explicitly lazy structures (btw, OCaml has "lazy" keyword exactly for that).

Sure, GHC goes to heroic lengths and turns as much lazy computations as it can into eager ones, but there is always a limit to what it can do on its own, and you inevitably end with the programmer having to slap strict patterns and seqs and deepseqs wherever they can reach.

Re: Avoiding space leaks at all costs

#18

Post by benreesman »

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…

Some would argue that in retrospect strict should have been the default, I sympathize with that view personally somewhat.

But every language that beats Darwin for long enough does so by iterating the stuff that can be “fixed” and developing conventions and tools for the gotchas that can’t (practically) be.

Re: Avoiding space leaks at all costs

#19

Post by UncleMeat »

benreesman wrote: post #16
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…

GHC language extensions are like C++ Technical Reports. They are a way to evolve the language without excessive red-tape on an opt-in basis, and periodically the ones that worked out make it into a new “standard”. It’s not really all the different from Python PEPs or Rust’s various proposals / nightly stuff. Just about every language has some form of this.

That's true. And when somebody says "oh you can just use GCC's special feature to make C++ tolerable" they rightly get pushback because only a portion of these features ever make it into a standard. This means that over time you end up with a codebase that is forever tied to these nonstandard features and might even end up being incompatible with major language changes. Or maybe the feature you adopted does get standardized but in a slightly different and incompatible way and now you've got a big problem on your hands.

It is good for people to have ways of playing with a language so it evolves. It is (IMO) bad to suggest the adoption of these things as a means of making a language production-ready.

Re: Avoiding space leaks at all costs

#20

Post by benreesman »

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.

Algorithmic finance might be the most ruthlessly Darwinian area of industrial software, it’s way up there certainly.

It’s also notoriously opaque, which makes it especially hard to know that so-and-so is wasting their time.

How about “I don’t like Haskell and/or OCaml because X, I recommend Lisp instead because Y” as an alternative formulation?

That one I’d be interested to read!

Post reply on HN