Almost exactly 6 years ago, the incredible Cory Ondrejka and I met for the first time in real life (having previously blogged together on Terra Nova) at the Austin Game Conference 2004, where we got on like a house on fire. Several months later I joined Linden Lab and (as James and Jim Linden were already taken) Babbage Linden was born. The first task Cory asked me to do was embed the Mono virtual machine in to Second Life as a next generation scripting engine. It was a wonderful project to work on, involving authoring a new LSL compiler back end to generate CIL bytecode, a scavaging garbage collector to allow assembly unloading and a microthread injector to allow 10s of 1000s of scripts to run concurrently on Mono in a single process (work that has been described in detail in talks at ooPSLA, Lang.NET and FOSDEM ). As a long term R&D project it was put on hold a number of times to make way for more important projects like HTTP-Out, Message Liberation and Het-Grid, but eventually we shipped a Second Life simulator that embedded Mono in 2008.

Running LSL on Mono in Second Life was a huge win, allowing scripts to run 100s of times faster in some cases and reducing the average memory footprint of scripts in Second Life by a third, but the big hairy audatious goal for Mono in Second Life was always to enable other languages that targeted the Common Language Infrastructure to run in Second Life. After waiting until the end of last year for Mono 2.6 to implement the bytecode verifier and CoreCLR security sandbox which allowed us to safely run other languages on Mono inside the simulator we started work on adding support for C# in Second Life at the beginning of this year. A team of Linden engineers in Brighton and California did an amazing job overcoming an array of challenges and got to the point where we had Silverlight chess demos, run time configurable script profilers and scripts that used .NET reflection APIs to visualize other C# scripts running in our development simulators earlier this summer.

Alas, tomorrow is my last day at Linden Lab and Babbage Linden will never get to see C# scripts running in the wild in Second Life, but I very much hope that I do. I hope that C# support is eventually added to Second Life and that I don’t have to wait 170 years to turn the handle. As another Babbage said when he failed to build the Difference Engine: “Another age must be the judge”.

It was incredibly satisfying to be able to go back to Lang.NET 3 years on to be able to say that we actually managed to make all the crazy plans we had for Mono in 2006 work. My talk is now online here. Lots of people hadn’t seen the 2006 talk and were blown away with us adding support for continuations on the CLR and enough new stuff to keep those that had seen the first talk interested. In particular the anecdote about flywheel exploits for the Mono scheduler got a laugh from Anders Hejlsberg.

The other highlights on Tuesday were Mads Torgeson’s talk, which gave some nice insights in to the process that led up to the final C# 4.0 Dynamic design. Mads did a good job capturing some of the concerns that static advocates have with dynamic languages. Gilad Bracha’s talk on Newspeak and the Hopscotch IDE showed what’s possible with a really dynamic language: extending the IDE and debugging it from inside itself. The access that newspeak has to it’s call stack was particularly interesting: it would be much easier to move a newspeak stack around than build the infrastructure we needed to move a CLI stack. I spoke to Gilad about his experiences building newspeak on Sqeak afterwards. His impression is that Squeak is runtime mostly used for education and has no support for security or running untrusted code. Having spent a decade seeing the various security problems with bytecode verification in Java, Gilad isn’t convinced that a bytecode level sandbox is the right approach, but although he has some ideas for object capability based security for the post squeak Newspeak implementation it seems a long way off.

The highlight on Wednesday was definitely Lars Bak’s talk on V8, which I had missed last year at JAOO. The mechanism for discovering emergent types in dynamic languages to allow indexed lookup instead of hash table lookup is a very nice hack. Lar’s super competitive heckling of everyone at Microsoft for the rest of the day was also fun. Other highlights included Erik Meijer throwing coins around while talking about mathematical duality and Amanda Lauter and Luke Hoban talking about F#. Potentially relevant to Linden Lab if we get to the point where we can support debugging scripts in Second Life was Herman Venter’s talk on the Common Compiler Infrastructure a newly open sourced library which can allow CLI assembly rewriting while preserving debug information.

