5 ms·
Rails is in a though spot right now. Facing a big challenge, a huge challenge even. And arguably, a challenge it didn't have to face. Why introduce a new VM an
by jd 18y ago
Rails is in a though spot right now. Facing a big challenge, a huge challenge even. And arguably, a challenge it didn't have to face.
Why introduce a new VM and break backwards compatibility at the same time? Why not first give people a better VM, with bytecode, better threads and all the other goodies? When people know that upgrading is painless (think Perl) then you can just upgrade without thinking twice about it. If you know you have to check the compatibility checklist of all software you have ever installed (for all you know your text editor depends on Ruby nowadays) then upgrading becomes a very unappealing task.
So, step one: introduce new VM. Step two, still don't break backwards compatibility. -If- you have to break the language, at least put some legacy mode in, so people don't have to port every script on their system.
- joe_the_user 18y agoWhy introduce a new VM and break backwards compatibility at the same time? I agree that "Big bangs" aren't always a good idea. However, what I believe is the case is - Any language geeks can feel to tell me I'm wrong here - is that the new VM benefited tremendously from making Ruby's syntax more regular. "MRI", Matzo's Ruby Interpreter, produced the unfortunate effect of making whatever its haphazard result were into "Standard Ruby". Making a faster interpreter that preserved all this stuff would be hard. So in this case, a "big bang", however painful, made sense
- Andys 18y agoThe incompatibilities that have hit hardest are for the modules that use C language extensions. This can't really be helped for such a major change to the underlying structure. The ruby language changes were mostly included in Ruby 1.8.7, and so most "pure ruby" libraries that worked there also work in 1.9.