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

An apologia of lazy evaluation

epicandmonicisnotiso.blogspot.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: An apologia of lazy evaluation

#21

Post by bmitc »

chriswarbo wrote: post #20
ummonk wrote: post #8

The article seems to downplay the effect that space leaks can have on correctness / reliability. If 99.9% of code you write works, but every once in a while code nondeterministically encounters space leaks, that's a bad thing for the reliability of the language as a whole. You can no longer rely on any program you write being guaranteed to execute to completion.

> If 99.9% of code you write works, but every once in a while code nondeterministically encounters space leaks, that's a bad thing for the reliability of the language as a whole. I don't know what you mean by "nondeterministic"? The behavious is occasionally hard to predict , but it's completely deterministic. Compare it to e.g. writing C in a certain style, relying on GCC to optimise it. Those optimisations might no…

I think they probably more meant something like chaotic, in that small changes to your program can have big changes in the space leak space.

Re: An apologia of lazy evaluation

#22

Post by xmcqdpt2 »

wirrbel wrote: post #6
sfvisser wrote: post #2

My biggest observation from switching from Haskell to Rust is the change in thinking in terms of program composition. In Rust you need to really make some careful design choices in your producer/library code depending on the expected use. All of them quite on the operational level and not really semantically. So many internal choices about refs/arcs/pins/mut/ownership leak out. In Haskell you don’t really do that. If…

I really wished there was a GC-ed but strictly-evaluating Haskell. A Rust-like syntax would probably help with adoption but I don't have a strong preference in that.

Scala can be quite Haskell-like and is eager evaluating by default. (It's a lot less opinionated though so you can use it to write Java like code.)

Re: An apologia of lazy evaluation

#23

Post by sfvisser »

bmitc wrote: post #19
sfvisser wrote: post #2

My biggest observation from switching from Haskell to Rust is the change in thinking in terms of program composition. In Rust you need to really make some careful design choices in your producer/library code depending on the expected use. All of them quite on the operational level and not really semantically. So many internal choices about refs/arcs/pins/mut/ownership leak out. In Haskell you don’t really do that. If…

> Like the article explains, laziness is a big part of this. I don't think the article does a good job addressing this. They have a conclusion they want to get to, but I don't see how they get there with the arguments provided. Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more…

> Lazy evaluation increases mental burden.

In some situations, definitely! In other situations, definitely not!

My experience with writing Haskell application code is that you’re thinking way less about the runtime operational aspect of your code than in any other language. The burden is much lower.

The exceptions are possibly when writing low level library code that involves a lot of IO and steaming. Or when storing a lot of data in-memory for longer periods of time.

Re: An apologia of lazy evaluation

#24

Post by amelius »

sfvisser wrote: post #2

My biggest observation from switching from Haskell to Rust is the change in thinking in terms of program composition. In Rust you need to really make some careful design choices in your producer/library code depending on the expected use. All of them quite on the operational level and not really semantically. So many internal choices about refs/arcs/pins/mut/ownership leak out. In Haskell you don’t really do that. If…

It would be great if the language allowed you to defer choices and program like in Haskell and then add constraints later and end up with the advantages of Rust. Or apply a series of correctness preserving transformations (perhaps GPT can help with that).

Re: An apologia of lazy evaluation

#26

Post by wirrbel »

bmitc wrote: post #17
wirrbel wrote: post #12

Earlier quoted context omitted.

I really like standard ML. Modules are great but type classes would be … more pragmatic?

My preference are ML dialects, but it sounds like Idris is something you should check out. It's strict by default and has type classes and dependent types.

Idris was always filed in my head as some estoric/academic/obscure thing, will have a look at it.

Re: An apologia of lazy evaluation

#27

Post by wirrbel »

xmcqdpt2 wrote: post #22
wirrbel wrote: post #6

Earlier quoted context omitted.

I really wished there was a GC-ed but strictly-evaluating Haskell. A Rust-like syntax would probably help with adoption but I don't have a strong preference in that.

Scala can be quite Haskell-like and is eager evaluating by default. (It's a lot less opinionated though so you can use it to write Java like code.)

I have worked professionally with Scala for two years and while I see its appeal of using it over plain Java, it always felt fairly alien to me and pretty complex (probably due to the Java interop and strong typing).

Re: An apologia of lazy evaluation

#28

Post by antonvs »

lispm wrote: post #16
koito17 wrote: post #4

> Lisp communities care more about syntactic extensibility than performance, etc. Huh? Are SBCL maintainers SIMDifying chunks of their CL implementation, improving static type checking and inference, improving numeric performance, and improving compiler optimizations as much as they can simply for "syntactic extensibility?" Even Clojure cares enough about performance and problems with laziness and copying to give us…

There are some Lisp communities which value syntactic extensibility more than low-level performance. For example when using FEXPRs, which are functions which have access to their source and where the function decides which arguments to evaluate. You'll find that in R, Picolisp, Standard Lisp and a few others. Most other Lisp communities have settled on always strict evaluation and compilable macros as syntactic exten…

FEXPRs haven’t been relevant in mainstream Lisp since the 1980s. See Kent Pitman’s 1980 article describing the problems with them: https://www.nhplace.com/kent/Papers/Special-Forms.htmL

The languages you mention probably use them mainly because they’re easy to implement in the language implementation, which has nothing to do with what the community values, except in a post-hoc sense when the community tries to justify to itself why it’s using such an inherently intractable feature.

Re: An apologia of lazy evaluation

#29

Post by dan-robertson »

I was surprised by the argument about the distribution of space leaks. In particular, it feels a lot like the kinds of silly arguments C/C++ people make about various safety features – that bugs are unlikely / easy to catch / only made by the inexperienced. Those arguments are silly[1] because evidence from the C/C++ programmers who try hard to write correct programs that avoid these bugs is that they cannot be totally avoided.

The existence of these kinds of space leak (and lazy evaluation in general) mean that it is hard to predict the performance characteristics of a program in advance. They mean that it can be easier to dos servers by causing them to do slow things which the programmer didn’t realise would be slow. I think that this is (at least sometimes) a safety issue that a language which cares about safety and correctness should care about.

Perhaps it is true that worries about space leaks or surprising performance are overblown. But I think that any apology for lazy evaluation in Haskell should attempt to understand and argue against the reasons that someone like SPJ would say ‘the next Haskell will be strict’. (I’m not totally sure what the reason is; maybe it’s just that lazy evaluation is unpopular)

[1] more compelling arguments can exist but they must concede points regarding safety.

Re: An apologia of lazy evaluation

#30

Post by runeks »

bmitc wrote: post #19
sfvisser wrote: post #2

My biggest observation from switching from Haskell to Rust is the change in thinking in terms of program composition. In Rust you need to really make some careful design choices in your producer/library code depending on the expected use. All of them quite on the operational level and not really semantically. So many internal choices about refs/arcs/pins/mut/ownership leak out. In Haskell you don’t really do that. If…

> Like the article explains, laziness is a big part of this. I don't think the article does a good job addressing this. They have a conclusion they want to get to, but I don't see how they get there with the arguments provided. Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more…

> Languages that are eager by default but support lazy evaluation are also not really discussed, and it's because they are the best of both worlds. Yes, lazy evaluation has its pluses, but more often than not, you don't need it.

What makes you say strictness is the right default?

I write Haskell at my day job, and I practically never experience crashes due to space leaks. And given that strictness has its own performance issues (unnecessary evaluation), it’s not clear to me that either is the “right” default.

Post reply on HN