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.
June 4th, 2008 at 1:25 pm
Dion, did you see Dmitry Jemerov’s interview on Artima? http://www.artima.com/lejava/articles/javaone_2008_dmitry_jemerov.html
Lots of talk about polyglot, but clearest description of the problem of massive codebases of dynamically typed code that I’ve seen yet. Yes, you can have magic metaprogramming in Java too, via byte-code injection, or stuff like GWT Generators, but the overall system still allows you to efficiently navigate a large codebase, refactor it, and find stuff in it, with ease, as well as debug it extremely well. For example, with GWT, I can step through code from the compiler (Generator) to JS (client) right on through an RPC call into a servlet, and back. I’ve got a code base right now that involves 20kloc of GWT code, plus 30+ third party libraries and another 30kloc on the server, and I regularly need to jump around through this at the touch of a button to make changes, or debug library calls.
I’ve written systems in scripting languages that exceed 50kloc, and my impression is, you start to run into a productivity and coordination issues when the size of the platform scales up. Even Google appears to recognize the problem, the goog.* libraries they released with DocType show the usage of a compiler, probably due to issues scaling up a massive Javascript code base, the need for extensive checks to maintain idiomatic code.
Much of the “pain” people complain of in static languages is the verbosity and boilerplate of Java. Not every statically typed language requires manifest types everywhere. Hindley-Milner type systems show you can get buy with very little type declarations. Scala also shows for example, that you can have your cake and eat it too. A system with excels at writing compact DSL-driven code, with a minimum of required typing. And, Scala even supports interpreted mode so you don’t need to compile.
I think too many people spend too much time fighting wars over static and dynamic typing, without recognizing that each has their place, and that the system you choose depends on your project, your aesthetic preferences, and the team you work with.
June 5th, 2008 at 11:36 am
Polyglot will come hand-in-hand with SOA. As more, smaller services are deployed and wired together, we’ll see different tools used where they make sense for each service. As always, developers will communicate across the APIs.
June 6th, 2008 at 9:17 am
The problems that developers face are so far up the stack from the language it is comical ;) that it is discussed so much. It’s called a language appropriately. These conversations are just like saying, “Japanese is better than Norwegian” and I’ll prove it. See in Japanese I can say – “雨の日大好きチキンスープ” and in Norwegian its “Jeg elsker kylling suppe på regnfull dager” 12 characters vs 44 characters, see it’s better.
Enterprises need to adopt languages that are well thought out and have a considerable community behind them so that they can gain and train new people not in the language but in the business.
As an individual developer, I tend to thing more in terms of services whether data services – Is this data coming to me in XML, JSON, CSV… and what is the best way to handle it? – or UI services – how can I build and deploy a UI service like Google Maps for my cool foobar widget and integrate it with other UI and data services.
IMO, the world has / needs way to much software to be worrying about application development to such a low level.