Example:
You want to find an element with a certain property in a list.
In a imperative language you can do:
function ...
for( ... loop over list)
if( ... current element has the property ...)
return the element
But in clojure we can do:
(first (filter has-the-property? the-list))
If 'filter' was not lazy, the performance would be absolutely terrible.
With laziness however, it is only necessary to evaluate until we reach an
element that has the property (that is, the same as in the imperative way).
A simple runnable example would be:
(first (filter #(> % 5) (range)))
;=> 6
Where (range) is of course an infinite list, so this would not even be
possible without laziness.
The point is that laziness basically makes it possible to use the functions
that operates on seq,
without really caring about how much we are evaluating.
The above example might seem like a nifty little example, that doesn't
reflect the real world.
I think it does. In fact, I think the advantages you get from laziness is
much greater than
this example shows. I often have functions where I do several
map/filter/"that stuff" on a
list, then send it to the next function(s) that also does something along
those lines.
So on and so on.
---
"Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
computation?"
Basically, yes, I think so. You could rephrase it as
"making algorithmic clarity possible, by avoiding unnecessary computation.".
"So far I haven't run into any cases where I wouldn't realize the entire
sequence, and it's always faster to do it up-front."
I think the cases where I have to realize the entire thing are much more
common than not. However, when they do
crop up, it's absolutely necessary to have laziness.
Is it always faster to do it "up-front"? Maybe. The question is: do we
really need the extra performance.
In almost all cases, I would say "not really".
The only time that I have actually needed the extra performance was in some
euler problem(s).
Otherwise, the performance have not been noticeable.
Jonathan
On Tue, Oct 23, 2012 at 8:38 PM, Brian Craft <craft.br...@gmail.com> wrote:
> I don't yet understand how laziness helps. Can anyone point me to a
> reference? I have vague memory that one of the videos addresses this (I
> remember something about "these are not iterators"), but I'm having trouble
> finding it now.
>
> I'm finding that lazy seqs are too slow for everything, so I expect I'm
> using them incorrectly. Many of the core functions return seqs, and I
> invariably end up wrapping them with (vec ...) to get any kind of
> reasonable performance. Is that what I should be doing?
>
> Is a lazy seq mostly about algorithmic clarity, and avoiding unnecessary
> computation? So far I haven't run into any cases where I wouldn't realize
> the entire sequence, and it's always faster to do it up-front.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
