As somebody who has been using Ruby since over ten years (we are not using Rails) I would like to cast my vote on Ruby 1.8.8. I was reading http://url.ba/lxah about Ruby 1.8.6, 1.8.8 and 1.9.2 and 2.0. How can Ruby 1.8.6 be _too_ stable? I hope to get a reply from Yui Naruse http://url.ba/g8qu
We have a huge legacy application and it is not easy to shift from Ruby 1.8.6 to Ruby 1.9.2 – basically this will be a rewrite in many ways. Blame it on us but it is a fact.
So I am with Michael Fellinger who tried to think Oniguruma Style with Ruby 1.9.2 but got a bit burned and actually is dreaming of the Onigurama patch for Ruby 1.8.6 http://url.ba/39re we also need Regular Expressions and we also depend on the Oniguruma-Patch.
I know that Matz says that it is not a goal of Ruby to be consistent http://bit.ly/Y1bQT. I do not have a problem with that. But Matz should clearly decide when to be consistent and when not to be consistent.
Helping the developers to smooth the path but then clearly communicating when they will expect a break is good for everybody. If you look at the development process of the Linux Kernel, that is exactly what Linus Torvalds aims for. A smooth path with no bumps in the Road.
The Oniguruma-Patch helped a lot of people. It made their applications better. It improved the lives of their users. Why kill that good feeling just by saying Ruby-1.9.2 does not support Oniguruma 100%. Why always reinvent everything from Scratch? Well because it is fun. Well it is not always fun for the people who actually depend on Ruby for their daily lives.
I believe the point when not to be consistent is the change from Ruby 1.9 to Ruby 2.0. Please let the people know in advance.
Also see: http://url.ba/t2pu and the conversation is here: http://redmine.ruby-lang.org/issues/show/4239
One thought on “A vote for Ruby 1.8.8”
Well, that’s the tradeoff for using a relatively young and fast moving environment like the Ruby ecosystem. Same with Apple btw.. throwing away legacy sometimes hurts but often is a chance as well.. Adobe had to rewrite huge parts of its CS Suite from scratch – just because Apple went for Cocoa instead of their Carbon legacy… that’s a take it or leave it situation at end..
Therefore longterm is such an important part of the evaluation process for a specific platform. That’s why Java EE, Microsoft or also Red Hat are that successful and why it’s hard for Apple to enter the enterprise world (or why they don’t even try to enter that market besides some clients).
But at least there is some light at the end of the tunnel.. nobody will ever stop you running legacy and new systems side by side 😉
And the more robust and widespread Ruby gets the more it becomes a platform with providers for longterm support etc. as well… and the “cool guys” will move the the next hot thing – whatever it will be…