Living in the Tech Avalanche Generation

I decided to share my experiences on the path to IronRuby so far and perhaps it might be useful to others who wish to travel that road.

Not so long ago I posted about choices in front of me regarding learning a new language. After having programmed in C# for some 7 or so years I wasn’t going to choose another statically typed language, I wanted to add a dynamic language to my arsenal and with the DLR on it’s way and a key interest and stake in the Silverlight, the choice as obvious.

After having decided to dedicate the time and effort to IronRuby, the next question was how to address the learning. Clearly picking up IronRuby as the first pit stop was going to come with some difficulties borne out of the fact that the documentation isn’t great yet and the toolset way of being close. Based on this, I decided that learning Ruby first was the best way to progress this goal for two main reasons, one it allowed me to learn in the comfort of an IDE (NetBeans) to write ‘do as you learn‘ code and also gave me a perspective on IronRuby that is not indifferent to its genealogy.

So after downloading NetBeans (Ruby Edition) and installing Ruby 1.8.6, I got my hands on the excellent free online book by Jeremy McAnally, the title of which is “Mr Neighbourly’s Humble Little Ruby Book“. This book is a nice little quick starter to get you comfortable with the absolute basics of Ruby, but needs to be followed by something with a bit more industrial strength such as Matz very own offering The Ruby Programming Language.

Once having navigated this far, I decided that it was time to pull down the IronRuby bits and start to have a play. A while back now, Hanselman and Gu both posted some early pieces on getting started with IronRuby. Most people seem intent on making XAML based applications the focus of their IronRuby attention, which in turn lead me to DLR Pad (see the image above) which provides the ability to interactively script IronRuby (and IronPython) against a statically set window that contains a XAML UI layout (interesting). From there I found my way to Ivan Porto Carerro’s blog and book on IronRuby. Ivan’s book is not yet released but is available as early access, so I decided to avail myself of it.

And if your wondering what code looks like (see below) for something that you might have been routinely doing (as I was), it doesn’t take long to knock something (trivial in this case) together to begin to get the picture, in the case of having gone down the path I described above.

require ‘mscorlib’
require ‘System.Windows.Forms,
  Version=2.0.0.0, Culture=neutral,
  PublicKeyToken=b77a5c561934e089′

begin

    #alias the forms namespace
    Windows = System::Windows::Forms
    #new up a form & set it’s text
    first_ruby_window = Windows::Form.new
    first_ruby_window.Text = “Simons first Ruby Form”
    #new up a button
    first_ruby_button = Windows::Button.new
    #subscribe to the buttons click event
    first_ruby_button.click {|sender, args| first_ruby_button.Text =
                                    “I got clicked!”}
    #add the button to the form
    first_ruby_window.Controls.Add(first_ruby_button)
    #show my new form
    first_ruby_window.ShowDialog()

end

And we get the following:

So that’s my story (to date) and perhaps it offers some help in getting you underway with your IronRuby / DLR journey.

Just a short ping to continue to push along the awareness and Greg’s earlier call to action in trying to help move forward community interest in Spec#. As Greg said, if we make some noise about how important we think this research is in allowing us to build better software then the more likely we are to get it and sooner rather than later. Please visit the original post and sign onto Greg’s list of interested parties and for good measure I will leave a few useful links here for you to check out some podcast and webcast presentations and discussions on the technology if your not yet familiar with Spec#.

Above I have included the Bumper Sticker to show your support

The Homepage

Hanselman Podcast

The Publications compressed into a single download

The MSDN Webcast

The Alt.Net presentation

I used to be a VB 4, 5, and 6 hacker back in the day and I will confess that when I first went down the .NET path I chose VB.Net as the language vehicle of learning. Shortly after developing my first .NET application I made the immediate decision to switch languages and decided to use C# as my first choice. The reasons were simple: I found the language more compact, more elegant to read and the resources for .NET in the early days seemed to far more abundant in C#.

From time to time I do choose to implement a component or two using VB.Net; this was simply to stay in touch with the language. Most recently I found this exercise a bit harder to stomach when I had to write some lambda’s in VB 9.0.

Dim dlo As DataLoadOptions = New DataLoadOptions()
dlo.LoadWith(Of Customer)(Function(c As Customer) c.Orders)
db.LoadOptions = dlo

Any more brackets and keywords and I would be ready to pick up my guitar to make a living. This code had me really thinking that I was glad to that my “checking in with VB.Net” was an occasional practice, in fact it got me to thinking that perhaps it was becoming a bit of waste of time and that the practice should be more about checking out a new language paradigm rather than another empirical statically typed language for the same platform. Enter the polyglot programmer debate. And so, the outcome is that I have made the determination that my spare “language time” will go into Ruby and F# having assigned some value to the idea that both functional and dynamic languages should be explored NOW and in some depth. Functional programming has caught my imagination quite a bit of late and I can see some real application in the document management domain where we constantly find ourselves dealing with large recursive trees of data that are immutable.