Wednesday, September 17, 2008

Boo... Worth the time?

One of my colleagues, Tore Vestues, has recently sparked an interest in Boo internally.

Boo is, for those who don't know it, just another .NET language. I like Ayendes definition:

Boo is an object oriented, statically typed language for the common language runtime with a Python inspired syntax and focused on language and compiler extensibility.

Today we had a voluntary Boo-night, which meant about 15 developers having a go at Boo for a while. Good stuff :)

First of all, I really don't know Boo (at least not yet), but there's one thing I totally dig about it - the way anything and everything can be put together at compile-time. You got code generation at compile-time, without all the runtime hazards of standard code-generation. It really just rocks compared to the everyday c#-code.

For instance you can define what a singleton is one place, then just add a [singleton]-attribute around your class to define for the compiler to compile this as a singleton. Or a better example Tore came up with: INotifyPropertyChanged. Anyone like writing that code over and over again? How sweet is it to get to write it once, and use it over and over again? I can think of lot's of examples were I keep rewriting annoying boring code, which isn't just boring to write, it provokes errors, and it makes the code much harder to read than a declarative style possibly could.

So what's the negative things then?

First of all, Boo is a separate .NET language. It will compile to IL-code, but you need to use it fully in it's own assembly. You can of course not mix and match. In other words, you won't get C#-code with Boo compile-time code-generation. Unfortunately :(

Number 1 once again. This is the biggest problem the way I see it. The language in itself seems really cool. But what's the chances for mainstream development? Will you implement part of your application in Boo, or everything? Can you justify the cost of learning up all developers on the project to the Boo way of doing things? (I don't know, so I'm really just asking questions) Is it mature enough or has proper tool-support? (not yet)

I guess most of the initial issues with Boo comes from the fact that it's just new (of sorts) - with the standard problems you have when something is new. There is not enough documention, tool-support, or followers.


But isn't many of the concepts I just mentioned possible in C# for instance? It is, to some extent. You have AOP-support through for instance PostSharp, which does it's magic after your code has compiled. Now I don't really know just how big a difference these two approaches make (Can someone please educate me?), but since it gets in after you compile, at least all your code needs to compile already - which removes the possibility for defining your own keywords for instance, like "print" or something.

In conclusion, Boo seems exciting, but I need more time to conclude properly. Is it worth the time? Might be. I know I definitely need to have a closer look.

2 comments:

Anonymous said...

Exactly. With PostSharp, your code needs to compile before. It limits the number of things we you can do, and sometimes forces to uses not-so-nice tricks.

But AOP can be implemented as a compiler extension (AspectJ does). So it is not a limitation of AOP in itself. But Microsoft compilers (unlike Eclipse ones) are not extensible, so we have to use these workarounds.

I would tip that an extensible compiler like Boo is a better solution than post-compilation. However, I don't think the solution is viable in the .NET community (Boo will never become mainstream imho).

-gael

Anonymous said...

Good points, Rune.

Boos main advantage is that it lets you control the compile process, which (unlike postsharp) means a) you can extend syntax, and b) you can extend behavior at compile time in contrast to extending it run time. For me this makes Boo extraordinary, and I believe that it will increase our productivity by removing boiler plates and trivial code.

I totally agree that the lack of users, support and tools is Boos biggest drawback, and for this reason it might never become mainstream.

If it does not become mainstream it is of course a high risk that spending time with Boo will not be "worth the time" commercially speaking. On the other side, if there is such a productivity gain in this as I believe it is, those of us that dare to spend some time on this, might also hit the jackpot. Life's a gamble, isn't it?

But a commercial success or not, learning Boo is really expanding my horizon, and that is always a good thing.


-Tore