Home > Education, General Development > BOO – The Winter Project

BOO – The Winter Project

November 13, 2007

My winter projects usually revolve learning another programming language, brushing up on some non-programming skills (architecture, graphic design, etc.), or learning a human language (which I’m partially doing by reteaching and catching back up on my Japanese).

I wanted to learn another programming language and have heard a lot of interesting discussion in the community about BOO.

Resources:

I have a minor project coming up that I’m going to use as a guinea pig for BOO—really get in and force myself to learn something rather than dinking with code snippets.

So, what’s the code look like?

Here’s a quick example from something I was playing with while in a meeting today.  It’s a quick example of a console application that creates a new generic list, adds a few items, and spits them out.  From using statements to the final squiggly bracket “}”, it’s 22 lines.

In C#:

using System;

using System.Collections.Generic;

 

namespace BooComparison

{

    class Program

    {

        static void Main(string[] args)

        {

            List<string> names = new List<string>();

            names.Add(“This”);

            names.Add(“is”);

            names.Add(“a”);

            names.Add(“test!”);

 

            foreach (string name in names)

                Console.WriteLine(name);

 

            Console.ReadKey();

        }

    }

}

In Boo, it’s a bit shorter at 15 lines since the Main method and class are not necessary.  You’ll notice the Python and slight VB.NET references and, for me, breaking the habit of the closing semi-colon.

namespace BooTutorial

 

import System

import System.Collections.Generic

 

names = List[of string]()

names.Add(“This”)

names.Add(“is”)

names.Add(“a”)

names.Add(“test!”)

     

for name as string in names:

      Console.WriteLine(name)

     

Console.ReadKey()

You’ll notice that the for each loop is a bit different and, something that threw me when I first started messing with Boo, is that it’s position sensitive.  The Console.WriteLine is part of the for each statement BECAUSE it’s indented (there are no {  } in Boo that I’ve found).

Overall, it looks interesting and should be an challenge to learn.  Will I throw my C# away and start scaring our customers with Boo?  Ehh, I doubt it; however, it’ll be an interesting tool to add into the collection.

The most annoying downfall right now?  There isn’t a plugin for Visual Studio, so I’m using the open source SharpDevelop tool.  It’s not a bad tool (actually, quite awesome for being open source and portable), but things like R# and such are missing and make me sad—I’m used to those keyboard keys.

  1. November 13, 2007 at 8:56 pm

    So is Boo based off of the .NET platform?

  2. November 13, 2007 at 9:06 pm

    Ehh, sorta. It compiles against the MSFT .NET and Mono (they prefer mono to keep with the open source theme).

    Full info from the creator at: http://boo.codehaus.org/BooManifesto.pdf

    A lot of the keywords and such are C#-esque, which helps–but I think I’d have a better learning curve if I’d learned Python first. Dunno, we’ll see.

  3. Michael
    November 13, 2007 at 11:31 pm

    I’m curious how you came to decide on learning Boo. Would your department even want you using something as obscure as Boo to develop a system they might have to support further down the road? (Admittedly, I only heard about Ruby a few months ago, so I know I’m not cutting edge.)

  4. November 14, 2007 at 6:28 am

    @Michael-

    I considered Ruby for a while and even have a VM of a Ruby/Rails environment setup that I experiment on at whim; however, I think I settled on Boo simply because it will compile to .NET and work hand-in-hand with our current environment. My organization encourages “tinkering,” which is very nice.

    As far as sanctioning the decision, there really isn’t any work aspect to that–the project that I plan to use Boo on isn’t a work project.🙂 I might, however, in a few months, look around the office for something small to mid-sized with a relatively short lifetime and use Boo for that as an experiment.

    Learning another language just helps me know what’s out there better… and allows me to draw comparisons between them when deciding what direction to go. Java/Spring, VB, C#, and, eventually with some success, Boo.

  5. November 15, 2007 at 9:19 pm

    Brush up on Visual Studio (preferably 2008) Web & Windows Setup projects. They’ll change your life once you understand them and get the whole custom actions bit. Custom actions are an obfuscated way of saying override by the way.

    I just got done with a little ditty that runs some custom actions to create / delete IIS Virtual Directories, launch applications, etc…

    While the project details are on the low, I’ve got enough conceptual information to blog about for at least 2 weeks. Speaking of which, I’ve pretty much forgot how to login to my blog. It’s been about 2 weeks since I made a post. Peace to 60+ hour work weeks I guess.

    – Will

  6. November 15, 2007 at 10:30 pm

    @Will-

    That’s one I’ll look in to; I’ve done a good deal of my current rollouts with CMD (and lately PowerShell) scripts because my 2005 experiences with some of the setup projects made me a bit sad inside. I’ll look into what 2008 has to offer.

    Yeah, you owe us details on that crazy XML builder thingy! Post up!

  7. November 15, 2007 at 11:01 pm

    @David: Funny story – Visual Studio 2003 – 2008, setup projects are the same (afaik) for what you can do with the ui. The cool stuff is when it comes to language enhancements. I’ll give you a quick taste:

    What directory is my installer running from on a client’s machine? Pretty basic right? In a console or windows app it’s as easy as DirectoryEntry.GetCurrentDirectory() (System.DirectoryServices namespace). Wow. Open and shut case right? Sike.

    This and Environment.GetCurrentDirectory, Path….. all end up with %windir%\system32. The devil is in the details; what you pass as your custom action data. You are able to access the SOURCEDIR parameter. Everything in a custom action boils down to Key-Value pairs (IDictionary). There is a gotcha though. When sending custom action data (i.e. CHECKOPENREGISTRATIONWEBSITE checkbox status would be sent in the CustomActionData property as /OpenRegistrationWebsite=[CHECKOPENREGISTRATIONWEBSITE] right?). /OpenedInThisDirectory=[SOURCEDIR] should work then right? WRONG! This will throw an exception (I can’t answer why). This works though:

    /SourceDirectory=”[SourceDir]\” I won’t even pretend to know why that works, but it does.

    Again, setup projects are like extending existing controls (your modal popup and my RequiredTextBox). Microsoft takes care of 90% of the work and we have to fill in the other 10%.

    Trust that I will post a detailed blog entry about this.

    Sorry to go off on a tangent and steal your Boo shine but I feel like I would be doing other like-minded developers a disservice by not sharing.🙂

  8. November 16, 2007 at 6:28 am

    @Will- LOL. Okay, I see the advantages of that in commercial development for external customers or huge organizations… but eeeh.. Build > Publish Web Site.

    Still something fun to look into; it’d be nice to have those to roll out on the server simply as Mack Truck measures (I set up everything and manage our web environment atm, a project that automates everything would mean that anyone could essentially roll it out in my absence).

    And tangents are good; means you’re passionate about it.🙂

  9. November 16, 2007 at 1:48 pm

    I just realized I pretty much created a post in your comments. I should just copy and paste that and publish on my blog.

    – Will

  10. November 16, 2007 at 1:51 pm

    @Will-

    LOL, indeed. See, productivity! Copy and paste and you’re done!

    …o r at least give me a chance to look at it and make a post of comments and observations and reply to that.😛 j/k

  1. No trackbacks yet.
Comments are closed.
%d bloggers like this: