I witnessed yet another “dynamic vs. static” argument between a couple of developers today. The age old debate just keeps on going.
I totally understood both sides. I have been in both positions. If you look at the Rails code for example, it takes you quite awhile to grok what they are doing with tons of meta class stuff. It can be a little frustrating to open up classes that all look like “class Foo; end” and you growl “where is the functionality!”.
On the other hand, I have worked with plenty of Java codebases that have me jumping through the IDE following the class – abstract class – interface trail where it seems that a ton of code could be shortened to 1/40 the size.
Obviously, it is easy to write bad code in any language (and I have done plenty of that!).
What makes matters worst is when you have the team with the one wizard. This is the guy that builds code that bit twiddles your bytecode so much that you get exceptions when testing that send you to weird anonymous blocks that don’t actually show you what is going on. You curse as you are in static language land with a great IDE like IntelliJ yet all of the information is gone. The worst of both worlds.
On the other hand, you want to bring good practices from other lessons learned. When I write Java now I often use closure-like semantics. However, I try to think about who the users of the code are, and how they are likely to think about things. If you always give people a clean API (again, very hard) then you can do a bit more magic under the hood (until it breaks and the developers can’t debug the darn thing).
As we move to the world of the polyglot, it will be interesting to see how developers cope thinking in various paradigms in the same codebase.