Iterators are used so frequently that they have become implicit in modern programming environments, with foreach loops replacing explicit getIterator() and next() calls in typical designs. It is therefore somewhat strange to think of iterator as a design pattern - it is so simple, common and abstracted that one hardly thinks about iterators as anything other than an implementation detail.
This got me to thinking about the nature of programming, as our tools and environments continue to evolve. I was looking at a problem recently of adding logging to a number of functions in a C# application and my mind immediately jumped to implementing the feature using a decorator, as I would if tasked with the same problem in Python. Django development has pushed the decorator pattern into the same category of common and trivial code as iterators in my mind, and yet decorators remain a far less standard programming construct across other languages and frameworks. This is not to say C# doesn't exhibit a similar relationship with other design patterns - WPF databinding has likely antiquated thinking about the observer pattern for many front end developers. Today, we stand on the shoulders of giants when starting any new application and simply need to choose the best fitting option.
As languages and frameworks continue to evolve, I look forward to seeing how this process continues. Perhaps worrying about making an application RESTful will one day seem as trivial as iterators. Wouldn't that be spiffy?