4 ms·

Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know. In one patchlevel of 1.8.6, they've added a check again

Somewhere around Ruby 1.8.6, the stdlib Digest::MD5 syntax changed without any explanation that I know. In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once. Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did. Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different. Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport. And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.) Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit. Ruby is a bad example.

josegonzalez 14y ago
I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all. Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.
- iamumassthrower 14y ago
  Hahaha. People wouldn't complain. That's a knee slapper.
  - sirclueless 14y ago
    No more preposterous than software without bugs.
  - josegonzalez 14y ago
    At that point I'd start making fun of your username ;)
- gurkendoktor 14y ago
  I just wanted to reinforce that Ruby and PHP are equally unstable languages. Most changes in my list aren't bugs at all, just obscure design decisions. Even the new Hash literals are likely complicit in breaking the "when X:" syntax that I'd heavily relied on. The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.
  - Xylakant 14y ago
    None of the decisions listed here were "obscure" design decisions and none of your examples indicates that ruby is unstable. Specifying the source encoding in 1.9 is only required if you have string literals in your code that are not in the default encoding. That should be a rather rare case, in fact pretty much none of my code files has the encoding header. Ruby 1.8 was not encoding aware, so Strings were just pure byte streams and the encoding didn't matter. Changing the way require works fixed a potential attack against ruby scripts. Effectively the only thing that was changed was that from that point on the working directory was not included in the loadpath any more. Calling `ruby -I . <script>` reverts to the previous behavior. Backporting require_relative is not a sensible decision, 1.8 has reached EOL. If you need to write code that compatible to both ruby versions, just don't use it. It's nothing but a convenience method (in fact, most libraries just use a proper LOAD_PATH setup and don't use it). Since 1.9.2 was the first stable release of the 1.9. branch it's fair enough at that point. Breaking the extension API between 1.8 and 1.9 is fair enough as well since Ruby 1.9 is a new major release. Ruby's versioning works different than PHPs. A minor PHP release (5.3.1 -> 5.3.2) would be a patch release in ruby (1.9.3-p0 -> 1.9.3-p125). Breaking changes are required at some point. 1.9 added more breaking changes, such as String not being enumerable any more etc. Most of those were required to add encoding support, which was the big and important feature added at that time. All in all I must say that the only large-scale breakage of existing code I've witnessed in the ruby world was the 1.8 -> 1.9 transition.
    - Tloewald 14y ago
      So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about. Well played, sir.
rurounijones 14y ago
Yep, all those are true, I wasn't thinking. I was just focused on the hash syntax statement, thank you for all the good examples.

josegonzalez 14y ago

I used it as the example simply because it is normally a language that is touted quite superior to PHP. I think it is better in some regards - building/using Ruby DSLs is awesome - but not all. Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.

iamumassthrower 14y ago
Hahaha. People wouldn't complain. That's a knee slapper.
- sirclueless 14y ago
  No more preposterous than software without bugs.
- josegonzalez 14y ago
  At that point I'd start making fun of your username ;)
gurkendoktor 14y ago
I just wanted to reinforce that Ruby and PHP are equally unstable languages. Most changes in my list aren't bugs at all, just obscure design decisions. Even the new Hash literals are likely complicit in breaking the "when X:" syntax that I'd heavily relied on. The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.
- Xylakant 14y ago
  None of the decisions listed here were "obscure" design decisions and none of your examples indicates that ruby is unstable. Specifying the source encoding in 1.9 is only required if you have string literals in your code that are not in the default encoding. That should be a rather rare case, in fact pretty much none of my code files has the encoding header. Ruby 1.8 was not encoding aware, so Strings were just pure byte streams and the encoding didn't matter. Changing the way require works fixed a potential attack against ruby scripts. Effectively the only thing that was changed was that from that point on the working directory was not included in the loadpath any more. Calling `ruby -I . <script>` reverts to the previous behavior. Backporting require_relative is not a sensible decision, 1.8 has reached EOL. If you need to write code that compatible to both ruby versions, just don't use it. It's nothing but a convenience method (in fact, most libraries just use a proper LOAD_PATH setup and don't use it). Since 1.9.2 was the first stable release of the 1.9. branch it's fair enough at that point. Breaking the extension API between 1.8 and 1.9 is fair enough as well since Ruby 1.9 is a new major release. Ruby's versioning works different than PHPs. A minor PHP release (5.3.1 -> 5.3.2) would be a patch release in ruby (1.9.3-p0 -> 1.9.3-p125). Breaking changes are required at some point. 1.9 added more breaking changes, such as String not being enumerable any more etc. Most of those were required to add encoding support, which was the big and important feature added at that time. All in all I must say that the only large-scale breakage of existing code I've witnessed in the ruby world was the 1.8 -> 1.9 transition.
  - Tloewald 14y ago
    So you dismiss a bunch of valid breaking changes because you weren't affected by them and then cite one you know about. Well played, sir.

rurounijones 14y ago

Yep, all those are true, I wasn't thinking. I was just focused on the hash syntax statement, thank you for all the good examples.