For most Microsoft Visual C#® and Visual Basic.NET® programmers, the evolution of dynamic language support by Microsoft has probably progressed well below the radar screen. When I polled a number of my colleagues on this topic, I was met mostly with mere puzzlement and no knowledge of any support for dynamic languages by Microsoft. My research, however, has disclosed that a lot has actually been happening that neither I nor my friends have been aware of.

At the same time, dynamic language programmers, most of whom are likely not Microsoft oriented, may not have noticed that Silverlight 2 now allows them to write client-side web programming code in their favorite language—instead of forcing them to switch to JavaScript. This is a significant new development, something not previously possible in any other context, including Flash. When I pointed this out to a friend of mine who is a PHP developer, he was quite impressed.

A recent article entitled "Developers Shift to Dynamic Programming Languages" by Linda Dailey Paulson offers an explanation for the rise in popularity of dynamic languages. She writes: "Software developers are always looking for ways to boost their effectiveness and productivity and perform complex jobs more quickly and easily, particularly as projects have become increasingly large and complex.... With this in mind, many developers are increasingly using dynamic languages such as JavaScript, Perl, Python, and Ruby." Moreover, in my conversations with dynamic language developers, the rapid development cycle and the ability to see changes immediately without the need to recompile are the most commonly stated reasons for their preference for dynamic languages. This article will focus specifically on dynamic language support in the recently released Silverlight 2. This topic should be of potential interest to three categories of developers:

1. Python or Ruby developers who would like to be able to use Python or Ruby in the browser.
2. Classic C# and Visual Basic.NET developers who, based on my informal and non-scientific survey, most likely are not aware of the advantages that they might reap from using one of the dynamic languages in the right circumstances to supplement their normal development.
3. Developers of any stripe who want to offer scripting capabilities to end users via a web application.

Currently, dynamic language support by Microsoft extends to three languages: Python, Ruby and JavaScript. Of these three Microsoft supported dynamic languages, the most advanced at this point is IronPython. Version 2.0, RC1 was released in October 2008. By contrast, IronRuby is still in Alpha for Release 1.0. (I am advised that for open source languages—which are continuously updated and not officially supported by Microsoft—there is not quite the same degree of significance associated with the terms Alpha and Beta.) The third language is Managed JScript, a Microsoft version of JavaScript.

Let's look briefly at each of Microsoft's three existing dynamic languages in turn, with a little bit more emphasis on IronPython, given that it is currently the most advanced.

IronPython
IronPython is a Microsoft-created version of Python. IronPython 2 is equivalent to Python 2.5 and includes all of its core features. Even though it is written in C#, IronPython supports most of the "standard library", a large collection of modules written in a combination of C and Python providing many pre-built tools to boost developer productivity.

One of the key advantages of IronPython over other versions of Python such as CPython or Jython is that IronPython is capable of using almost all of the classes in the .NET Framework. As most .NET programmers know, the .NET Framework contains thousands of classes designed to facilitate almost any programming task. The availability of both the standard library and the .NET Framework represents a major incentive for switching to IronPython from other flavors of the Python language when developing for the Microsoft Windows® platform.

The output of the IronPython engine can be set to be a compiled dll which is capable of running via the .NET Common Language Runtime (CLR). Now that Silverlight 2 has been released, the CLR is present not only on that portion of Windows computers which have the full .NET Framework installed, but also on any computer running the Silverlight 2 browser plug-in. Silverlight 2 works in Microsoft Internet Explorer® and Firefox on Windows, Firefox and Safari on Mac (OS X and higher and on the Intel platform only) and Firefox on Linux / Unix via the Moonlight project (when released). This means that applications written in Python can (eventually) run in a browser on all three of the major platforms.

The .NET CLR also provides IronPython applications with memory management, multi-threading capability and security features. Similarly, in Silverlight the CoreCLR provides comparable capabilities to IronPython applications. In both cases another component, the Dynamic Language Runtime (DLR, discussed below) is required. Michael Foord, author of IronPython in Action, asserts that IronPython running in Silverlight is a couple orders of magnitude faster than traditional JavaScript.

IronRuby
IronRuby, also written in C#, is the Microsoft implementation of the Ruby dynamic programming language. IronRuby was announced at MIX07 and although at about a year and a half in development is just now approaching its first full release.

Ruby also has a standard library. Work is currently underway to provide support in IronRuby for most of the standard library. Microsoft is also working on support for the Rails framework. And, unlike non-Microsoft implementations of Ruby, IronRuby can directly access almost all of the classes contained in the .NET Framework, thereby greatly expanding the number of pre-built tools available for any programming task.

As with all of the Microsoft dynamic languages, IronRuby runs on the DLR which makes it interoperable with each of the other Microsoft dynamic languages and with Silverlight.

