jmoiron.net

On friday November 17th, I started the first of what will be 2 two week vacations in 2 months. That night, sitting at my desk in the office at 7:00, I decided to fire up monodevelop and try out the Boo Language. I had been using Banshee since fixing the support for it in my xchat irc script, and was somewhat impressed with the startup speed of mono gtk applications when compared to Python. Although I had just finally gotten a pygtk app to run in both windows and linux (unmodified! it was kind of exciting) I decided to go ahead and play around with the CLR's library a little.

One of the things I noticed immediately upon learning Perl (and of course Python) is that I was able to write programs extremely quick and with fairly few bugs even though my hand was not being held by a static type checker. As far as I know, there isn't any serious research being done as to why this is (other's have experienced it as well), but a few people smarter than myself, notably Bruce Eckel, have made some educated guesses. Eckel, an experienced Java developer who had written books on Java, said that the dynamic typing enabled rapid prototyping by getting nagging details (like types) out of your way.

Boo has a decent type inference system that allows you to skip over most type and variable declarations. This might not save much time really, but it saves two things that are extremely important: mental real estate and spatial real estate. You don't have to think about what variables you need and what types they must be. While exploring an API (which is what you do when you learn a language) this is paramount; often all you want to do is store the result of a method call and print out some information about it. If the compiler is checking that you have created the right type and knows when there's an error, why can't it just determine the type itself?

The spatial real estate is also very important. Less code is simply better in almost any scenario, the exception being when the smaller code is obfuscated or orders of magnitude more complex for small spatial gain. This argument is somewhat ignored but it's important.. when you're searching for a bug, the less you have to read the better. It's almost always faster to understand 1 line than 3, and it is always faster to understand what's going on in one section of code when everything that pertains to it is nearby.

Boo saves you these, and the semi-colons, and gives you compile time type checking and optional duck typing. The optional duck typing in boo lets you escape the type checking net, but I found myself not using it because the introspection in CLR is much less handy than the introspection in Python and since the compiler keeps track of types it's usually just as easy to insert a cast to the right type as it is to insert a cast to duck.

Without knowing .NET at all, I put down about 330 LOC in 2 days. There was some gui code in there, and there wasn't a lot of intellectual heavy lifting, but the equivalent in C++ or C# would have been far larger, and that really does matter ... really! One of the nice things about the CLR is that I'm free to use software that has been written in the radically more popular C# without really doing anything to it. The bad thing is that typically the libraries written in C# are either of low quality, restricting license, or charge a fee. The OSS Python ecosystem is actually much healthier, even for simple 25 year old networking protocols.