This post is not about creating a language zealot’s war – let me make that absolutely clear from the outset. What this post is about is a question, how does one go about making their minds up in choosing a language for developing in the dynamic world of the DLR?
For my part so far I have delved into IronRuby and started to employ it for scripting my C# applications. Why did I choose IronRuby over IronPython? It began with curiosity in the Ruby language in general and led inevitably to IronRuby. I quickly acquired a taste for Ruby but there is something nagging in the back of my mind and I can’t get to the bottom of it - “did I choose the right language” and really after all “does it matter which one I choose?”
Given Pythons relationship to C and my emotional connection to the C family of languages, would IronPython have been a better choice? Certainly IronPython is further down the track and more mature than IronRuby at this stage, but what does that count for at this early stage? All these questions make me curious for some other opinions which I would leave to hear right here, so please tell me – what do you think? What criteria would you use to make a choice?
During my journey in learning Ruby / IronRuby, I have caught myself often naming things in C# with a Ruby convention or BDD test naming regime. To be extreme here’s an example:
var customer_to_make_preferred = Get_Customer_By_Id<ICustomerMakePrefered>();
//OR METHODS LIKE THIS
public void Group_By_Orders_And_Print_To_Console_Window()
{
//…..etc
}
I really find a benefit in greater understanding when reading code when I take this approach. Now it’s true I have been programming in C# for some 10 years and I don’t know if this kind of behaviour will see me excommunicated from the circle of brethren or not but I would like to know what others think.
Opinions please! And yes I know this is gonna be like waving a red flag in front of a raging bull :). And for the Ruby people, I am only proposing the extended underscored naming convention and nothing else – it’s all about naming and that’s it – ya basta!
One of the clear value added possibilities with IronRuby and IronPython (or any DLR language) has to offer is making applications scriptable. This opens the possibility for enabling scripting of your application, it’s types and potentially objects running in memory in your application at runtime. I recently went looking for an IronRuby console / shell window control written natively in WPF and turned up nothing. I did however come across some examples implemented for Windows Forms and the one that got my attention was Orion Edwards Embedded IronRuby Interactive Console.
Whilst Orion’s project provided the basis of what I was after, I was under no illusion that I would find exactly what I was after and would therefore have to build out the rest of the functionality I required.
The Basic Requirements List
- Reusable WPF User Control
- The Console should allow users to write script against in memory objects of the host application.
- Should persist (to a log) the state of variables in the IronRuby runtime scopes.
- Extensible Application Design and easily maintained and Testable.
So rather than re-invent the wheel I started out with Orion’s code and worked it into a WPF User Control that followed the MVP pattern. This version supports printing of all scope variable state to the console window, clearing of the console window text and all the out of the box access to the IronRuby runtime from the console itself. The IronRuby Console User control also allows the consumer application to pass through in memory variables from your managed CLR hosting application.
Finally I need to also make mention that some of the classes used to stream the STD/IO came directly from Ben Halls wonderful IronEditor. And before I forget, the code can found here on my blogs subversion repository.
