2 ms·
> with lazy evaluation I know it has functions that are lazy, but it's not lazy as in a sense that Haskell is right? I never use it as I find it a ghastly horr
by anonzzzies 3y ago
> with lazy evaluation
I know it has functions that are lazy, but it's not lazy as in a sense that Haskell is right? I never use it as I find it a ghastly horror show (my taste, other people like it, that's fine), but I had to use it a few times and found that (also from the article) some parts are lazy, but not python as a language. Is that not correct?
> it does limit the sorts of problems the language is suited for,
Interpreted (...) is the implementation, there is no reason why it should be interpreted.
- the_af 3y agoAlmost surely the author of TFA meant "dynamic", not lazy. Nobody uses "lazy" in the sense of TFA.
- anonzzzies 3y agoThe article meant Dynamic instead of Lazy? Ah.. Well, that's terrible use of words that mean something then.
- the_af 3y agoYes and yes. It doesn't bode well for a bit of criticism when it starts by grossly misusing a technical term.
- asplake 3y agoIt’s just plain wrong. The Wikipedia link points to “lazy” in the Haskell sense. Python is not that.
- the_af 3y agoAgreed. It's so evidently wrong my guess is that the author thinks "lazy" means "dynamic", searched Wikipedia and pasted a link to the article without reading it (in which case he would have found it didn't match his understanding). It's the less insane explanation. The alternative, that the author read and understood what lazy evaluation is, but somehow still thinks Python does it this way, is too crazy to consider.
- deleted 3y ago[deleted]
- kdmccormick 3y agoYou are right, the article is wrong. It is most certainly not lazy. f(g(), h()) will always call both h and g regardless of whether f uses their results. Iteration in a sense can be "lazy", but that laziness is via data structures built on top of a strict core language. Python is not alone in having lazy iteratable data structures, but it leans into them relatively hard in its standard library. Many of us love this, as it lets for loops work elegantly over all sorts of abstractions, but I could see some folks disliking it. Still, the author does not explain this nuance, which makes me think he does not quite know what he is talking about.
- the_af 3y agoAlmost every mainstream language has a way to "lazily" (in the sense you mean) iterate over lists, so this can't be what the author was singling out. I think he's just confused.
- anonzzzies 3y agoBut that's just libraries though. A language that actually evaluates outer to inner is different. And yes, indeed confused I would say.
- epage 3y agoNot Haskell style lazy but more of declarations are just another statement that aren't evaluated until those lines are executed. This means you can have function definitions inside of ifs which can be very useful for conditional programming / meta programming. Similarly, all variable accesses happen at runtime. This makes it so you can't truly statically verify the program but that the only way to know for sure how it will behave is to run it. In an odd twist, function argument defaults are evaluated at function definition execution time rather than call-time (so half-way in laziness) so a `[]` as a default is shared between all users of that function and if you modify it you are changing a global. I heard that this led to a vulnerability within some security software.
- the_af 3y agoWhat you describe is not lazy evaluation in any accepted sense of the term. I bet you it's also not what the author meant; he was probably thinking of dynamic typing. Alternatively, maybe the author (and you) meant "interpreted language"? Lazy/strict evaluation is an orthogonal aspect.