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.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (6)

  1. @Dave Yeah, that is an excellent example. Also, it is pretty funny that the question was posted in the "client side" web development forum and when you asked the guy where he was working with it, he said "server side". 🙂

  2. What are the scenarios – considering culture, architecture, and existing systems portfolios – where C# code will need to call Ruby code.

    I think the interop argument is a good one, but I think the concrete scenarios are extremely rare, making the interop argument mostly theoretical in context.

  3. I have to say that I agree with Scott Bellware. The cases where interop is needed are rare and generally one-sided. IMO, a rubyist may find a need for a .NET library more often than a .NET developer needs a ruby library. Usually, the .NET community will port something cool from another language rather than use it in its native form e.g. NHibernate, Nant, NHaml.

    In addition, interop seems to be MS’s weak point. Their solution seems to always involve creating their own version of the language they wish to interop with. In other words, they don’t gain interop as much as they adapt the syntax for use on their own platform e.g. J#, JScript.

    Because of this, I constantly entertain alternate solutions to the interop problem MS is solving. I look at solutions like CSScript, RubyCLR, and even Powershell. BTW, I’m still looking for the definitive guide on how Powershell does .NET interop with its Extended Type System.

    Making C# more dynamic seems like a bad idea to me. However, making it more functional seems like a natural progression in making it perform better in the future.

    Sorry for the long-winded rant.

  4. @Curtis @Scott I must have missed the e-mails for these comments, because I see that Scott’s comment was left some time ago. Sorry about that.

    I think that the interop scenarios is fairly rare currently, but personally I believe that will change in the future. A lot of software is written right now to use a ton of xml, rules engines, database driven logic, etc… all because someone wants to inject a bit of dynamism into a static application.

    While the dynamic language features of IronRuby or IronPython may not be at the forefront when decisions are made to use them in these contexts, I believe that their dynamic nature and more simple syntax will give them an edge in this space.

    I hope that having very good interop with interpreted languages (that have very simple syntaxes) will lead to a shift away from some of these configuration driven technologies and more toward real languages so that we can use some of these fancy IDEs and debugging tools that we have invented over the past 50 years. 🙂

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

More Insights

View All