Living in the Tech Avalanche Generation

If I could teach myself to write hello world in twenty languages that would not do it! Clearly a ridiculous way of measuring isn’t it. But seriously how do we go about qualifying whether our knowledge in a given language is of any value (to anyone, including ourselves).

A common mantra of the polyglot programmer (as espoused by some) is to learn a new language every year. This is an interesting idea, however in isolation it sounds perhaps somewhat of a generalisation without a clear purpose. It’s my experience that we human beings have an equally strong capacity to forget as we do learn (not in equal measure), and without exercise we can easily lose some our fluency and dexterity when working with languages. If I were to learn a language every year I would no sooner forget much about them without regular usage. Can we really be expected to employ a host of languages in our day to day work and is that even the goal? I think a specialised meaning for the word ‘learning’ is what’s missing here but let’s come back to that later.

I must profess that I am extremely interested in learning new programming languages, I find it stimulating for a variety of reasons; someone (I forget who – sorry) remarked on twitter recently about how fabulous it is to feel totally unknowing at the outset of learning something totally new. Over the course of the past year I have invested significant personal time in learning both Ruby and then Python and did enjoy some small opportunity to put IronPython into practice commercially in 2009. I do not consider myself a strong Python or Ruby Developer, far, far, far from it; C# continues to enjoy my most significant attention and depth of knowledge, a reasonable outcome given it is the language I spend most days plying my trade. I do however consider myself strong enough as a developer to leverage my existing knowledge in programming and capacity to be resourceful, to employ new languages to my benefit if they are the right tool for a given job. No doubt over time and with more experience my rating with Python will increase but I am happy with where it is right now, it’s somewhat in line with my planning, expectations and requirements.

My interest in Python at this point is quite singular, it is a window to the Dynamic Language Runtime and specifically one of the languages which can be leveraged to script the more significant C# projects I am engaged in. Do I need to become equally knowledgeable in Python to leverage it in this manner? Must one exercise mastery of all chosen languages with proportionate levels of precision? My current mode of thinking on this point is we don’t need to, however, as always I am open and curious to hear other points of view.

How does one choose which language to learn next. I don’t think developers should pressure themselves into making hasty decisions in this regard. My own approach was to sample them both first – study a reasonably significant language guide (from each) and spend some time (1 hour a day) writing code (in each) – then make up my mind. After going through the ‘sampling’ exercise, I chose to Python initially however that doesn’t mean I wont one day decide to invest more time into Ruby, I like Ruby. One of the most commonly touted value propositions in learning a new language, is that it helps us become more rounded as developers opening our minds to a broader range of programming techniques and design possibilities. I think we are mature enough these days (as a profession) that the religious language wars are becoming consigned to the past, part of our less enlightened and evolved communal selves.

Most recently I have emerged myself in learning Erlang. Erlang’s established position in the world of highly concurrent distributed systems is the key to driving my interest here, I want to better understand the wider implications and possibilities in the language and platform. A secondary motive is that it will give me a good opportunity to learn a functional language after having now tasted the fruits of statically typed and dynamic languages. Does this mean I will tie myself to the Erlang banner now? Not at all, it’s just the starting place for me, I will look at AXUM and F# over the coming twelve months. AXUM may never get out of MS Research, who knows, but going on what Luke Hoban said at the PDC09, F# may reap some of the benefits from AXUM’s research, making distributed message passing a part of the language.

Will I become an advanced user of Erlang – I don’t know, for now all I plan to do is read Joe Armstrong’s book and type of bit of code at the Erlang Shell, but that doesn’t preclude the possibility that I will use Erlang in a professional capacity at some point in time.

So am I a polyglot programmer? Does it require commercial implementation or does personal study aimed at greater understanding qualify. What level of command of languages does one ascertain to become a true polyglot programmer? What languages qualify for polyglot distinction – what about JavaScript, CSS and XML, surely most web developers must find themselves in a default position of being a Polyglot just to survive in their jobs?

Let’s go on a journey that takes two interesting technologies that have been to date, confined to an interoperability argument that left them barely on speaking terms. Of course I am speaking figuratively but what I’m trying to convey here is that, languages built to run on the DLR are currently limited in ways that preclude them from working seamlessly with the LINQ based ORM technologies from Microsoft, namely the Entity Framework and LINQ To SQL. This of course does not mean that languages such as IronPython are stuck in some ADO.NET void, that is not the case at all. In fact if you want to check how to use ADO.Net Data Readers etc, from IronPython I suggest check out chapter 13 of IronPython in Action (in fact if IronPython is of interest I can highly recommend the book).