Managed JScript/ Microsoft Dynamic Languages
JScript is Microsoft's version of JavaScript (technically ECMA Script 3.0) which runs in Internet Explorer. Managed JScript (as compared to JScript.NET) is the version of JScript available in Silverlight which is designed to take advantage of the DLR.

Dynamic languages have many devoted supporters, as do statically typed languages, and rail cars of ink have been spilled discussing the relative merits of each. The question of which one is better for creating your RIA is rendered moot because existing dynamic language supporters do not need to switch to C# or Visual Basic.NET in order to create a Silverlight application. As can be seen from the sample applications discussed in this article, it is possible to create Silverlight applications using exclusively one of the Microsoft dynamic languages.

Most interestingly, two of Microsoft's dynamic languages are Open Source. Both IronPython and IronRuby have been released under the Microsoft Public License.

The source code for IronPython is available at CodePlex. The source code for IronRuby is hosted on Rubyforge. Since Managed JScript is not Open Source, only the binary files (Microsoft.JScript.Runtime.dll and Microsoft.JScript.Compiler.dll) are released. The location of the latest versions should always be available from the Silverlight Dynamic Languages SDK site on CodePlex (discussed below).

Silverlight Dynamic Languages SDK
To provide developers with the tools which they would need to use Microsoft dynamic languages for building Silverlight applications, Microsoft created the Silverlight Dynamic Languages SDK. Version 0.4.0 was released in mid-October 2008. It has four main components: the Dynamic Language Runtime (DLR), assemblies for IronPython, IronRuby and Managed JScript, Chiron (a tool for creating .xap files for dynamic language applications, discussed below) and Microsoft.Scripting.Silverlight.dll which provides the integration between Silverlight and the DLR. It also includes a number of sample applications written in each of the three supported dynamic languages.

Dynamic Language Runtime
The Dynamic Language Runtime (DLR) is a critical element for dynamic language applications running under Silverlight. The DLR is a common substrate for all of Microsoft's dynamic languages that provides them with code generation capabilities, efficient method dispatch, name lookup and debugging support. Most importantly, the DLR is what enables Microsoft's dynamic languages to interoperate with the .NET Framework and with each other.

The DLR is contained in two assemblies, Microsoft.Scripting.dll and Microsoft.Scripting.Core.dll. Since neither of these assemblies is included in the Silverlight browser plug-in, it is necessary for a developer to package them with any dynamic language application. This is one of the tasks of the Chiron tool (discussed below).

Chiron
Chiron is a special tool for creating Silverlight application packages (xap files) for projects which use one of the Microsoft dynamic programming languages. Chiron can be used either from a command line or indirectly from Microsoft Visual Studio® 2008 (See figure 4 below). The syntax for calling Chiron from a command line is relatively simple (assuming that the command line current directory is the folder containing index.html and the folders containing the Python/Ruby/JScript file(s) and other assets)

Figure 1. This screenshot illustrates the folder structure for a simple IronPython Silverlight application. In this case the required current directory from which to call Chiron would be U:\clock\.

Figure 2. This screenshot illustrates how to call Chiron with the /b parameter which launches the user's default browser to view the Silverlight application. "Path" is simply an alias for the actual physical path to Chiron.exe.

Note that Chiron.exe is initially found in the bin folder in the Silverlight Dynamic Language SDK along with several other dll files. Generally, moving Chiron to another location is not possible without also moving all of these other .dll files, although a separate path to these support files can be specified in the Chiron config file. Of course, the location or locations of Chiron and its support files can also be added to the PATH environment variable.

Figure 3. This screenshot shows the list of files contained in the bin folder of the Silverlight Dynamic Language SDK. Access to all of these files is required for the proper functioning of Chiron.

While Python and Ruby developers will likely run Chiron from the command line, most C# and Visual Basic.NET developers will probably find it easiest to use Chiron from inside Visual Studio. (See also the section on IronPython Studio, below) Doing so requires setting three parameters in the Start Options of your dynamic language web application. These parameters can be found in your application's property pages on the Start Options page.

Figure 4. This screenshot points out the required Start Options which must be set in order to use Chiron from Visual Studio.

By default, the "Start action" is set to "Use current page". Unfortunately this will not work in a Dynamic Language project because there is no .xap file available. Creating the .xap file is the responsibility of Chiron, whose path must be specified in the first field as the external program to start when the project is run. The command line argument "/b" tells Chiron not only to start the built-in web server but also to launch the user's default browser to display the project's Start Page. The "Working directory" tells Chiron where to find the data files that it will need to build the required .xap file (i.e., the .py (or .rb) and .xaml (if any) files that make up your web application).

Running the sample projects provided with the Silverlight Dynamic Language SDK simply requires opening the folder containing the file "index.html" in Visual Studio (File / Open / Web Site). Right click the Project node in the Solution Explorer and open the Property Pages. Set the Start Options as described above and press F5 to run the project.

