The Great Static vs Dynamic Language Debate

I was looking over some of the archives of Bruce Eckel a while ago and came across his Static vs Dynamic post comparing the two types of languages.

Again and again, the argument about Static vs Dynamic languages seems to devolve into an argument about finger typing: whether not declaring types is worth the loss of the safety net of compiler checking. This argument seems to originate particularly from the 'Static' camp since from their point of view, the real difference between static and dynamic languages is the lack of type declarations.

The sad thing is that the Static camp's focus on the argument that 'reducing the amount of typing is not worth the loss of compiler checking' always seems to coerce the dynamic language crowd into the argument that type declarations really aren't needed.

I think that is missing the whole point.

It's true that many claim that dynamic languages help reduce the amount of code you have to write to get a particular problem solved. However, this reduction in code is not because of the lack of type declarations. It's because more time than not, dynamic languages provide the programmer with more powerful abstraction techniques. From the point of view of the dynamic language 'weenies', the problem with Java (and its evil twin C#) isn't that you are forced to declare types. It's that the type system hinders your ability to create more powerful abstractions. Code blocks and list continuations and the like don't seem to be possible using the type system of these so-called static languages.

And, the fact is, that power doesn't simply come from dropping the static type system. As an example, Coldfusion is a dynamic language in the sense that you do not need type declarations. However, it sucks at creating abstractions. Thus, it isn't considered under the 'dynamic language' umbrella, even though, based on the 'Java crowd' definition of dynamic languages, it should be.

The sad thing about the whole argument is that the Java evangelists seem to forget an important point. Many of the more prominent Java developers made the switch to Ruby and Python based on first-hand experience. Although they 'knew' Java's compile-time type checking was too important to give up, their actual experience using these dynamic languages showed them to be much more productive outside of the restrictive shell that Java's type system enforces.

I guess my plea, although it may fall on deaf ears, is to simply try to code something significant in Python. Do a project using Ruby. And truly use it. Don't code Java in Ruby/Python. Try to leverage the power that the language provides. Try it yourself on just one project, and make a judgment call on real experience. And see for yourself how better abstraction capabilities lead to a better coding experience.

The Ills of Procrastination

Sometimes, procrastination can really suck your life out.

I'm sitting here trying to motivate myself to do SOMETHING, but no go. I have a bunch of work to do, but nothing doing... my brain is frozen.

I guess that happens to the best of us.


It's also the reason why I think working 'regular hours' can totally suck from a productivity standpoint. I typically work from home rather than the office, and on a day like this, if I were home, I'd just go and take a nap or relax in some way, and get to work later in the night. Of course, that luxury isn't available when at the office. You just can't 'do something else'.

So, instead, I sit here, and try to beat off the procrastination. Unfortunately it is beating back. And it hits much harder.

Converting Ruby to Java

I readily admit that my previous post about the lack of distinguishable efficiency between Ruby and Java was absolutely off-base. Completely.

I'm still working on that same simulation program that I described yesterday. Why? Although I designed the program using Ruby, I need to provide the source code in Java. I always knew this, my thought process was that I would try out the development process using Ruby, and then port the program to Java once I was completed. Which is what I attempted to do last night. Which was another 'eye-opening' experience.

It seems that my current lack of Java exposure has numbed me to the amount of cruft in a typical Java program. I started the port fairly straightforwardly... copy the Ruby code into a Java class, and change the various Ruby-specific keywords to their Java equivalents, and that should be it.

So, I begin to change def to public void/int/boolean, end to }, and removing the @ and : from instance variables and symbols respectively.

It was then I began to realise how much visual clutter Java forces on you. I needed to put the opening brace after every method definition. I needed to add opening and closing parentheses to all my method definitions AND function calls. And don't forget the dear old semi-colon after every line. Nope, we can't use the if/while/unless statement modifiers, so every one of those becomes a full-blown if statement block, complete with all its brace-y goodness.

Just making all the syntax changes was an experience... by the time I was done, my code was noticeably longer, and just seemed much more like code and less readable as a result.

But, the difference between Java and Ruby goes beyond syntax. So, the stage two of the conversion involved changing constructs such as blocks, array sorting, use of hashes etc to Java equivalents. And there was where the true differences between the languages surfaced. You see,he language you use does influence your coding style, by making certain things easier to do. Thus, the natural syntax of hashes make them extremely popular, as Rails can attest to. Of course, the Java equivalent is a huge pile of clunkiness that I don't even want to think about.

The end result is that after the straightforward conversion of standard syntax differences, I actually had to then rewrite logic for the Java version because of its lack of certain Ruby functionality.

That is to be expected, right? I mean, they are different languages after all. Some things will be easier in Ruby than in Java and vice versa, right?

Of course, so far, I've only come across things that are harder in Java than in Ruby. I've yet to find something that Java does better.....

Hmm....


PS. What has me particularly cranky is the fact that in converting some of the Ruby constructs to Java, I broke something, and I'm having a hard time figuring out what. And it's annoying me that I have to go through the same debugging process again in Java that I went through in Ruby....

Programming in Ruby

It's been a while since I've been here.... I know...

Work's been pretty hectic these last few months, and it continues to be so, but I've come to realise that you just have to make time for the things you want to do... because there will ALWAYS be things to do.


I did spend the last week working hard at a computer simulation program for my sister. It's a computer simulation of a networking link, which is actually not really relevant. The key point is that it was a fairly straightforward program... a school project-type thing, which is indicative of the scope. That is, it was a small and straightforward program.

Because of time constraints, and also because I wanted to increase my learning, I developed the program using Ruby... my first test run of Ruby development without Rails.

And I must say, it was an interesting experience.

First, the negative....

There is much talk in the Ruby space about how dynamic languages save you from having to deal with the boilerplate code that is common with static languages (i.e. variable declarations, interfaces et al).

That is very much true. However, what those dynamic language gurus fail to point out is that much of this boilerplate can be provided by the IDE. Granted, it is still visual clutter, but the actual typing is minimized. In fact, that was my biggest gripe with working in Ruby... the comparable lack of help from the IDE. Context sensitive hints are much less effective and focused in the dynamic space, which can actually make you slower compared to Java and its pals.

And of course, the automated refactoring support is much less robust, which means back to manual refactoring. Of course, the fact is that the amount of refactoring that needs to get done is much less, but when you do need an "Extract Method" command, you do miss it.

There is one benefit to the lack of variable type declarations that is not mentioned very often though....

Because a variable can hold anything, it makes variable naming extremely important. You can't infer anything from the variable type, so as the developer, the variable names have to contain all the relevant info... which makes you as the developer much more conscientious about choosing proper variable names to portray all the necessary information. This is especially important in function signatures.


Overall though, the experience was quite pleasant. For the most part, the language did stay out of my way and allowed me to think in the domain rather than in the language. And, the open class structure did prove to be useful as well (I monkeypatched the Symbol class to allow sorting of symbols with minimal effort).

I think those two are the more important features that make Ruby such a pleasant experience: - the well-thought-out standard API, and
- the open classes to enhance any standard class when it doesn't quite fit your needs.


All in all, I think Ruby will be a valuable addition to my toolkit... and is definitely a language worth exploring even outside of the magic that is Rails.