Before we continue lets touch on some background. An important part of getting IronPython entities working alongside the Entity Framework, required that the Entity Framework would be calling back into our IronPython code. In recent times, a new feature was added to IronPython 2.6 which accommodated this requirement. The __clrtype__ feature allows customization of the classes that constitute the underlying CLR types for IronPython classes. If you want to find out more about this you should read the series of posts by Harry Pearson on the subject.

So with a fistful of interest in the DLR and the dynamic languages built on it, I became curious about whether the new advances and features in the Entity Framework version 4.0 combined with the addition of __clrtype__ meta class for IronPython, would bring these two technologies any closer to working together. After some pointers in a recent discussion with Michael Foord, I was willing to bet that some form of interop between the two (EF and IronPython) would now be possible; I was gambling on the added support for POCO in the Entity Framework and the customising of CLR types generated for IronPython to provide the neccessary hooks to effectively create PODO’s (Plain Old DLR Objects) that would map successfully as Entity Framework entities. Here is what I was hoping a PODO might look like.

class Customer(object):

    __metaclass__ = clrtype.ClrClass
    _clrnamespace = “EntityFramework.Podo“
    _clrfields = {  “_customerId“:str,
                    “_companyName“:str,
                    “_contactName“:str
                 }

    @property
    @clrtype.accepts()
    @clrtype.returns(clr.GetClrType(str))
    def CustomerID(self):
        return self._customerId

    @CustomerID.setter
    @clrtype.accepts(clr.GetClrType(str))
    @clrtype.returns()
    def CustomerID(self, value):
        self._customerId = value

    @property
    @clrtype.accepts()
    @clrtype.returns(str)
    def CompanyName(self):
        return self._companyName

    @CompanyName.setter
    @clrtype.accepts(str)
    @clrtype.returns()
    def CompanyName(self, value):
        self._companyName = value

    @property
    @clrtype.accepts()
    @clrtype.returns(str)
    def ContactName(self):
        return self._contactName

    @ContactName.setter
    @clrtype.accepts(str)
    @clrtype.returns()
    def ContactName(self, value):
        self._contactName = value

First up, I guess that in a pure sense this is not so compliant in the P part of PODO right? The Decorators on our functions do bleed out the technology a little but I am not going to let the goal get hung up on this point.

My initial thoughts also considered that with Code Only mapping I might be able to do away with any need to provide any supporting infrastructure code created in a statically typed language (C# or VB.NET).

In Part 2.0 of this series of posts we will start the journey in earnest and see what successes and hurdles we hit along the way. Rather than keep you waiting to find out whether this is all going to end well and keep you dangling under false pretences, let me just say that it partially works. The fact that it partially works gives me hope the rest of this series might help uncover or encourage a way to make these two technologies work together in a more complete way.

A while back I went through the personal struggle of trying to decide which .NET dynamic language I was going to adopt. After some fairly lengthy consideration and with a bit of help from Michael Foord, I chose IronPython. Recently I posed this question to Michael: are .NET developers experiencing some *romantic* attraction to IronRuby? Michael I think was a little taken aback and not sure how to respond, most likely I didn’t frame the question eloquently nor clearly enough and so I will take another shot at it here.

Let me explain what I mean by “romantic”. I am noticing that people (I know) in the .NET development community are leaning more towards IronRuby when faced  with the choice. Perhaps my perspective over the so-called community isn’t broad enough to make any sweeping generalisations here, I understand that, nonetheless, tucked away here in my small corner of the universe I get a sense that I am observing a kind of default (if not romantic and sometimes perhaps envy driven) choice of IronRuby over IronPython.

What are the contributing factors? Some very high profile .NET people have jumped the .NET ship in favour of developing with MRI in the recent past. The most obvious connection I guess may be that ASP.NET developers (who by far number the majority in the .NET employment pool) have an vested interest in the successes of ROR which may account for this perceived phenomenon. I also get the feeling the feeling that Ruby gets a better deal in the hype stakes and that could also be having some impact.

I wonder has anyone else noted this? Figment of my imagination? Way off the beam? One thing is for sure, neither seem to be playing a real part in the commercial world yet; a search on seek.com.au (a well known job market web site) for IronRuby or IronPython or DLR, will sadly produce no results. This is understandable as IronRuby in only just recently gone RC1, but IronPython has been around a little while and some people in some parts of the world do make a living with it already.

UPDATE:

Oh I did forget that perhaps people just think Ruby is the better of the two languages?