The Meta Introduction to Domain Specific Languages was a really good opening for the DevCon, but the talk most relevant to Second Life was Paul Cowan talking about DSLs in the Horn Package Manager. Paul talked about creating DSLs by extending Boo, something that should be possible when we get to the point where Second Life can accept arbitrary CLI assemblies. I got a first Boo script compiling against the Second Life assemblies at the DevCon and have some plans to experiment building a DSL for virtual ecosystems in Second Life over the next few weeks. Supporting C# as a general purpose language and Boo as a meta language for building DSLs in Second Life would be an excellent combination.

A lot of the talks at the DevCon seemed to involve doing terrifying language somersaults to create more natural DSLs that run on the JVM or CLI which then can’t be easily debugged due to the huge chained expressions or nested types that the languages boil down to. There seems to be a large opportunity for disaster here when these DSLs need to be extended or maintained in 10 years time after the original authors have moved on. Although Martin deflected a lot of these questions by saying you can get bad frameworks as easily as bad DSLs, I feel a lot more comfortable unpicking a bad framework or wrapping a library than trying to fix or extend a broken language (maybe several years reimplementing LSL’s quirks did that).

The ultimate promise of DSLs was hinted at by Magnus Christerson’s talk which demoed Intentional’s amazing Domain Workbench. Instead of building DSLs on top of mainstream runtimes, the Domain Workbench models the domain and can then project the model as code or using domain specific projections like interactive circuit diagrams that can be manipulated and debugged interactively. Magnus started his talk saying that we used to have to enter programs on punch cards that evolved in to sequential programs and that we don’t need to do that any more. If the Domain Workbench’s promise is fulfilled it could change the way we develop software forever.

When I heard that the theme for the Linden Lab Christmas party was going to be steam punk, I knew I had to go as Babbage Linden. Since 2005 my avatar in Second Life has sported a victorian suit from Neverland and a steam arm, originally from a Steambot avatar which I updated to a more recent design from Marcos Fonzerelli after Joe Linden started washing his face in my sink.

I had a suit that was close enough and a bit of riffling through local shops and ebay got me a waistcoat and cravat that were a pretty good match, but I knew the arm was going to need a lot of construction, even if I went for the first version from the Steambot. After some Googling trying to find out how to construct a conical frustum I remembered the export to world project that had converted Second Life objects to paper craft models. So, after checking that Marcos didn’t mind me exporting his geometry from Second Life, I decided to do that.

Installing OGLE proved to be really easy — just dragging the replacement OpenGL DLL and supplied config to the Second Life directory worked fine, but my first few captured scenes were full of unwanted clutter. In the end I found that using the advanced menu to turn off all render types apart from Basic, Volume and Bump and the UI feature allowed me to capture just the steambot arm placed in front of me in Second Life.

After opening the .obj file captured by OGLE in Blender, exporting it as a DXF and opening it in Pepakura Designer it was clear that the model was far too complicated — the cones and spheres created dozens of faces. Going back in to Second Life I broke the steambot arm in to 1 piece for each cardboard part I expected to make, stripped off all of the spheres, made the finger tips in to boxes instead of cones and then used the Second Life preferences to set the object mesh complexity to minimum, which reduced the number of faces on each cylinder to 6.

With these simplifications made the models looked much more managable when opened in Pepakura Designer, but it was still worth playing with open faces to simplify the parts in to quad strips. With these tweaks made I determined the correct scale. I placed my forearm on a couple of sheets of A4 and then adjusted the scale in Pepakura Designer until the steambot arm covered approximately the same amount of paper, then noted down the scale so I could use it when printing each part.

After printing the parts out on A4, I pinned them to some think double ply corrugated card from some old Dell boxes and then cut out the shapes and assembled them with gaffa tape, PVA and paper fasteners. I replaced the spheres with some polystyrene spheres from a craft shop and replaced the shiny with half a dozen coats of copperchrome spray paint.

I had a load of fun and the finished arm is amazingly sturdy, surviving 6 hours of Christmas party relatively unscathed. Who knows, maybe I’ll get another chance to wear it at an SLCC in the future. A full set of pictures with notes is available here.