Archive

Archive for the ‘Languages’ Category

The IronPython standard libraries dilemma – [a learning strategy]

August 5th, 2009 Simon Segal 4 comments

The choices facing any programmer wanting to start working with IronPython or IronRuby for that matter, contain some interesting questions. Working with Dynamic languages in .NET prompts us to consider whether to use Python / Ruby native standard library method and functions or directly work against the BCL? If your programming in a statically typed language on top of the CLR, then it’s just different syntax but the same platform libraries. If you want to try your hand with IronPython or IronRuby you need to consider that both these languages have evolved on different platforms. For example, should I consider using Python standard library functions to interpolate some strings or should I use the BCL? Consider these two approaches:

Classic Python Version

print should I use python functions or .Net? +
                    Ans = %(yes)s % {yes: yes}

BCL Centric Version

print String.Format(should I use python functions +
    or .NET? Ans = {0}, BCL Functions)

So that was pretty trivial. What about File access?

Classic Python Version

 rdrp = open(r”c:\Document1.txt)
 rdrp.read()

BCL Centric Version

 rdr = StreamReader(r”c:\Document1.txt)
 print rdr.ReadToEnd()

Any clearer on a choice? The pragmatist in me says use the BCL and the purist says use the python standard libraries. So how heavy should our BCL wielding hand be? This leads me nicely to the next question, how exactly should we go about learning a Dynamic .NET Language? Surely this process will help us make up our minds about when to use the BCL and when not to? Something tells me that the answer lies pragmatically somewhere in the middle ground? The kind of meat and potato stuff like that demonstrated above is likely going to have me opt for the classic Python approach as my default position, however I am not going to put myself to the trouble of working with databases for example without the help of ADO.Net. To help myself form my own opinions I decided that the best learning path for me was as follows:

  1. Read the Python 2.5 (CPython) documentations PDF Tutorial and re-type it’s code examples and follow with my own experimenting.
    • This allowed me to get a fairly good overall feeling for the language.
  2. Read IronPython in Action to get a good overall point of relevance to .NET and see how the power of .NET as a platform would impact the Python experience and visa versa.
  3. Read Python is a Nutshell and get a grasp on Python’s roots and how the language is best put to use on it’s original platform (the C implementation).

Some people will surely think that points 2 and 3 should be reversed? Perhaps, but my rationale for taking this approach is that Python is not likely to become a daily instrument in my work and I want to understand as much as possible about it in the .NET world first. I do believe however that to truly understand the power of Python I will need to learn deeply about its roots and oddly I suppose that step in the process will come last.

Share/Save/Bookmark

Categories: DLR, IronPython, IronRuby, Languages Tags:

Which DLR language should I choose? Is it now IronRuby vs. IronPython.

June 18th, 2009 Simon Segal 2 comments

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?

Share/Save/Bookmark

GOF Series: Episode #5 : [The Prototype Pattern] - In IronRuby

April 23rd, 2009 Simon Segal No comments

Firstly let me mention that whilst this series started out as demonstrating the Gang of Fours patterns in C# I have since decided to change direction a little bit and have the rest of the series presented in IronRuby. Why? My Reasons are twofold, firstly there are probably more than enough examples of the patterns in C# that another one will certainly not be missed and second completing the series in IronRuby will serve as great learning tool on the way to better knowing the language. I have previously posted on the Builder Pattern implemented in IronRuby and for that example I used Sapphire in Steel to develop the code and I am really hoping that we get a great code editor for IronRuby when it makes it’s official debut.

What purpose does this pattern serve?

Implementing the prototype pattern facilitates creating a prototypical object and subsequently being able to produce copies of that prototype.

Example Code:

First lets start with our Vehicle manager which will hold the prototyped vehicles that we wish to take copies of.

class VehicleManager
    def initialize
        @cars = {}
    end
    def add key, prototype
        @cars[key] = prototype
    end
    def remove key
        @cars.delete key
    end
    def get_vehicle_by_key key
        @cars[key].deep_copy
    end
end

Next we create a module that we will use as a mixin to extend a ‘vehicles’ behaviour to include cloning.

module Cloneable
    attr_accessor :id
    attr_accessor :horse_power
    def deep_copy
        Marshal.load(Marshal.dump(self))
    end
end
Now some some Cloneable vehicles that our Vehicle manager can work with.
class Car
    include Cloneable
    def initialize horse_power, id
        @id = id
        @horse_power = horse_power
    end
end

class MotorCycle
    include Cloneable
    def initialize horse_power, id
        @id = id
        @horse_power = horse_power
    end
end

All that’s left is to look at how to create some prototype’s using these classes.

$counter = 1

#new up a VehicleManager to store vehicles
#that we are interested in cloning
vmanager = VehicleManager.new

#add a car and motor cycle to the manager
vmanager.add :eighty, Car.new(80, $counter)
$counter += 1
vmanager.add :ninety , MotorCycle.new(90, $counter)

#retrieve clones of the car and motor cycle
vehicle_car = vmanager.get_vehicle_by_key :eighty
vehicle_bike = vmanager.get_vehicle_by_key :ninety

#print the results
puts “The horse power for the car is “ +
     “#{vehicle_car.horse_power} and the ID is :#{vehicle_car.id}”
puts “The horse power for the motor cycle is “ +
     “#{vehicle_bike.horse_power} and the ID is :#{vehicle_bike.id}”
console_ir_prototype_pattern
Yet again the brevity of IronRuby (Ruby) comes to the fore and true to the languages nature, interesting things can be done with less code when you compare to our statically typed friends. I am definately gaining a real appreciation for “composition over inheritance” and as the static languages are now crossing the paradigm divides with features clearly borrowed from both the functional and dynamic worlds, should we be expecting to get the ability to compose our objects in C# or VB.NET sometime in the future?

Share/Save/Bookmark

Creative Commons Attribution-ShareAlike 2.5 Australia
Creative Commons Attribution-ShareAlike 2.5 Australia