The Blurring Lines of Languages

On Twitter the other day I had a short conversation (well, it wasn’t really a conversation since it was only about 4 tweets) with Jeff Cohen who is the author of Rails for .NET Developers. Which is, by the way, an excellent book and highly recommended. The conversation that we had was about the dynamic keyword for C# and its implications for C# developers.

Jeff expressed some concern for the keyword and its potential abuse among C# developers. His point was that if C# developers want to write dynamic code, then you need to use a language like IronRuby or IronPython, not try to inject dynamic code inside of C#. Thankfully, for  the most part, I agree with him! However, I do think the dynamic keyword is a great thing because, most importantly, it allows interop between static and dynamic languages to be super easy. Without dynamic, we would have to use all kinds of nasty APIs to use an IronRuby object inside of C#. With dynamic I’ll be able to write code that looks like this:

dynamic irObject = GetIronRubyClass();
string resultValue = irObject.CallSomeMethod();

Which is pretty awesome, but how would that possibly work in a statically typed language? The short answer is that it wouldn’t. In order to accomplish this magic, whenever C# sees the dynamic keyword it generates IL that performs late bound calls against the object. Which means that in order to interact with a dynamic language, C# essentially becomes a dynamic language itself. So does that mean that C# is a dynamic language now?

But I think a more interesting question is, do we need to draw a line in the sand between static and dynamic? It seems that as time passes the lines between static/dynamic, OO/functional are being blurred more and more every day. When C# 4.0 comes out we will have an object oriented, statically typed language that has enough functional features in it to almost be considered a functional language, and now a bit of dynamicness thrown in to give us a leg up on a few special cases where making dynamic calls could really make our code more simple.

Now before people get out there pitchforks, yes I know that C# is still missing several fundamental aspects of a functional programming language such as pattern matching, easy immutability, partial application (not at the language level), etc… but that really isn’t my point. My point is that C# is starting to pull in many paradigms in order to make developers lives easier without going full steam in an entirely different direction.

Another great example of a language like this is Scala. Scala, just like C#, is a statically typed, object oriented language. The main difference is that Scala has gone much further in the functional programming direction than C# has. Scala does have support for easy immutability and even encourages the developer to program in this way. It also has language support for partial application and it has robust pattern matching. However, Scala has not yet gone in the dynamic direction that C# 4.0 has. In Scala, the only support for dynamic typing is structural types, which allow you to specify a type by its shape. Sort of like specifying an anonymous interface.

So, are we pulling what we need into our languages so that we can right software easier and faster? Or are we creating kitchen sink languages that are so bloated it has become difficult for people to learn and use them effectively?

Personally, I think that general purpose languages can only benefit from learning a few tricks from other programming paradigms. But I also don’t think that we will ever get to the point where we have one programming language to accomplish everything. Nor do I think that is even desirable. I love the fact that I can write in a language on a day to day basis that allows me to pull in a bit of lazy evaluation, or some other functional goodness, but then I also see that it would be very difficult to take the dynamicness or the functionalness much further in C# without sacrificing the core of what the language is. It is a very narrow line to to walk.

I for one look forward to a future where languages borrow from each other, but keep enough of their individuality in order to make them useful. Always keep in mind that a jack of all trades is an ace of none.