Please provide studies to the effect that the practices you consider "proven" are, indeed, effective and references to the fact that they were widely adopted before the agile movement.
Because, so far, you've drawn a line based on personal opinions -- actually, just your own personal opinion -- about what's effective and what's not, what was common practice and what was not, said everything effective was common and everything not common is unproven, and then, based on this edifice or your own single opinion, declared that the agile movement didn't improve anything.
I'm very impressed with how much you deduced from your own thoughts, which means you are probably omniscient. In that case, you'll have no trouble providing actual evidence backing your statements.
Both you and jashkenas are missing the point. The examples you are giving are also pretty easy to do in Scala.
The more complex method he is proposing (filterMap) cannot be done at all in the languages you mention, though he only uses it precisely to get the most complex kind of method that Scala collections offer. But it is also possible, and I just blogged about it here: http://dcsobral.blogspot.com/2012/01/adding-methods-to-scala....
But, no, that is not what he wants. He wants to add this method not to the collections, but to something that isn't a collection. Well, Scala can do that too -- it added all the collections methods to String and Array, didn't it?
And here comes the twist: he wants to add filterMap not by adding it directly to them, like Scala does. He wants, instead, to go _through_ that code to get at them.
With extension methods, the login would be like this:
* X adds extension methods to Y
* Z adds extension methods to X
* Therefore, Z extension methods should be available on Y
And, in fact, it is even possible to do that in Scala for many methods, but not for the particular combination he chose, and while still inferring all types.
Instead of getting bogged down in his specific example (the tree), I think it's more helpful to focus on his larger points in "On Acknowledging Problems" (the forest).
That's not the problem, it's a problem. That is, it's a problem in this discussion, but I feel it has been dealt with well. The author's main point, though, was not about the specific example. That was to illustrate his larger point, which was about the complexity that arises when rich features interact.
The issue the author mentioned has already been solved in a much more easy and efficient way, without trying to use every feature of the type system.
Now the question remains: Should a language make almost-impossible and dangerous tasks easy or hard? I certainly prefer a language like Scala, which makes easy things easy, hard things possible and dangerous things hard, instead of the other way around.
I'm sorry, but won't these two examples add the method just to arrays? The author is intentionally trying to add a single method that will work for all collections, both scala's and non-scala's, and will always return a collection of the same type as the one the method was called on. Can you show how to easily do that in a dynamic language?
Please provide studies to the effect that the practices you consider "proven" are, indeed, effective and references to the fact that they were widely adopted before the agile movement.
Because, so far, you've drawn a line based on personal opinions -- actually, just your own personal opinion -- about what's effective and what's not, what was common practice and what was not, said everything effective was common and everything not common is unproven, and then, based on this edifice or your own single opinion, declared that the agile movement didn't improve anything.
I'm very impressed with how much you deduced from your own thoughts, which means you are probably omniscient. In that case, you'll have no trouble providing actual evidence backing your statements.