20 April 2006

Dynamic languages are scary?

I have noticed a post on the Ruby on Rail mailing list that catched my attention today:
> I somewhat agree with you, but I recently
> realized I don't even know *why* I feel that way. Is it because
> dynamic scripting languages, by being way less chatty than something
> like Java, somehow feel more fragile? I seriously wonder.
It was about implementing financial transaction systems with Rails.

This thought catched my attention since I have been programming a lot on my free time recently with Ruby (as an attempt to prototype some ideas that I found revolutionnary for our product).

While programming, I had many times the impression that I would accidently misname a variable or a method and that my program would fail at run-time. No more compile-time safety. This is like jumping from a plane without knowing if your parachute will open at the right time. And this really made me feel uneasy.

Think about it: you program in java with Eclipse or whatever advanced IDE. Every class name or method name can be safely completed, researched, refactored,... This was a real advance for day-to-day programming. With Ruby, or Python, this is all gone. Scary, isn't it? How can you build large systems, knowing that a single mistyped name could bring the whole system down without you even knowing it right now!?

I was indeed scared! However I could also recognize that I had been able to program a quite complex infrastructure in Ruby that was doing the job! So, what are the keys to more confidence in dynamic languages?

The keys to get more confidence are interesting since they are anyway the foundation of better development practises.

TDD virtous circle

I have been practising TDD for this project, I have been checking my coverage (with rcov) all along and I have paused enough to consider refactoring each time the tests were green.

So the first key is "start the vertuous circle of using TDD". You can start using TDD, just because you're afraid to break anything, anytime. The added benefit is a Test Driven Design.

Ruby is your best refactoring friend

The second key is "use Ruby capabilities to refactor to the maximum". Ruby on Rails has really shown that "less is more" and that duplication could be avoided up to the limit. Most of this magic is done thanks to Ruby. Ruby helps factoring code well beyond what can be done with Java (without AOP and all that metadata stuff). The added benefit is a readable code, aiming at representing the domain and nothing more.

Good engineering is here to stay

The third key is "use your object and architecture skills". Whatever the language, if you design carefully your system, with encapsulation, delegation over inheritance, layers, patterns,... you should end up in a system where undesired effects can not ripple too far. The added benefit is a maintainable and evolvable system.

Fragility turned into strength

So, basically the lesson here is that Ruby (and al.) fragility practically forces you to sign for sound development practises. You get more confidence in your development and the added benefit is that you develop it faster!

No comments: