I am sorry to disagree but if you think that the iterator or visitor pattern or the state pattern or abstract factories are only bound to Java than you have a very low skills/understanding of those patterns and you really don't understand their importance and/or applicability.
I think it's a cultural thing. Other languages don't name things that seem obvious, like iterators or filters. Consider something like filepath.Walk in go; you give it a function that gets called for every file and directory in the root of your choosing. They don't call it a visitor, though, they call it a "walk function". It's just as clear, it's just as much of a design pattern, but they don't make a big deal about it.
Meanwhile, I'm sure in Java that you have to implement some class that is the visitor, which means you have to create a new file, and probably install some VisitorUtils for making file visitors easier to implement, ... that is where it's gone off the rails. (But I am perfectly willing to believe that the exact same API exists somewhere in Java too, and most people browsing directory trees don't have 13 classes to print the names of the files in a directory. But at the same time, I feel like there are pressures pushing you in that direction. That's where the complaints come from.)
> Consider something like filepath.Walk in go; you give it a function that gets called for every file and directory in the root of your choosing. They don't call it a visitor, though, they call it a "walk function".
The ironic thing is that golang doesn't have an even better construct for this kind of pattern, namely pattern matching.
The majority of design patterns only exist because of the limitations of single dispatch. Java is far from the only single dispatch object system, but his criticism is still valid.
