Musings on Language Design

A few years ago, at the university, we were working on a project under the theme of programming languages and compilers. After much debating and brainstorming we decided to develop a little language for describing card games and an interpreter which could translate such a game into a playable version. For practical reasons the language ended up being limited to solitaire games but never the less it remains one of the coolest pieces of software I have had the pleasure of working on.

Creating a language is an interesting experience and it is not often an excuse comes along for making one. After long discussions about whether and how to include loops and such, you get a certain amount of appreciation for the work that has gone into the languages you use on a daily basis. It is a balancing act to get all the factors right, especially if you both want an expressive and elegant language which also facilitates efficient writing of code.

In the case of our language, I had come up with the initial idea which was to describe the card game as closely as possible to how you would think about a real card game. This meant that you would designate card piles, events for clicking them and rules for moving and turning cards. In essence we maintain a state machine for the playing field with legal state changes matching those of the real world; in other words, you cannot magically conjure up new cards and otherwise create a game state which does not make sense. I quickly grew attached to this idea and envisioned the language as a conceptually pure language which would more or less only use these card abstractions to define behavior. The others group members, on the other hand, looked at the language with more practical eyes and wanted more traditional control logic to be included as well such as conditional branching and looping structures. After much discussion and arguing we settled on the practical version of the language which, in hindsight, I think was a crucial choice.

Dusting off the old bits

Recently I got it into my head to bring out the interpreter again, shine it up and repackage it in some Silverlight goodness. I hadn't tried Silverlight yet but I've made another program in WPF and that's close enough I guess.

The original code was some dusty old C# 2.0 code which I merrily began refactoring away at and I have now brought it up-to-date with shiny C# 3.0 features. To be honest, it was quite easy to port the code to Silverlight, though not without a couple of strange bugs. The biggest hurdle was to replace the legacy code which no longer worked in Silverlight. Who needs ArrayLists anyway? Here, you can see how the Card Game Simulator shapes up:

The simulator is in a constant state of change as I work on improvements and you can always find the current version here. I will be posting a guide to develop your own card games in the near future, so stay tuned.