Boo + SharpDevelop 2.0 = production software

Recently some contract work I did involved creating an application for converting a "legacy" .txt file into several smaller .pdf files for various reasons that won't be listed here.

Due to the fact that this was going to be used by non-programmers and was a "one-shot" software application, I decided to use .NET 2.0... and Boo.

I really wanted to see how a Boo application would hold up if, instead of a quick hack, I used the normal patterns to build production ready software.

There are some glitches in SharpDevelop 2.0, but to be honest, its a really nice environment for creating and debugging Boo applications. Variables that are created in the scope of a method are given a different highlight color, then, say, assigning a value to a local class member. One annoying thing is that the version of Boo that #develop ships with doesn't support generics; I guess they haven't upgraded the Boo addin in awhile.

Boo didn't really get in my way when I was developing the application: in fact, due to the agile nature of Boo, I could write really terse code that was mostly self-documenting and easily maintained.

I say easily maintained because the client requested a modification to the application, and I was able to easily insert the new (and frighteningly different) functionality into the application codebase with ease.

One thing that I loved was using Boo's anonymous closures. A background worker thread had to frequently update the user interface. If you've used Control.Invoke before, you'll know what a major pain in the ass it is. Still, Boo reduced all the complexity to something as simple and easy to read as this:

1 self.Invoke() do:
2                 enableControls()
3                 fooBar()
4                 setupLabel(true)                

Or this:

1 processor.Finished += do:
2     self.Invoke() do:
3         chunkProgress.Close()
4 ThreadPool.QueueUserWorkItem() do:
5     Thread.Sleep(2s)
6     processor.Process()

All in all, it turned out just like a C# application would have -- except that thanks to the various syntactic niceness of Boo, development time went down and productivity went way up.

Still, Boo could be made better -- [property] is experiencing growing pains and should be made into a proper class member level macro, the generator syntax gets terrifying once you go beyond simple iterations, and the Boo parser error messages are strange, hard to read laments about tokens or whatever random crap it spews.