During development (using the /b parameter) the .xap file which is created by Chiron is written only to memory and not to disk. This is convenient because it can speed the performance of the application when testing modifications of the dynamic language code. However, for deployment it is preferable to save the .xap file to disk. This can be achieved by running Chiron from the command line and specifying both the source path (/d[irectory]) and the name to be given to the .xap file (/z[ipdlr]). Chiron will then build the project and include both the DLR assemblies and whatever specific language assemblies are required by your project. If necessary, Chiron will also generate an AppManifest.xaml file.

Figure 5. This screenshot illustrates calling Chiron to create the app.xap file where the project files are located in the sourcepath folder. Of course, both "path" and "sourcepath" are aliases for the actual physical paths which would be required in this case.

IronPython Studio
The Extensibility group for Visual Studio has released a product called IronPython Studio designed to facilitate Python development. IronPython Studio comes in two modes: Isolated and Integrated. This means that a licensed copy of Visual Studio 2008 is not required in order for existing Python developers to use IronPython Studio. In cases of that sort, IronPython Studio can be installed on top of the royalty-free Visual Studio 2008 Shell runtime. Existing users of Visual Studio 2008, on the other hand, can take advantage of the Integrated installation mode.

Sample Applications
Fractulator, one of the sample applications included with the Silverlight Dynamic Language SDK, nicely illustrates an application written entirely in IronPython running in a web browser. This application presents a user with an input box into which he is suggested to type a mathematical expression. Client side IronPython code immediately formats this expression into a user friendly layout, calculates the result of the expression and displays the IronPython syntax which could be used to represent this expression.

Figure 6. This Fractulator screenshot shows a user entered mathematical expression, its formatted equivalent, the formatted calculated result and the IronPython eval expression syntax.

Photoviewer is another SDK sample application built entirely without C# or Visual Basic.NET. Photoviewer performs a flickr search using Ruby and then displays the results using Lightbox, an open source JavaScript project. This application very nicely illustrates the interoperability of Ruby, JavaScript and Silverlight.

Figure 7. This screenshot shows the images returned from flickr from a search for "Tiger". Clicking on one of the images will display a larger size photo. Clicking on one of the numbered boxes at the bottom will display another set of 30 images.

Future Developments (C# 4.0)
Microsoft is currently working on some language improvements which will significantly simplify the syntax required to call dynamic language code from C#. Using a process similar to implicit typing, it will be possible to get a reference to a dynamic object by calling some method or function which returns a dynamic object.

Pseudo Code: dynamic d = FunctionWhichReturnsADynamicObject();
C# 4.0 Example: dynamic doc = HtmlPage.Document.AsDynamic();

The significance of a dynamic object is that the C# 4.0 compiler will not check any method calls on a dynamic object at compile time, thus deferring resolution until runtime. While this is standard procedure for dynamic languages, it is highly unusual for a static language like C#. In all other respects, however, C# will remain a static language. The purpose of this change is to facilitate C# interaction with these dynamic objects through syntax simplification which can be illustrated in the following code samples:

C# 3.x
ScriptObject map = win.CreateInstance("VEMap", "myMap");
map.Invoke("LoadMap");
map.Invoke("SetTitle", item.Title);
C# 4.0
dynamic map = win.New.VEMap("myMap");
map.LoadMap();
map.SetTitle(item.Title);

As you can see, methods belonging to a dynamic object can be called directly instead of through a call to Invoke, passing in the actual method as a string as is currently required. This deferral of method dispatch will extend to field and property accesses, indexer and operator calls as well as to delegate invocations. As we all know, cleaner simpler code is easier to write and less error prone. The mere existence of this project signals the importance which has been assigned to dynamic language development at Microsoft.

Summary
Dynamic language support in Silverlight turns out to be a major benefit for existing Python and Ruby developers because it allows them to write Python and Ruby code for web applications, which formerly required them to write JavaScript. As the Fractulator and Photoviewer sample applications illustrate, it is possible to create Silverlight applications without any C# or Visual Basic.NET code.

On the other hand, for the C# and Visual Basic.NET developer, dynamic language support creates the opportunity for a whole new set of developers to build Silverlight applications, many of which will be open source and available for inclusion in non-dynamic Silverlight applications. Additionally, where it is desirable to provide end users with built-in scripting capability, this can best be achieved via the use of a dynamic language. Finally, since the demise of the HTML DOM and since the need for client side scripting does not appear to be on the visible horizon, further developments in scripting support promised for inclusion in the next release of the .NET Framework looks to make the task of interoperability with scripting languages even simpler than it is today.

Special thanks to Michael Foord for making available to me a pre-publication copy of his excellent book, IronPython in Action. In addition to a comprehensive explanation of IronPython in general—including how to take advantage of the .NET Framework, this book contains a very useful chapter outlining the use of IronPython in Silverlight. The estimated publication date is in early 2009.

Links