Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

.NET and Dynamic Languages

In the months and years ahead, dynamic languages are going to take on an increasing important role in the .NET platform. To support this Microsoft is heavily investing in integration between the dynamic languages and the CLR.

Before we get into how that integration works, we have to take a moment to discuss open source. The most important dynamic languages on the .NET platform are IronPython and IronRuby. As both of these are under an open source license, they won't follow the normal schedule for language changes. All open source languages officially supported by Microsoft will have two release cycles. There will be the release early/release often schedule common for open source projects, which of course results in a lot more rollouts. Parallel to this will be the formal, highly tested releases that Microsoft prefers. Companies and developers will have the option use either style of release, as both will use the same code base.

As for integration, is all revolves around the IDynamicObject interface. This acts as a method binder allowing each object to use the semantics of the language it was written in. The languages that will have binders out of the box include IronPython, IronRuby, JScript, and COM. Yes, COM is considered a dynamic language for this purpose of late binding and dynamic method invocation.

In addition to language specific binders, developers can have special rules for just a single class. The easiest way to do this is to start with the abstract class DynamicObject. What follows is a list of actions that can be overridden for custom behavior. As you browse the list you will undoubtedly see some actions not supported directly by the syntax in your language of choice.

GetMember

SetMember

DeleteMember

UnaryOperation

BinaryOperation

Convert

InvokeMember

Invoke

CreateInstance

GetIndex

SetIndex

DeleteIndex

Developers do not have to implement all these methods. They could, for example, create a property bag by simply supporting SetMember and GetMember. And because of the way it was designed, a truly dynamic class can be written in any language, even otherwise statically typed languages like C#.

Originally, IronPython had its own language-specific abstract language tree. As work on the DLR continued it was discovered that the differences between each language was actually quite small. Finally, it was determined that LINQ Expression Trees had almost everything needed to represent any dynamic language.

The missing features, which will be added in .NET 4, are assignment, control flow (loops and goto), and dynamic dispatch nodes. The dynamic dispatch nodes are language specific and used to honor language-specific rules for method calls and overload resolution.

An example of language-specific semantics is the result of multiplying 2 billion by 2. If the expression tree is honoring IronRuby or IronPython semantics, it will return 4 billion. Using C#'s default semantics it will overflowing and VB will default throwing an exception. For those wonder why, IronRuby and IronPython will automatically promote an Int32 to a BigInteger field when an overflow could otherwise occur.

To improve performance, the DLR is using a new call site mechanism. Call sites in the DLR are statically typed representations of a dynamic call based on delegates. Since delegates are not cheap to create, the delegates are cached in a list. For each call, the list is walked until a match is found. If a previously unseen type is seen, a new delegate based on the shared abstract syntax tree for that type is added.

To determine if an argument type has been seen before, each language needs to provider a MetaObject. This holds a check to see if the argument type matches what has been seen in the past and what to do if it does match.

The ability to create new MetaObject allows developers to replace expensive name based hash table lookups with the actually expression tree that represents the method being called. Depending on how it is written, one could even see performance that exceeds what is seen in the static world.

And to be honest, I don't really see a whole lot of interest in the future. As a statically typed language, it has a ton of competition. And now Olso is making it so that anyone can make a new language in short order.

Unfortunately there hasn't been enough resources invested into Boo over the years. It was light years ahead of C# pre-C# 2.0, and still has Macros which no Microsoft language has.

As far as M (the language of Oslo) is concerned, it's yet to be seen how that is going to pan out. I've downloaded the SDK and looked at some of the videos. We'll see what kind of investment Microsoft really wants to put in it.

It's definitively true that Boo website is lacking... but please do not take the website's news category as the only metric of the liveness of the project.SVN logs and more importantly the mailing-list are much better metrics in the case of Boo for instance.

Also, Boo is not a 'pure' statically typed language (we've got duck typing and IDynamicObject, in the form of IQuackFu, for years). In this particular niche of a hybrid static/dynamic DSL-friendly language I do not think there is much competition.