Dynamic Languages 101

Much hoopla has been generated across the community about dynamic languages; much of it is spoken in the same glowing terms normally reserved for unicorns and rainbows. Some of it is deserved, some of it isn’t. All of it seems to surround two languages-JavaScript and Ruby-but in fact, several other languages, three of which I’ll present here, offer some distinctly interesting and useful features.

Twenty years ago, I took a contract building a standalone desktop application for a small firm. I was the die-hard hard-core C++ developer who prided himself on knowing the four different kinds of smart pointers, not to mention all of the Gang-of-Four design patterns and the C++ template syntax. But as I scoped out the project, it became apparent to me that this program didn’t cater much to C++. It was a lot of file manipulation, writing a file here, reading a file there, copying a file to this other place and so on. And they wanted a small database to store some configuration, and… The more I looked at it, the more it sounded like this was a problem for… (dare I admit it?) Visual Basic.

Long-time VB developers know what’s coming next.

I presented my position to the boss, an IT guy who clearly wanted to make the transition to development, and his response was emphatic. “This is an application that the firm is going to depend on, so it has to be written in C++.” When I asked him why, he said, point-blank, the way one lectures a small child, “Visual Basic code is interpreted, so it’s slow. It doesn’t have a type system, so code written in it is buggy. And it runs on top of a garbage-collected virtual machine, which means it’s bloated.” And so on.

I often wonder what that guy thinks of the success of the JVM, the CLR, Parrot, and LLVM, not to mention Ruby, Python, JavaScript and Perl.

Well, maybe not Perl. Perl just sucks.

Rise of the Dynamics

One of the core facets, typically, that makes a language a “scripting” language (as opposed to a “system” language like C/C++ or Pascal) is that the scripting language is interpreted rather than compiled. In a world dominated by just-in-time compiled bytecode execution engines like the JVM and the CLR, these definitions get a little fuzzy. Let’s not argue that point-it’s not incredibly important anyway.

What is interesting about dynamic languages is that the presence of that interpreter gives us an interesting ability, one that goes underutilized within most enterprise projects: we can embed the interpreter into another project and use the scripting language from within our own applications. Imagine business rules written by business analysts and stored in a database for your web application to retrieve and execute, for example. Or imagine being able to modify the code on the fly from within the application, usually in response to user requests or fast-moving business logic changes. Or imagine using the “scripting” language as a way of storing configuration data that has some logic within it (to differentiate between users, roles, servers, you name it). In fact, this latter example is hardly new: James Gosling, the inventor of Java, once said, “Every configuration file becomes a scripting language eventually.” (I’m looking at you, app.config.)

In some cases, the language in question can be compiled directly to bytecode and executed alongside the code we write in C# or VB (or F#, if you were paying attention to Aaron Erickson’s article from Mar/Apr 2012 issue of CODE Magazine, Quick ID: 1203081). This means we can take something of a Marxist approach to languages in a project: “From each language, according to its abilities. To each project, according to its needs.”

In this article, I want to show you a few dynamic languages you’ve probably not seen before, and how to use them from within traditional C#/VB applications. I’m not going to suggest that you use all of them at once, nor even that this is a “must-do” kind of thing. But, hey, if the shoe fits….

Note that I’m not going to spend a lot of time talking about IronPython and IronRuby because they’ve already gotten some good press in the past. It’s likely that readers of this magazine have run into them before.

Note, also, that I’m not trying to jump into the “dynamic vs. static” debate and weigh in on the side of dynamic languages as being “better” than static languages (whatever that means). To be honest, I actually prefer languages that have a strong type system behind them, like F#, but much of that is because I tend to write code behind the scenes, rather than the front-end code which generally lends itself better to the dynamic end of the language spectrum. (I cite as exhibit A the incredible success of Ruby on Rails.) To be perfectly frank, I believe in a polyglot world, one in which we use a variety of languages to solve the world’s IT problems.

And these are three of the languages I think you should think about using to solve those problems, above and beyond the ones you already know.

Lua

Lua is probably the most widely used scripting language you’ve never heard of. The language itself is a freely-available open-source object-oriented(ish) language hosted at http://www.lua.org. The reason for its popularity is simple: Lua was designed from the beginning to be easily hosted from C/C++ code. This made it very attractive to game developers and designers, allowing them to write the high-performance code in C or C++ and the game rules and triggers and game logic in Lua, even opening up the Lua scripts to third parties (like gamers) to customize and extend. World of Warcraft does this, and it has spawned a cottage industry of gamers-turned-programmers who customize their WoW experience with plugins and add-ons and extensions, making the WoW ecosystem just that much more fun and interesting.

The original hosting interface for Lua is, as mentioned earlier, based on C/C++ code, but fortunately the Lua community is every bit as active as the Ruby or .NET communities. A .NET-based adapter layer, LuaInterface, hides the .NET-to-C++ interop parts, making it ridiculously trivial to host Lua code in a .NET application.

Getting Started with Lua

LuaInterface is, like Lua itself, an open-source project, and lives at http://code.google.com/p/luainterface/. Currently, the best way to use LuaInterface is to pull down the source, which is a trivial exercise in Subversion. Once it’s on your machine, it’s an equally trivial exercise to build it in Visual Studio.

One note: there are a few mentions on the LuaInterface wiki about build errors around “mixed-mode” assemblies, but I didn’t run into this. I did, however, find that the test executables (LuaRunner) were missing an app.config in the project, which breaks the build. It caused no harm to remove the app.config reference from the project and build, so I suggest doing so. Fact is, we don’t really want the test executables anyway-we want the library for our own uses.

Before we go much further, test the LuaInterface build: in the “Built” directory next to the LuaInterface directory, you should find a compiled “LuaRunner.exe” (assuming you got it to build). From the Built directory, run:

C:> LuaRunner ..\lua-5.1.4\test\hello.lua

And you should get the traditional greeting.

By: Ted Neward

Ted Neward is a Principal Consultant with ThoughtWorks, a global consulting firm focusing on .NET, Java and Ruby enterprise development. He is an internationally recognized speaker, instructor, consultant, and mentor and spends a great deal of time these days focusing on languages and execution engines like the JVM and CLR.

ted@tedneward.com