Tore Vestues blogs

On a quest for the silver bullet...

What makes Boo great?

About five years ago, Rodrigo Barreto de Oliveira created the programming language Boo. It is a statically typed .Net language that incorporates some very interesting features not seen in any of the mainstream .Net languages today.

What makes Boo cool?

The cool thing about Boo is its no nonsense approach. I really enjoy its focus on a clean, wrist-friendly syntax combined with expressiveness and simplicity. Boo is actually inspired by Python, and combining the best of Python with the .Net framework and statical typing is quite powerful.

Boo makes the compiler work for you. The philosophy is, if the compiler can figure it out, you shouldn't have to tell it. For instance, Boo has an automatic Type Inference. If the compiler can figure out what type a method returns or a field is, you do not have to declare it yourself. You can write

def GetCount()
 return 1

count = GetCount()

instead of

def getCount() as int
 return 1

count as int = GetCount()

It's not hard for the compiler to deduce that the getCount() method is returning an integer, so why should you have to tell it? That's wrist-friendliness for you. Mind you, as long as the compiler can figure it out, both alternatives are valid Boo code. Then it is up to you if you want to declare the types or not.

Let's look at the classic "Hello world" to demonstrate Boos expressiveness. In C# it is implemented something like this:

public class HelloWorld
{
 public static void Main(string[] args)
 {
   Console.Writeline("Hello, world!"); 
 }
}

In Boo, writing this line will do the same thing (you do not need a class or a method):

print("Hello, world!")

The Boo manifesto simply concludes, "The guys who came up with 'public static void main' were probably kidding".

Although Boo is inspired by Python, it is not just another Iron Python. It's much more than that.

What makes Boo great?

These are examples of Boo's no-nonsense approach and there are many more examples of this. I really like that the language itself is built on this philosophy. But what really makes Boo great is its compiler extensibility. This means that you can write extensions that run in the compiler when your Boo code compiles. This powerful feature enables you to actually extend the Boo language itself.

There are several ways to do this. You can write syntactic attributes. They look like regular .Net custom attributes, but they are not. You can also make new keywords either with syntactic macros or meta methods. If these techniques are not fitting your needs you can hook up to the compiler pipeline and do virtually anything you want to with the output of the compiler process.

What all these techniques have in common is that custom code is run during compilation of your Boo code, and this custom code changes the output. The compiler takes the code as input, and asks your extensions to do their magic, and then creates the output which normally is an assembly. The magic your extensions do is to basically change whatever you'd like, giving you control of the output.

The great thing about this is that compiler extensibility is an excellent tool for removing boring, repetitive boiler plate code. This enables us to increase our productivity. Let me demonstrate how:

INotifyPropertyChanged

I hate implementing the INotifyPropertyChanged interface. To implement it I have to write a lot of boiler plate code. And as we all know, boiler plate code is boring to write, it's often harder to maintain, and it bloats your otherwise elegant code. This is a problem since you need to implement the INotifyPropertyChanged interface to be able to use .Net's data binding, and I have come to realize that data binding is an extremely nice tool when used correctly.

For those of you not familiar with Data binding and INotifyPropertyChanged: Data binding is about one object wanting to know when something changes in another object. It is really an effective implementation of the observer-pattern. Often this is used when a gui-control wants to know if the object it represents changes. To do this the gui-control is databound to the object it represents. In order for the data binding to work, the observed object needs to implement the INotifyPropertyChanged interface. This is all very nice and effective, except for all the boiler plate code in the observed object.

This is basically how the observed object is supposed to implement the INotifyPropertyChanged interface in C#:

public class Customer: INotifyPropertyChanged
{
    private string firstName;
    private string lastName;

    public string FirstName
    {
        get
        {
            return firstName;
        }
        set
        {
            firstName = value;
            NotifyPropertyChanged("FirstName");
        }
    }
    public string LastName
    {
        get
        {
            return lastName;
        }
        set
        {
            lastName = value;
            NotifyPropertyChanged("LastName");
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    private void NotifyPropertyChanged(String info)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(info));
        }
    }
}

Man, this is simply too much code for just notifying when some properties change! I honestly do not believe that Microsoft is proud of this. The problem is that the language does not allow us to simplify it. Sadly this is probably the best solution within the mainstream .Net languages. Believe me, I've been looking for better ways to do this for more than a year, and I haven't found a substantially better way. But that was before I found Boo. Because Boo is different. Boo gives you possibilities where other languages and frameworks must give in.

Let's analyze the INotifyPropertyChanged-implementation. What is it that we really want to do? We want to notify when a property has changed. If we think a bit declarative, this should only be one line of code: "Notify observers when properties change". And with Boo, you can actually do that. I've implemented a syntactic attribute called "NotifyPropertyChanged", and when you tag your class with it, all the boiler plate code is added at compile time, so you no longer have to bother with the details. Look at this:

[CreateProperties,NotifyPropertyChanged]
class BooCustomer:  
    public LastName as String
    public FirstName as String

Can you believe that this code does the same as the C# code above? Well it does. I have extended the compiler with two attributes. When the code compiles, the "CreateProperties"-attribute takes all public fields and turns them into properties, and the "NotifyPropertyChanged"-attribute adds all the code for notifying about the changes. When this code hits the compiler, all the boiler plate code is added to the output, leaving your code simple, clean and elegant.

I won't go into the details here on how to create these compiler extensions, but I will say that it is a lot easier than you might fear. And as an additional goodie, you can write these extensions in any .net language you'd like.

The INotifyPropertyChanged example is just one example. I feel that repetitive boiler plate code is introduced more and more these days. The problem with this kind of code is that it's hard to remove it with our mainstream .Net languages. Boo is the perfect tool for removing this kind of code. I believe that these possibilities can substantially increase our productivity in enterprise systems. That being said, I do not see Boo as a mainstream language in the near future. This is partly due to the lack of good tool support, and that the community is still too small. Instead I see Boo as a language that will be used in some suitable layers or components in a larger application written in a mainstream .Net language.

If you'd like to look into Boo, I recommend you start at the Boo homepage.

- Tore Vestues

(This post have been migrated from my old blog, so sadly the old comments are gone)

blog comments powered by Disqus