Chris Donnan

Ruby.... The dynamic language debate continued

So.... I spend most of my day typing C# code for the past several years. This is of course not to mention running dev teams to 'get the job done', being a husband, dad, etc. I also spend time writing Java code, Ruby code, when I need to - C++, etc, etc - i will spare the list. That all said - there is so much debate lately regarding dynamic vs static typing.... I think that there are some missed points in these debates as I have been experiencing while writing my C# to Java converter (lets call it Hydrogue).

Many of the 'debates' regarding static vs dyamic typing seem to have left out much of what my experience tells me are key differentiators. Most of the dynamic language fans say:

"Type errors are such a small part of the error spectrum - why be burdned by type constraints???. Focus on unit tests." Sounds good - take away the 'constraints' of strong typing.

But:

1. Dynamic languages force you to know the implementation - or the type expected - how about that! This is the biggie in my mind. BREAKS ENCAPSULATION/ INFORMATION HIDING.
2. When data modeling - I WANT to know the types/ subtypes etc of aggregate objects (see 1st bullet too - I must go look around to see the 'interface' of an object/ sub-object)
3. Tools have a hard time helping
1. Refactoring support
2. Intellisense like support
4. "Duck typing is fine" - but it does NOT help me when I need to expect certain 'interfaces' will be passed into a routine. (related to bullets 1,2)

The worst of all of these has been point 1. Without knowing types of objects - I am constantly having to run around and look at routines innards to see what methods they will be calling on my objects I pass to them. If I pass an interface reference - this is effectively saying - you can call only these things on me - and I expect it. With out this notion - I need to go look inside and see what the client class will call.... thus breaking down encapsulation.

It is hopeful/ possible/ likely that a dynamic language IDE will support statement completion (Ruby Eclipse does MINIMALLY). When this happens - it will be beyond helpful. I find that even though it is 'more code' I can turn out more code in an automated fashion using IDEs that support refactoring, intellisense, AND INTELLIGENT find usages/ implementors, etc.

That all said - I LIKE Ruby. Writing Hydrogue has been fun, educational and useful. Just pouring over the C# language spec @ msdn has been worth the work as my understanding of the bowels of C# from the inside out have gotten all the more clear. The extra Ruby education has been great - and getting everyday back into Java has been great as well. I will just say that - either IDEs have to get smarter, or I do to be as productive with a dynamically typed language as I am with a strongly typed language.

My thought was, and continues to be - the right language for the right job. I am not convinced (as many others seem to be) that dynamic languages are ready to do the things that C#/ Java do (much less C++). Perhaps I will be more convinced to use Ruby for 'bigger' or 'more complex' applications eventually. I will keep working with Ruby and hopefully by the time the tools catch up - I can contribute to the community of developers that start with them...

Enough;

Chris