Comments on: Java’s Failure to be Lazy

By: Enfranchised Mind » Java and Lazy Lists: I Stand Corrected (Sort Of)

Enfranchised Mind » Java and Lazy Lists: I Stand Corrected (Sort Of) — Tue, 06 Feb 2007 17:10:34 +0000

[...] If you’re not sure what I’m babbling about, check out this post for an introduction to lazy lists in their natural environment, and this post for my railing about Java’s lack of lazy lists. You can also bookmark this on del.icio.us or check the cosmos [...]

By: Candide

Candide — Fri, 05 Jan 2007 18:14:45 +0000

To Gafter:
Right — so Java’s completely failed to be lazy, but there’s some people out there who would like to introduce things that would make it easier to be lazy. Granted. That doesn’t change the fact that it’s just fallen apart right now.

Maybe someday it’ll catch up — but my guess is that you won’t really see it until F#, Ocaml, or Haskell break their way into business. We may be lucky, and Sun may be looking at some of the quasi-functional stuff in Ruby, but I doubt that.

To BHurt:
Yeah, I’ve personally encountered that situation. I actually feel kind of bad, because some of the stuff that I treat as natural (e.g.) the people at my last contract are completely baffled by. They keep saying things like “He should have a Ph.D. for this kind of stuff.”, which is far from true — it’s pretty clear what’s going on, as long as you’re used to functional styles of development.

By: bhurt-aw

bhurt-aw — Fri, 05 Jan 2007 02:03:07 +0000

15 years or so ago, when OO was just starting to become popular, a programmer aquiantance of mine stated that he hated OO programs, because they were impossible to follow the flow of control in. This was especially the case in OO programs written in procedural languages (yes, Virginia, you can write OO programs in C, I have), where the implementation details can obscure the fundamental patterns. An experienced OO coder would immediately start recognizing the patterns- this is inheritance, that’s a virtual function, this whole structure is actually a class, specifically it’s a decorator, etc. But he didn’t know the design patterns, and thus OO programming to him was an undifferentiated mess of function pointers and unmaintainable code.

Now, there’s a point to this story, and the point is this: if the paradigm isn’t understood, the likelyhood is that the program won’t be understood either, nor appreciated. Nor maintained.

Nothing I’m describing here is actually that hard to implement in Java. OK, there are some rought edges, and implementation details will show through, but technically it’s not that hard. But ask yourself this question: if you implemented a lazily evaluated list, with lazily evaluated maps and filters etc., and then implemented Newton’s method as an infinite list- what would the average Java programmer’s response be? Remember that this design pattern in unusual for Ocaml programmers (although it’d be medium-obvious for Haskell programmers, I think).

By: Neal Gafter

Neal Gafter — Thu, 04 Jan 2007 23:11:49 +0000

Candide: the only reason that java.util.Iterator might not be thought of as a lazy list (according to BHurt) is that the map/reduce/transform (etc) operations take List instead of Iterator, and don’t operate lazily… but wait a sec, those operations don’t exist in Java yet! We’ll be adding them (I hope) along with closures. So when we add them we can ensure that they (or versions of them) operate properly on lazy data structures, returning lazy data structures in return.

Thus my original answer.

By: Candide

Candide — Wed, 03 Jan 2007 16:25:02 +0000

My brain reads those closures precisely backwards, because of the syntax of Ocaml, but that’s not something I’d expect Java developers to care about. I am surprised, though, that they didn’t pick up something like C#’s function pointer syntax — that’s a lot more concise.

That all said, it’d be kinda nice to have something like this in play.