Iterators? They still make these?(beust.com)
beust.com
Iterators? They still make these?
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
14 comments
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.
> 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.
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)
C++ iterators, being a jumble of related concepts, have separate plus and minus points.
(I can't read the original article since it's 403 at the moment.) The big concept of iterators in C++ is that they are the abstraction that connects algorithms and containers. The traits of an iterator dictate if and how an algorithm is applied to a container.
(I can't read the original article since it's 403 at the moment.) The big concept of iterators in C++ is that they are the abstraction that connects algorithms and containers. The traits of an iterator dictate if and how an algorithm is applied to a container.
This bothered me as well, I was expecting him to say that iterators were a great mechanism, but not one you should see unless you really know you need to interface with them directly.
But then, he didn't.
But then, he didn't.
Forbidden
You don't have permission to access
/weblog/2010/06/17/iterators-they-still-make-these/
on this server.
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.
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.
It did not make sense back then, it does not make sense now. Even the traditional for loop is superior to iterators.
Can you implement a tree traversal (in-order, post-order, your pick) in a traditional for loop without abusing the syntax?
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.
And btw: let's not confuse implementation with syntax.
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.