Nov
13
Although I've heard of Boo before, it never came on my radar. However, recently the boojay emerged and I found myself curious enough to take a closer look.
And you know what? It's pretty neat!
There are number of features which almost instantly had me sold:
Python-like syntax. I'm a big Python fan. I value its syntax for simplicity, readability and "obviousness". Some say it's executable pseudo-code and they're right to some extent.
(One might ask why not use IronPython if I want .NET development? Read on, I'll get to that.)
Both static and duck typing. Duck typing is the way to go if you need to develop something in an exploratory mode. It also simplifies testing. On the other hand, static typing has its advantages: compiler-level error checking and optimization, to name a few. And type inference take most of static typing pain from programing.
Being a static typing language, Boo allows function overloading for different argument types. I really miss that in Python. It can be emulated, but it should be compiler's job, not programmer's.
Boo allows operator overloading as well. It's often criticized for mis-use but applied wisely can produce cleaner and more natural code. This is the single feature I miss from C++ programming.
Closures. Everybody and his brother is talking about closures now. They are so simple yet so powerful.
Macros. Yaaay! Macros on a main-stream platform! Even though they are not so easy to use as Lisp macros, they add another dimension of programming power. Simply put, you can evolve Boo into a DSL suited for the problem you're working on.
There are also other nice things like interfaces or enums which I always missed in dynamic languages.
So, what are the disadvantages?
.NET. Until recently I had an association in my mind that .NET = Microsoft & Windows. It was broken when I discovered several Linux-only C# applications. So even though Boo ties you to .NET, it does not force you to use Windows; it seems that .NET is a first-class citizen for Linux too.
Static typing. It is both a great thing and a ball and chain. Sometimes you have to jump through a lot of hoops to get your job done. I don't have much experience with Boo and I cannot tell whether its duck typing mechanism only easies the pain or makes it completely go away.
Compiled. A need to compile the code to distribute applications seems so twenty-century. Dynamic code loading is possible but not as easy as in Python or Ruby.
I've mentioned IronPython. Why I think it's better to use Boo to create .NET applications? Two reasons.
One, I'm not convinced in marrying world of two distinct languages/platforms. Python has its own libraries, idioms, habits. .Net has its own. I'd rather program in a language which was designed for a platform. If I need to create something quickly for JVM, I use Groovy, not Jython or JRuby. Groovy was designed for JVM and can take advantage of JVM's features (like overloading). Jython is a stranger, half way between Python and JVM.
Same applies to Boo and IronPython/IronRuby. There are lots of nice .NET thingies Boo can use and Iron* can't.
Don't get me wrong. I think Python is one of the best languages available at the moment. But it's a world on its own, trying to stretch it to different territories takes away its identity.
Would I use boojay when (if) it reaches a decent level of maturity and stability? I'm not sure. Boo includes some .NET-specific features that play nicely with libraries. It might be strange to use Java idioms when dealing with JARs and .NET idioms in the rest of the code. On the other hand, Boo was designed to leverage another platform. I think time will tell. Maybe boojay will mature, maybe nobody will care.
The second reason I would not want to use IronPython is an ideological one: it's controlled by Microsoft. I don't feel comfortable using tools I can't take to the direction I want. (Unless somebody pays a lot for that 
).
Whew. A lengthy entry. The last thing I'd like to say is:
Try Boo. It's worth it.
Comments
8 Comments so far
Although Boo is a fine language - and if you’re happy with it then stick to it - I have to say that I have had good experiences of programming with IronPython.
The Open Source license is genuine, and there is a community distribution called ‘FePy’.
The main thing though, is that after nearly two years of developing with IronPython it very much feels like ‘developing with Python’. We’re simply writing Python code, but have a large new set of libraries to use (the .NET framework classes).
I didn’t mean to bash IronPython. I don’t have much experience with .NET. I tried Jython and JRuby and they feel very strange to me. On the other hand, Groovy feels very natural. I’m pretty sure it’s me, not the languages.
As per the license… I’m confused. Is MS Permissive License (MS-PL) the same as MS Public License (MS-PL)? If so, it pretty much invalidates my “controlled by MS” argument.
(Mmm, IronPython in Action. Clickety-click. Put on my “to read” list)
You might be the right person to ask - how does IronPython’s performance compare to a/CPython b/C#?
Boo is an exciting language and I love it.
It’s like a static version of Python, but it takes much of the pain out with its type inference mechanism. Therefore, it feels not very different than a dynamic language, while providing excellent performance.
However, your concerns regarding Ironpython are a little bit exagerated, IMHO.
It is simply python (a really faithful implementation) + access to all the .NET libraries.
You also said “I don’t feel comfortable using tools I can’t take to the direction I want”: well, if you are looking for that kind of control, I’m afraid you will never get it, unless you create your own language and platform.
Ironpython is pretty much complete right now, and if something happens in the future, such as an evil manipulation from Microsoft, the community will just fork it (it’s open source).
As for the platform, it is controlled by Microsoft. But there’s an open source implementation (Mono).
Not enough? Well, what are your alternatives?
Java is controlled by Sun.
Anyway, why choose? Use them all at will.
If you are comfortable with (Iron)Python, you can use it, and if you ever need more performance to avoid a bottleneck, you can code an extension in Boo (much nicer than c#).
The good thing is that python and its flavors are gaining momentum and this is very good.
The Microsoft Public License is the new name for what was called the permissive license (name change required by OSI for them to approve it as an open source license).
IronPython’s performance is pretty much on a par with CPython. Some things are much faster and some things slower - certainly performance *feels* about the same as CPython if that is any kind of metric.
This means that IronPython is slower than C#, by quite a long way. Mixing IronPython and C# in the same project is generally trivially easy though.
Luis:
Well, my comments might be exaggerated. I never claimed being objective here…
I don’t think in my case choosing one language over the other is a real issue. I don’t see any .NET development coming other then toy hobby projects. I’m just a language geek and learning a language for the sake of knowing the language is a sufficient motivation.
Michael:
CPython’s performance is enough for almost everything I do. “Feeling” is a pretty good metric as far as I’m concerned.
The ambiguously named .NET is NOT a first class citizen in the FLOSS world as most distributions either don’t ship it or don’t package it and for a good reason, Mono is a legal liability.
The thing with Mono is that *some* big heads in Gnome, specially Miguel de Icaza, are pushing a lot for it and some windows developers have gotten the idea of writing Linux software in C#.
But but MS could sue Mono out of existence, or at least large enough parts of it that it would be reduced to swiss cheese.
Icaza insists this is not a real threat, that the CLI is an ECMA public standard and that if Mono infringes a patent or two they will be rewriten in no time. Particularly he insist Mono’s FAQ addresses any issue you may have and that you should ignore the man behind the curtains. The FAQ never addresses the problem, that the ECMA standard defines only the core of the CLI, which is described as “a fairly useless system” all the useable stuff is potentially MS’s game.
Ricardo: FUD
How about the documentation, i couldnt find any good reference about this language. It would be hard to learn new language with limited reference. I dont need to have msdn like reference, but at least there is one small chm file like in python or php maybe.