This is part of a RubyConf 2009 series:
Overview | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status
Let’s be honest: not everyone uses Ruby. I know, it hurts to hear, but it’s the truth. To get a general idea of how bad it really is, let’s look at indeed.com’s job trends for Ruby, Python, Java, and .NET, and assume that’s a good measure of usage:
Holy crap! Regardless of the actual numbers, we all know what this graph is saying to be true. But why are dynamic language’s so under-used? Aside from the obvious, like fear of something different, the dynamic language community hasn’t sufficiently answered the “why” questions to the other camp, like “Why should I use Ruby if I already know .NET?”, and “why even bother.” Our answer has always been “Productivity, expressiveness, blah, blah, blah”; that turns out to be a horrible way to sell dynamic languages to people who love C# or Java for it’s productivity and expressiveness. =) However, their fears are justified; Ruby’s main usage today is for stand-alone apps (mainly websites, but there are some client apps), so they assume Ruby can’t be use it in their existing environment.
Let’s solve this!
Let’s make it easy for those programmers at the top of the graph to use the languages at the bottom of the graph. Ruby gets to expand its ecosystem, and enterprise developers get a great dynamic language to use. Ruby is nicely position for this specific scenario since implementations of Ruby exist for both Java and .NET, so Ruby’s usage could become more on-par with Java and .NET. And here’s the way we make this happen: .NET and Java developers can easily embed Ruby into their existing applications for scripting.
All this also applies for Python, and IronPython is forging this path along with IronRuby. This talk was for a Ruby crowd … I hope you understand Michael :). But don’t worry, Dino Viehland has already begun brainwashing .NET developers for Python.
Also, since I work on IronRuby, I’ll be talking about this in relation to IronRuby and .NET from now on, though the same arguments work for JRuby and Java (and Jython). Check out the embedding JRuby page, and also how all this work in Jython.
The .NET people reading this might be smiling, but the Ruby people want to vomit … (maybe partly because of .NET, but in all seriousness) … because of the word “scripting”. I know, I too hate the negative associations “scripting” has; when I first started working at Microsoft I was openly against naming a component “Microsoft.Scripting”, but who listens to the new guy? For those who don’t get it, “scripting” makes these amazing languages sound like they are only useful for little toy things, and not for real work. Anyway, this plan takes advantage of that misconception, so don’t look at it as such a bad thing. :)
Why and How?
Ok, .NET developers, stop reading … you’ll ruin the surprise! Just kidding. I love you. Read on …
Since .NET developers see Ruby as a scripting language, it’s not a stretch to convince them that Ruby is good for embedding into their applications as a extensibility feature; allowing customize their application with bits of Ruby code. Here’s where all the Trojans jump out of the wooden horse. Getting Ruby into existing .NET applications is a much easier way for those developers to learn and use Ruby, rather than asking them to build a new app from scratch, or just look at tutorials, docs, etc, without having a good reason to. If .NET developers want to look at Ruby for use in their existing projects, then we’ve succeeded; it’ll then be pretty obvious that they can do real things with these so-called scripting languages. They’ll probably start using Ruby to prototype new features in their existing system, and then either keep that code as Ruby, or port some of it to their main language. Keep in mind, the goal isn’t to steal people from .NET – they would have left long ago like many of the Ruby community did – it’s to make Ruby co-exist with these more “enterprise” systems, and overall make software development fun again for everyone.
But how do .NET developers really benefit from having a scripting language they can use from their current environments? Three words: No More XML. XML seemed to be the solution to all .NET developer’s problems since it was a way to make their environments more dynamic. It is easy to parse and walk XML, making it also easy to attach some meaning to seemingly meaningless angle-brackets. One could implement anything using this technique, even logic. Which is why XML became a dynamic language and meta-programming tool for .NET. But really XML is a work-around to these static languages lacking the ability to be treated as both code and data.
Being able to use your code just like your data is liberating. For example, running Ruby code from just at string:
IronRuby supports the DLR Hosting API, a language-neutral script hosting API for .NET. For instance, supporting another is just as easy as changing the 2nd line to "IronPython".
Imagine doing this with XML; you’d have to somehow encode what element and field you want to modify, along the value to update it to, and then use something like reflection to interpret the XML and do the work. And that’s just for this simple example of setting the text of a TextBlock. So using a real programming language allows for endless extensibility-possibilities. Ruby is especially interesting since it can be simple enough for non-programmers, but powerful enough for adding full features.
Software which allows simple extensibility, like Firefox and Rails, tend to always create an ecosystem of extensions around them, which end up being one of the most compelling features of the program. Maybe that next app could be yours?