+972 52-548-6969
What makes Boo a great language
I really like the CLR. It is a great platform, it has a rich set of libraries, it has a lot of power and flexibility, and it was designed with multi language support in mind, which means that what you can do on the CLR vs. what you can do in your language are two different things.
It is just too bad that the default CLR language is C#. Now, that probably raised a few brows, and definitely some hackles. C# is a great language, I can hear you saying. Well, yes, sort of. If you thinks that holding the compiler’s hands is a useful thing to do. Leaving aside the ability to extend the compiler, Boo has the following to offer us:
Syntactic sugar for common programming patterns - List, hash and array literals, object initialization, string formatting and regular expression matching are all first class concepts in Boo, with direct support for all of them in a natural manner.
Automatic Variable Declaration together with Automatic type inference – the compiler takes care of things for you, instead of having to type the same thing over and over and over again. Some would say that this is bad, for them I would reply that they should try it first. It works.
Take a look at this:
def random(): return 4 # selected by dice roll, guaranteed to be random val = random()
Is there are reason that I would need to specify the type over and over again? The compiler can figure it out for itself and not bother you with it. If you want to get a compiler error, you can:
val as string = random() # will error about type mismatch
Automatic type casting – don’t make me explicitly say it, figure it out for me. I’ll have unit tests to check to cover me.
Duck typing – Boo is a strongly typed language, but you can ask the compiler to relax those constraints at certain scenarios. It makes some things much more natural, especially since you have a way to get into this infrastructure and decide what to do at runtime.
If we will take a simple example, let us look at the XmlObject and what we can do with it:
person = XmlObject(xmlDocument) print person.FirstName print person.LastName
What we just did was resolve, at runtime, that we were asked to get the value of a property called “FirstName”, and we did. This is a trivial piece of code to implement.
Just those benefits present a significant improvement in the language experience, and we haven’t even touched the extensible compiler yet.
Comments
Automatic variable declaration reminds me too much of Option Explicit-less VBScript where you mistyped a variable name and then spent ages trying to find out why the code didn't quite work as you don't get any errors. Do you any get warnings during compilation such as variable set but not referenced?
How does the duck typing work? Is it reflection-based and potentially a performance hit?
[)amien
Damien,
Yes, that is what everyone says, but it turns out to be far less of a problem in reality.
Duck typing is based on the same principals that are used on the DLR, there is a lot of caching and smarts involved in order to make sure that plain reflection is not necessary.
It feels like many of these are handled already to a slightly lesser extent with C# 3.
I've grown to love "var" (when used sensibly) but don't think I like the idea of actual automatic variable declaration.
Doesn't duck typing make the claim that Boo is statically typed a little less true? I guess the type of the variable is known statically, but expressions are resolved dynamically... it's one of those continuum jobbies rather than a straight "yes/no" answer.
Don't get me wrong - Boo is somewhere on my list of "languages I'd like to learn" but I think C# 3 has stolen some of its thunder.
Can't wait to actually start using C# 3 for production code...
Jon
I came to C# from years of scripting language coding and automatic variable declaration, so I'll just have to disagree with your assessment that it is far less of a problem in reality. I like var and I like explicit type declaration, but automatic type declaration, while it is wrist-friendly makes for harder to read code. An explicit declaration means the variable appeared at this point in the scope, rather than earlier and this is a re-assignment.
But that's my personal preference. I like explicit syntax for readability.I admit that means I really need intellisense to not go crazy trying to type everything, but I infinitely prefer it to sparse syntax languages that just mean that I have to memorize more syntax shortcuts, rather than read the code.
Jon,
var isn't really enough, not after you have gotten used to what the language can do for you when it is really trying.
duck typing is optional, and explicit. Boo is fully statically typed until you ask it to do things dynamically.
For instance:
str = "hello"
print str.ToUppert() # static call
d as duck = str
print d.ToLower() # dynamic call
So is XmlObject always a dynamic object? There's no "as duck" in your earlier sample. With the explicit duck-ness I have no problem with it :)
I can't say I find myself missing duck typing particularly often, but I can see how it would be very useful occasionally.
Personally I'm happy with var, but there we go.
Nice to see Boo has good closure support, although I personally don't like significant whitespace (so at least it's a good job that there's an alternative!)
Jon
You can ask the compiler to do something that looks like duck typing if it encounters a method that it doesn't understand.
This isn't the same as runtime duck typing.
If we take this:
xml = new XmlObject(xmlDocument);
print xml.FirstName
XmlObject implements IQuackFu, which is basically method missing.
This code translate to this code, strongly typed:
xml = new XmlObject(xmlDocument);
print xml.QuackGet("FirstName");
The implementation of QuackGet depends on you, as the interface implementor.
In this case it will be something like:
def QuackGet(string name, args as (object)):
Right - so the duck typing is always either explicit in the calling code, or by the type you're using implementing IQuackFu (or potentially similar interfaces for other duck typing elements). Broadly right?
Out of interest, are there any plans for books just on Boo at the moment?
Jon
@Ayende
What's your opinion on VB - it has "always" supported duck typing (well, since VB6 anyway, can't remember much further back than that).
Public Sub MyMethod(Object duck)
End Sub
In fact, all these features that are now suddenly so popular are just the things that allegedly made even VB.NET into a "toy language"...
/Mats
Lol, that should have been duck As Object I suppose...my VB Fu getting rusty...;-) /Mats
No, I don't think there are any books on boo out there, but there is plenty of documentation in the site, and there is this:
http://mysite.mweb.co.za/residents/sdonovan/boo-book.html
It is duck typing, sure, but it is a very limited thing.
Duck typing on its own doesn't really give you much, the ability to interfer with that is the powerful part.
I also understand that VB's duck typing is purely reflection based, making it very slow.
So ... why Boo and not Ruby?
Ruby is 'coming' in the DLR and presumably the CLR ... so what advantages does Boo have over Ruby? (the big advantage Ruby has over Boo is widespread usage)
Casey,
Ruby has a lot of the syntactic niceties, but it is a different model of a language.
You don't call methods in ruby, you send messages.
This has profound implications on the language design and implementation.
I'll play with Ruby when it is released, but so far, it feels like I can do more, and more easily, using Boo
In your example, how do I know what your random() method return? Does it return a random int, double, float, long, duck ? If I don't know the type it returns, how do I know what I can do with it?
Tundey,
random() returns a System.Int32, because that it what you ask it to return.
Tools like #Develop knows to display the signature that the compiler will take, so the intellisense angle is covered.
Comment preview