True. I think that Ruby as a language has been interesting for a lot of people for quite some time and, if you look at why Ruby, the language is interesting. To me there has always been this idea that it spends a generation gap of programmers, that the kids coming out of school now, you know the "I am going to take over the world" crowd, those guys are very excited about the Ruby. If you walk around, is kind of like the Rails scout for the average age is under 20, mid 20s butter folks, and they are very excited and very interested in the language. But what is also very interesting is that not just the young kids are interested into this thing, but guys being around the block for a while are also very interested into this language - and I'd like to use the example that I always use in my slide deck: Dave Patterson was one of the guys who invented a lot of things, being the one who invented random risk, and he is a professor at the Berkley and is a huge fan of Ruby.
In fact not only does he teach Ruby and Rails as a classical, but he is also using it to build data center operating systems, which is his area of research today. So it is interesting to see guys that have been around the block, as well as the kids that are fresh out of school, both being attracted to the qualities of the language. To take the ideas that make Ruby an attractive language and turn around and bring them to the .NET, as well as the Java programmers of the world, is also something that is very interesting. So there is ongoing work to make that happen. JRuby is a on the Java side out of the house, and also on our side of the house we have the IronRuby project, which is run by Microsoft.
There is a lot of ideas that, I think, are interesting for the dynamics and development of a bunch of scenarios. Ruby is a dynamic language, so as a dynamic language is very different from the language that they are used to program in - C#, VB. Those languages give you additional expressive power, which can be used in certain scenarios, which I think are very appealing, potentially. One of them is the testing on the side of the house. So more and more, in 2008, unit testing is not this wacky crazy thing that it used to be at one point in time.
Most people are using this and most people are running the tests. Using a dynamic language to test your statically typed libraries that you are building in C# or VB today, turns out to be a very useful thing and, if you look at some of the advances in testing that have happened in the Ruby world, there is actually some very interesting work that has been done there. Perhaps a leading candidate for mentioning is RSpec. In RSpec, the way a unit tests are written read very naturally, is a very fluent interface, you read your tests from left to right, "1+1.shouldEqual(2)", is the way you write that test, not "assert true 2, 1+1", which is the way you write it in C#, and that plus this soft documenting feature - the fact that the code reads very nice ends up being an excellent place to start entering into the .NET world, or the Ruby world as a .NET programmer.
Ruby makes it trivial for you to do marking as well, inside of the interfaces, so that is another place where you could potentially use Ruby to mark out some of your .NET objects as well that you might want to use in tests. Using Ruby as a marking framer is very simple because all classes and all objects are open to modification all the time. So for example, I can construct an object whose only role in life is to record all method calls to it and all the parameters, and do various assertions about it. To build a mock in Ruby is so simple, it is almost trivial, it is 5-10 lines of code to build a mock framework.
A real contrast to the kind of effort you have to do in .NET, there you have to do some more things, so I think that winds up being a really interesting place for at least .NET programmers to get started inside of Ruby.
Now, another angle that is interesting is this idea of the so called "polyglot programmer" and the fact that the software stack of the future or today - depending on how progressive you happen to be - is one where you have some statically typed stuff at the bottom layer, you have some dynamically typed stuff as the middle layer, and you have this top level layer of this thing called the domain specific language, or the DSL.
On the DSL piecewall, most likely being implemented in terms of the dynamic language layer, and the dynamic language layer is probably implemented in terms of the statically typed layer, in a world like that you allow people to do this DSL stuff at a high level. Like the RSpec example that I gave you earlier, it is an example of a domain specific language we are testing. There are some other cases, such as some of the build systems that are out there as well, so if you take a look at the build system today like ANT or MSBuild, they are all built on top of the XML, right in this way that we describe what a built thing looks like.
But these things are not really programs, when you get down to it, there are things that you have to break lower chunks of stuff that interact with your source control system or maybe do some float control, or some conditionals or some exception handling. In a world like that it is very challenging to do the content switching, because you are writing stuff in XML and your tasks are written in C# or VB or Java or whatever your language is that these things are building on top of. In addition, you have to put a high level logic right inside of XML which is horrible. I think the really interesting thing about using a language like Ruby, which has got a DSL for doing build things called Rake, and Rake is very good at describing declaratively or in a fashion that feels declaratively at least the relationships between different targets, or they call them tasks, but these things are really targets and mostly they build systems.
You always program in Ruby, you never context switch out into some other language like a C# or VB in order to do something, you always stay in Ruby and that makes it very useful. So thinking the testing angle and the build deployment angle, there are some very interesting places where you can do some Ruby programming to make your life simple, even if your core application that you are building continues to be built using whatever you are using today - C#, VB and other things. At least, what that is going to do is, that is going to give you some exposure to the ways in which you can think about problems in these domain specific languages, as well as in dynamic languages.
Depends on who you ask, lot of things: there are folks that have already solved the "preaching to the choir" thing. Certainly at this event here at ALT.NET, it really is preaching to the choir here. Other folks are skeptical and they are skeptical for perfectly valid reasons. About a month ago, I gave similar set of talks over to some folks in MSR, in our programming language and theory group. There is a bunch of PhD guys who think that C# is way too weakly typed for their purposes and needs and they want much more statically strongly typed systems and they want to be able to prove things, they want to be able to prove correctness and those are absolutely lofty goals and admirable goals to have, and it is very difficult to reconcile the two world views, one which is "software is crappy and sloppy" and kind of all thrown together, but the reality is that shipping software trumps all else, even if it is shipping software that doesn't necessarily work in all cases, but it works in the cases you tend to care about a lot.
There is definitely value to shipping, even at the expense of correctness in certain problem domains, and with the idea that down the road you can fix all those things. Certainly, if you take a look at start-up companies today, shipping is everything for those guys - they are heavily constrained resource wise and time wise, and they have to ship stuff as quickly as possible and they have almost all universally gravitated towards using dynamic languages as their way to build locations for the web tool stuff and the things that people are building today. So I think that in trying to deal with the nay-sayers, there are different tools for different jobs and there are cases where you need that absolute correctness and that preciseness that you only get from a statically typed language.
Maybe with some other theory improvers and their analysis tools that they have - and there are some very critical security tools or code or some of the base class libraries - it depends very heavily on having these things being provably correct. I see value in that, because most people are consuming that stuff and their job is to try and get applications being built quickly and inexpensively and deployed. Dynamic languages fill a very good role there as well.
3. I am sure that, generally, Ruby side of things has been much friendlier and reacting towards you.
You would be surprised by that, because I wouldn't say that people in Ruby community are hostile towards our efforts: I think it is worse than that. Cathy Sear, who was an awesome blogger back in the days when she was blogging before she went chased off the Internet, had this wonderful document where there was this diagram where she described "Where you don't want to be". On one end, there was "People love you" and on the other there was "People hate you" and in the middle there was this vast thing that she called "The zone of mediocrity".
When you are in the zone of mediocrity, or when people are indifferent to you, it is really bad. You really want people rather hate or love you, because, at least, when they hate you they care enough to hate you, but when they are indifferent, they think "It doesn't affect my life". That describes a reasonable chunk of the Ruby community, and by this community I would rather narrow it down to somewhat - say - the Rails community, because in their world they build Rails applications almost universally on Macs, if you go to Rails conf you find one or two crazy people that have Windows laptops, they are probably from Microsoft, and everybody else is just carrying a Mac.
They build on Mac, they deploy on Linux, that is the MO for building these kinds of applications and, because of that, we are just basically irrelevant to them, they are saying "It doesn't really impact my life one way or another". What we want to do is that we want to try and change all their perception and show them we can add some value even to their world. So you as a Rails programmer building your stuff on a Mac, deploy on Linux, you stole an opportunity to use some part of our stack because of Silverlight. Silverlight is a very interesting opportunity for folks on Rails who might want to be able to use Ruby on both ends of the wire, because today IronRuby is the only implementation with a good deployment story into the browser.
Now this good deployment story is predicating some of the things happening, like wide-spread adoption of Silverlight 2 and I think that this is going to happen, some of the things are going to happen in the summer, and also the efforts of the rest of the company is trying to expend. If we assume that Silverlight 2 is widely deployed, then you have this opportunity to run Ruby in the browser and for Rails applications that could involve doing interesting work, like having your views being in the browser, as your controllers being in the browser as well, and I think that, if there is a minimal amount of impact to the rest of your application logic and Rails application, this sounds a very compelling scenario for these guys, because now you are not dealing contact switching in the JS and other things, but, instead, you are doing Ruby programming and have to reach into different browsers and I think that scenario is something that they simply can do today.
4. Could you go more into the scalability themes you can reach from there?
Scalability is an interesting term, because it is overloaded to the N-th degree. I think what is interesting to the scalability angle is the idea that, if you initially built an application as a more traditional web app, that there is not so much AJAX and Rails allows you do that kind of stuff. If you discover all of a sudden that for whatever reason that doesn't scale particularly free well your needs, you now need to AJAXify the application, you need to add a lot of stuff, you are now in full world of hurt, because all of a sudden you are doing all sorts of stuff to add a JavaScript to your application and, as well, it is modifying the way your application behaves.
So it is not just a simple "I am going to switch a little bit a configuration and have the things running magically on the client", it is the "I know I got to rewrite big chunks of my application logic, which I already wrote to run on the server, so now I have to turn around and run on the client". It is unclear to me whether or not many applications today start off as being serviceable only one way with no job description on the part of the client, it seems that a lot of folks are probably starting out with that as a default assumption.
But for the folks that are in that first case, it buys them a very interesting avenue to hopefully make that migration to having larger chunks of a code run on the client, just much more straightforward because they are still on Ruby, and it is just literally a matter of hopefully making just some small changes toward the controllers without having a rewrite, which is what they are effectively having to do today.
The CLR obviously is a runtime that loves typed information: the more typed information you give it, the better and happier it is, and one of the efforts that led to the genesis of our team was around the difficulty in getting IronPython to run for the first time. When Jim Hugunin came to the company and started working on Python as a Microsoft employee, to the time that he end up finishing, which was a couple of years after he started, it was a lot harder than he felt it should have been, because there were a very large number of smart decisions that he had to make along the way in order to get acceptable performance or even superior performance in Python running on top of the CLR.
It was the feeling that it was much harder than it should have been that really led to this idea of the DLR and the genesis of the DLR. The next guy to come along they wanted to build a dynamic language on top of the dynamic runtime, but have a much easier time with it and have a greater chance of getting it right from the beginning. That was our experience with IronRuby. IronRuby was more like we were dog-feeding the idea, so certainly it would have been easier for us to build on top of the DLR rather than building from scratch.
The reality is that IronRuby forced a lot of changes under the DLR because the DLR started off as the IronPython runtime, so there were a lot of assumptions built into the way code gen happened and there are other things that were very Python-centric. Having Ruby being a different kind of dynamic language really forced us to do some fundamental changes in the DLR and that has all been for good, so I don't think we had the experience we wanted an external customer to have, but certainly getting Ruby to run on top of the DLR is a big statement to be made about the fact that it really is a dynamic language runtime and not just a Python language runtime.