3 ms·

So what is different about the Ruby approach to language evolution? The community has moved forward relatively painlessly from 1.8.x to 1.9.x to 2.x, all of whi

So what is different about the Ruby approach to language evolution? The community has moved forward relatively painlessly from 1.8.x to 1.9.x to 2.x, all of which had breaking changes. Why has change been such an issue for e.g. Python?

brudgers 11y ago
Strings are, to a first approximation, the universal interface among software components. Lots of source code relies on strings in non-obvious non-trivial ways. Breaking string compatibility is a big deal. That's why C hasn't and C++ didn't despite the pit of hurt that null terminated strings turned out to be. Instead, Unicode abstracts over stings. One could make a plausible argument that by opting for C-style strings, Python didn't get strings right. In fairness, Unicode was not mainstream when Python was on the drawing board and C-interop was and continues to be a way of achieving performance from interpreted languages. Anyway, by the time the problem was addressed, there was lots of Python in the wild. Then as now, most Python programs didn't need Unicode; and as is the case today, much of that code was written without thinking about the implementation details of strings. Even the most non-benevolent dictator can change the economics of legacy code bases by fiat. Legacy code has inertia, and in the case of working Python 2 code it's Python 2 that's broken not the working code. Switching non-trivial code to Python 3 comes with the risk of subtle highly coupled bugs in exchange for little more than an 'atta-boy or two. There isn't a meaningful performance improvement at the end of a refactoring hell. In the end, the business case for changing from Python 2 to Python 3 is weak for many users. Python 2 works fine for their needs. Python 3 may just generate more work: even setting up, running and managing two versions of Python is work [and for non-devops people, often non-trivial].
kbutler 11y ago
I think it's largely because ruby use is dominated by a single, pure ruby application domain: rails. Once rails supports the new version, it's easy to move. google "ruby programming" 3.5M hits and "ruby programming rails" 1.6M hits. In contrast, python has many different application domains, each with their own dependencies that need to be updated, and native code extensions are much more common. "python programming" 38M hits, no single application is a significant percentage.
- jeltz 11y ago
  We are not a rails shop but moving to 1.9 was almost entirely painless. I think that is because Ruby never did any release which broke everything. 1.9 did not break that much.
onli 11y ago
In addition to brudgers point about strings, which might very well be true, in Ruby it was never an option to stay on the old version. The mindset of a really stable Ruby version does not exist. If someone considers Ruby, he is fast made aware of the fact that it will be necessary to adapt the code to the new ruby version, probably. But since that is true for everyone, all the frameworks and gems do the same anyway, which makes it easier. But the breaks were not that big. And the new versions always had really cool features, so updating was really nice. It might be a mindset thing of Ruby developers.
- brudgers 11y ago
  It's not just versioning that's "unstable". Inspired by Smalltalk, Ruby allows developers to make (nearly?) any object respond to any message by extending the language. A pining-for-C-Rubyist can change String to add characters and nobody who doesn't have to live with the consequences need ever know or care.
dragonwriter 11y ago
> The community has moved forward relatively painlessly from 1.8.x to 1.9.x to 2.x, all of which had breaking changes. Why has change been such an issue for e.g. Python? 1.8.x to 1.9.x was a pretty traumatic break, not that dissimilar to Python 2.x to Python 3.x; Ruby got over it quicker because there was less heavily-used-but-basically-maintenance-mode Ruby software around to be broken by the breaking changes (that Ruby hadn't had nearly as long of a stable period without breaking changes as Python 2.x probably contributes to that.) The Ruby 1.8.x to 1.9.x conversion started sooner, too, and I think lots of people are viewing the past through rose-colored glasses on that. A lot of the discussions you still see with Python 2.x vs. Python 3.x -- including discussion of a desire for a long-term maintained fork of 1.8.x -- happened then. People just forget because Ruby got past it a while ago.

brudgers 11y ago

Strings are, to a first approximation, the universal interface among software components. Lots of source code relies on strings in non-obvious non-trivial ways. Breaking string compatibility is a big deal. That's why C hasn't and C++ didn't despite the pit of hurt that null terminated strings turned out to be. Instead, Unicode abstracts over stings. One could make a plausible argument that by opting for C-style strings, Python didn't get strings right. In fairness, Unicode was not mainstream when Python was on the drawing board and C-interop was and continues to be a way of achieving performance from interpreted languages. Anyway, by the time the problem was addressed, there was lots of Python in the wild. Then as now, most Python programs didn't need Unicode; and as is the case today, much of that code was written without thinking about the implementation details of strings. Even the most non-benevolent dictator can change the economics of legacy code bases by fiat. Legacy code has inertia, and in the case of working Python 2 code it's Python 2 that's broken not the working code. Switching non-trivial code to Python 3 comes with the risk of subtle highly coupled bugs in exchange for little more than an 'atta-boy or two. There isn't a meaningful performance improvement at the end of a refactoring hell. In the end, the business case for changing from Python 2 to Python 3 is weak for many users. Python 2 works fine for their needs. Python 3 may just generate more work: even setting up, running and managing two versions of Python is work [and for non-devops people, often non-trivial].

kbutler 11y ago

I think it's largely because ruby use is dominated by a single, pure ruby application domain: rails. Once rails supports the new version, it's easy to move. google "ruby programming" 3.5M hits and "ruby programming rails" 1.6M hits. In contrast, python has many different application domains, each with their own dependencies that need to be updated, and native code extensions are much more common. "python programming" 38M hits, no single application is a significant percentage.

jeltz 11y ago
We are not a rails shop but moving to 1.9 was almost entirely painless. I think that is because Ruby never did any release which broke everything. 1.9 did not break that much.

onli 11y ago

In addition to brudgers point about strings, which might very well be true, in Ruby it was never an option to stay on the old version. The mindset of a really stable Ruby version does not exist. If someone considers Ruby, he is fast made aware of the fact that it will be necessary to adapt the code to the new ruby version, probably. But since that is true for everyone, all the frameworks and gems do the same anyway, which makes it easier. But the breaks were not that big. And the new versions always had really cool features, so updating was really nice. It might be a mindset thing of Ruby developers.

brudgers 11y ago
It's not just versioning that's "unstable". Inspired by Smalltalk, Ruby allows developers to make (nearly?) any object respond to any message by extending the language. A pining-for-C-Rubyist can change String to add characters and nobody who doesn't have to live with the consequences need ever know or care.

dragonwriter 11y ago

> The community has moved forward relatively painlessly from 1.8.x to 1.9.x to 2.x, all of which had breaking changes. Why has change been such an issue for e.g. Python? 1.8.x to 1.9.x was a pretty traumatic break, not that dissimilar to Python 2.x to Python 3.x; Ruby got over it quicker because there was less heavily-used-but-basically-maintenance-mode Ruby software around to be broken by the breaking changes (that Ruby hadn't had nearly as long of a stable period without breaking changes as Python 2.x probably contributes to that.) The Ruby 1.8.x to 1.9.x conversion started sooner, too, and I think lots of people are viewing the past through rose-colored glasses on that. A lot of the discussions you still see with Python 2.x vs. Python 3.x -- including discussion of a desire for a long-term maintained fork of 1.8.x -- happened then. People just forget because Ruby got past it a while ago.