
Iterators? They still make these? - fogus
http://beust.com/weblog/2010/06/17/iterators-they-still-make-these/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+beust%2FOtakuRdf+%28Otaku%2C+Cedric%27s+weblog%29
======
barrkel
This post mixes up several related concepts, and then proceeds to damn all of
them by criticising only one of them.

Separate concepts:

* C++ iterators, itself made up of different concepts \- input iterators: a kind of input pipe; \- output iterators: an output pipe; \- bidirectional; \- random: not really an iterator at all; \- often requires pairs to operate over a range

* Java iterators, and the fairly closely related concept of .NET's IEnumerable, IEnumerator and associated generic types

* Sugared iteration syntax (as opposed to imperative explicit iteration syntax)

* Iterators as read-only containers

Even with Java containers, iterators are _not_ recommended as a poor-man's
collection - rather, one should derive from AbstractCollection so that you can
at least provide size() as well as the iterator itself.

But iterators as implemented in .NET, IEnumerable and IEnumerator, are more
interesting as they represent a kind of lazily-calculated monadic stream of
values, which can be filtered etc. If you condemn iterators, you're also
throwing away LINQ.

Seems to me that he primarily dislikes the explicit iteration syntax, likes
the sugared syntax, but to leap from there to condemning iterators ignores the
question as to how the sugared syntax ought to be implemented. It's not clear
that iterators aren't an excellent way to implement the sugared syntax under
the hood for at least a subset of container types, not least because of the
benefits of something like LINQ when applied to a bare-bones container that
doesn't even supply a size() operation (think: infinite lists).

C++ iterators, being a jumble of related concepts, have separate plus and
minus points. They're often too verbose and introduce too many moving pieces
when simply dealing with a collection - you have to keep track of both the
beginning and the end of your range, which is often relevant in an algorithm
implementation, but rarely in use, which is usually just an iteration over a
transformed or filtered collection.

~~~
gxti
There's definitely a significant confusion of terminology here. FTA:

> The syntax itself is unimportant (some languages use foreach, others for i
> in l, etc…), what really matters is that iterators are gone.

The final example "for i in l" is Python. Python implements this construct
precisely using iterators behind the scenes. Other languages are very similar,
but Python in particular has a contract for an iterable object and that is how
for loops work.

I think he meant to say "iterators should be invisible", not "iterators are an
evil concept" but it's hard to be sure that he isn't just very confused as to
what an iterator is in the general sense.

~~~
eperfa
That's what I wanted to note as well, that the "new" Java for loop also uses
iterators - this syntax simply hides them. And this basically kills the main
point of this article.. (But it is definitely easier on the eye)

------
RiderOfGiraffes

      Forbidden
    
      You don't have permission to access
      /weblog/2010/06/17/iterators-they-still-make-these/
      on this server.
    

21:00 BST, 20:00 Zulu.

~~~
meese_
Google cache:
[http://google.com/search?q=cache:beust.com/weblog/2010/06/17...](http://google.com/search?q=cache:beust.com/weblog/2010/06/17/iterators-
they-still-make-these/)

------
jph
The Iterator pattern he describes can become much more powerful if there's a
way to say "do this on all items in a collection where each item is
independent". This enables parallel processing.

In his example, a simple sum of item values may be even more optimizable by
using a Divide-And-Conquer approach, Map/Reduce, etc.

Depending on your system's setup, you can get significant speed increases by
using these approaches because they work well on multi-processors and multi-
cores.

------
DjDarkman
It did not make sense back then, it does not make sense now. Even the
traditional for loop is superior to iterators.

~~~
RodgerTheGreat
Can you implement a tree traversal (in-order, post-order, your pick) in a
traditional for loop without abusing the syntax?

~~~
DjDarkman
Sure you can, just list all your tree elements in an array, your iterator does
that anyway. If done correctly it's 1 line extra code only.

And btw: let's not confuse implementation with syntax.

