I'm not up for creative titles tonight. Hopefully you'll see this in your feed reader and click for a second opinion. Granted, I agree with Ola's IronRuby post on most points, but I disagree on a few key items. So let's dive in, shall we?
You managed to blog this viewpoint before me, Ola, but you know I agree with almost everything. However, to pour a bit more oil on the fire, I'll take it a step further.
Having run the Ruby gauntlet and brought JRuby from not running anything to running Rails almost 100% perfectly (in just over a year, I might add), I will confidently say there's no way with current specs and tests that anyone could create an implementation of Ruby from scratch that will run Rails unless they can look at the existing implementations. I simply do not believe it's possible.
And I'll throw another couple curve balls too:
- I don't believe tests and specs will be where they need to be within the next 6-12 months unless there's a major effort put behind them. Even if that effort happens, I still don't think we'll ever have specs enough for someone to implement Ruby "in the dark" for at least a year, if it ever happens.
- IronPython did a great job getting pretty close to 100% compatible. But Jim Hugunin had implemented an almost 100% Python-compatible implementation in Jython before going to Microsoft; he didn't need to look at the Python source. I don't believe John Lam has the same level of experience with Ruby, so he's at a severe disadvantage (and to John: I really feel for you, man...this has got to be difficult).
- This is a good friend's belief, but he's won me over: we don't believe Microsoft would ever willingly allow IronRuby to get to the point of running Rails, since that would directly compete with their ASP.NET server, software, and tool offerings. What would be the benefit to them of a free runtime running a free language implementation that runs a free web framework? Probably zero. And as Martin Fowler and others have blogged about NUnit, Microsoft hasn't exactly been lovey-dovey with OSS projects that impact (or are perceived to impact) their bottom line.
- Given these facts and the current situation, I'd say it's a better bet for us as a community to get behind the Gardens Point Ruby.NET Compiler project, which is already much farther along than IronRuby...plus it's real open source (you can contribute) and they can look at Ruby's source (and have admitted to doing so for at least the parser). I was wary/skeptical of Ruby.NET last year, but they now seem like the current best hope for Ruby on the CLR. That link again is Gardens Point Ruby.NET Compiler. And to the QUT guys working on Ruby.NET, you need to do three things right now to save your project from historical obscurity: set up a public source repository, accept a few external contributors, and start blogging and emailing up a freaking storm.
18 comments:
Where does this idea that John Lam isn't allowed to look at the Ruby source code come from? As far as I can tell it is only from Martin Fowler. Has anyone bothered to confirm this with John?
For IronPython, they test compatibility by running the Python test suite - which is *part* of the Python source code.
I'm counting this rumour as FUD until proved otherwise...
Hmm... apaarently it is confirmed, which is slightly bizarre.
"I don't believe tests and specs will be where they need to be within the next 6-12 months unless there's a major effort put behind them."
If I wrote 20 tests/day in my spare time for DPTS (already pushing 5000 tests) I estimate it would take at least 2 years to cover just the core classes.
I think you're looking at hiring someone full time on a 6 month contract if you really want an acceptable test suite.
How, exactly, does MS lose revenue by having Rails run on windows? It's not like you have to buy anything to get ASP.NET to run on a server.
It's not like you even have to buy anything to develop ASP.NET in a reasonably decent IDE, either.
If anything, being able to run Rails on a windows server might prevent companies from putting in something else.
@Code Monkey: I think you are missing the point. Developers don't pay for ASP.NET, but they do pay for VisualStudio. Microsoft's business model is based heavily on tying products/technologies together so that you have to buy something to use the free stuff.
A fully working Rails implementation on the CLR is probably a threat in the same way NUnit was: it gave developers a tool that was not directly tied to Microsoft's pay stack.
@ptoland : Visual Web Developer / Visual Studio Express mean that you don't necessarily have to pay to write .NET in a reasonably decent IDE (what I was referring to in my first comment).
If you don't have a windows server already, you won't be running Rails.NET (unless the performance is so much better that you end up considering buying a windows server to host on). If you already have a windows server, you'll probably either continue to use the free IDE you're using, or buy Visual Studio for its IronRuby/Rails support. Either way Microsoft has something to gain and nothing to lose.
The only way they lose for supporting Rails is if their implementation sucks and their decision to attempt to implement it legitimizes Rails more than it already is, causing others to flee the windows platform for something else to host their Rails apps on.
Given the number of people writing Ruby implementations, would it be worth everyone pooling their specs and tests to form a single canonical spec project? This would be particularly useful if it were, say, RSpec-based, so anyone doing their own implementation could execute the specification (and this would probably reduce arguments over compliance -- you either did or didn't pass the tests).
@faisal:
First, no one can agree on how to organize the tests. I prefer one test case per method (excepting aliases and bang methods). Others prefer a one file per class approach, which I find unwieldy.
Second, no one can agree on rspec or test-unit. I prefer the test-unit (I find rspec too verbose for about 80% of tests), but many others seem to prefer rspec these days. IMO, rspec was designed for behavioral tests, e.g. inheritence, mixins, observers, etc. It was not designed for simple return values, but it's the shiny new hammer on the block, and every test suddenly looks like a nail.
Lastly, tests are time consuming and most people hate writing them. I'm perverse in that I actually enjoy trying to break things. :)
IMHO, in order to get a real spec in a reasonable amount of time will take money.
John Lam is saying that they licensed the GP Ruby.Net Compiler
http://www.iunknown.com/2007/06/ironruby_and_ru.html
anonymous: They licensed the Ruby.NET codebase, which is certainly a great step forward. And they're learning from it to build out IronRuby, which means they've already made steps toward remedying the "can't look at open source" thing. So I think we've all been vindicated...Microsoft has started to make moves toward exactly the type of collaboration we said they'd need. It's good to see they're recognizing that collaboration is the right way to go.
What's up with these JRuby guys? They've got their panties wound in such a tight bunch that they're devolving into a bunch of nuts.
This is a good friend's belief, but he's won me over: we don't believe Microsoft would ever willingly allow IronRuby to get to the point of running Rails, since that would directly compete with their ASP.NET server, software, and tool offerings
Oh, you're "little friend" right? Yeah, it's a big conspiracy. Gates and Ballmer will personally order the crippling of IronRuby in order not to run Rails.
Given these facts and the current situation, I'd say it's a better bet for us as a community to get behind the Gardens Point Ruby.NET Compiler project...
Are you freaking kidding? There is no "us as a community". There's you working on JRuby.
A note to Sun executives. You better have a talk to these guys you hired, because they're really doing a disservice to Sun.
My organization will never run software developed by such dysfunctional people, such as Charles.
@mark: Personally I'm very interested in the opinion of someone who is obviously very skilled at implementing Ruby on another platform. I would believe 'us as a community' is interested too.
I'm *pretty* sure that John Lam said that getting IronRuby to run Rails was an explicit goal of the project.
Ican't provide a link though, sorry. :-(
And on the Microsoft tools subject...
At Resolver we are developing an IronPython application (our codebase is about 100k LOC, just over 3-1 test code to production code).
We use non-Microsoft tools to code with (several developers using free tools and a couple using a commercial Python IDE called Wing).
For our build process and the small amount of C# in our codebase, we recently switched away from the paid version of Visual Studio to the free version.
The switch was very little effort, only a few things were different.
The only major lack is the ability to connect to a running process and debug it. For mysterious crashes this is actually quite a big loss, and we are *considering* switching back.
Two things that may justify MS' implementation of Ruby: having people developing in .Net increases the chance they'll rely on other platform's libraries and languages, thus tieing them to the platform; and they're free to add/chance Ruby in order to create even more tie-in, like they tried to do with Java years ago, but much easier now with Ruby since it doesn't have a big company behind it to prevent such move nor even an official spec.
HEre we go, at least one quote of John Lam saying that IronRuby will support Rails:
http://channel9.msdn.com/ShowPost.aspx?PostID=304541
"Nobody would take our implementation seriously if it doesn't run Rails. But we've only been working on this for 4 weeks ..."
Well, technically he doesn't actually say it will run Rails...
Flame bait question - does anyone do anything else with Ruby anyway? ;-)
Sorry for the multiple posts. This is the quote I was thinking of:
http://blog.jonudell.net/2007/04/30/a-conversation-with-john-lam-about-the-dynamic-language-runtime-silverlight-and-ruby/
John Lam talking to John Udell just after the announcement:
"The DLR-based version of Ruby isn’t quite ready, and it doesn’t yet run Rails. That’s the acid test because, as John says, Rails uses every metaprogramming trick in the book. But the intent is to get it working, and I think that’s the kind of thing that’ll open up possibilities nobody can fully predict."
I talked with John Lam about IronRuby running Rails and he did say that was the plan. I firmly believe that he (and Microsoft) want at least as good of a Ruby implementation as JRuby.
Sorry for the shameless plug, but here is the podcast of me talking with John about IronRuby, looking at Open Source code, Rails, community contributions, and IDE integration: John Lam on IronRuby
Post a Comment