Also C# suffers a similar issue with what I call "unproductive Java bureaucracy", since it's basically Microsoft Java. Bureaucracy is not static typing. You can also have full dynamic dispatch and still have static typing too.
But in C# for example, if the system was not designed with dependency injection and everything being an interface it's very hard to build a test harness since you can't mock anything. Which means everything has to be tested manually. (I haven't done any C# in a long time, maybe it's not the case anymore)
So you have to create an interface and classes for every implementations for every type in the system just so I can change its type dynamically. By the time you're done with all the cruft, you forgot what you were about to code.
I'm infinitely more productive in Ruby compared to C#. But I can understand dynamic languages not being welcoming to juniors, since they can code themselves into pitfalls that will bite them later.
I wouldn't have put it like that, but I think I know what you mean. Mocks for unit testing do require that you have defined an interface to implement, which means that every class that you want to be mocked out needs to have an interface extracted. It is extra work. Overall I think the tradeoff is worth it, myself, especially if your IDE can automated extracting an interface. But it is dumb work that a smarter language/type system could avoid.
If you define the interface first, then you can simply copy-paste that into the class definition and off you go implementing it. Hardly any more work at all.
This and other libraries can supersede method modifiers.
