Hacker News new | past | comments | ask | show | jobs | submit login

Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks".

For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash syntax changes in Ruby 1.9.

In any case, the current release is 5.4.4.

Sorry I couldn't grok what your opinion on semver was.

Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible).

PHP made an backwards incompatible change in their code so it should have been a major version increase.

So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver.

Is that not your opinion?

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.

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.

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.

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.

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.

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions".

All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had code that's hard to change or adapt. Hey, one of the examples the OP posted is "we had code relying on an obvious parser bug, and it breaks since they fixed it." So well, call it "dismiss" if you want. I call it "evolving a language"

I've been working with ruby at the point when 1.8 moved to 1.9 and it was quite a change. Pretty much every library that handled strings broke, but I don't see any way around that and still get encoding support. Many people actually forget that ruby 1.9 is actually what should have become 2.0.

I've been affected and patched several libs to work properly with 1.9.[1] There's absolutely no reason to become snarky.

[1] most of the changes required were trivial, still it's breaking and annoying.

Fair enough, I apologize for the snark, but then everything you've said hinges on your interpretation of the word "obscure".

Looking at the sibling comment, I'll happily take back the word "obscure" if it sounds too negative and subjective. But I stand by my opinion that Ruby is unstable because most of the above changes could have been handled in a backwards compatible way (for non-pathological cases). That should-be 2.0 was turned into 1.9 does not help :)

Not that stability is always the right choice, I wish C++0x would have been more radical, for example. It does matter for long-lived codebases though.

Well, 1.9 was the "unstable" branch leading up to 2.0, that's why that actually matters. And that's why most of those changes were made at that point - they were intended to land in 2.0. Later the decision was made to roll 1.9 as a stable release since 2.0 would take another couple of years and encoding support was an important feature that people wanted to ship. So a lot of changes that could not be handled in a BW-Compatible way landed in 1.9 since encoding support required those changes. String all of sudden was not enumerable any more since there was now String#each_byte and String#each_char which did something different. Require was changed because loadable encodings were an attack vector, ... But for people that needed the old behavior 1.8 was supported until lately and REE (1.8 patched) is still supported.

The breakage in 1.8.6/1.8.7 was widely regarded as a massive failure on the maintainer side - a bugfix for a security vulnerability that had other changes land in the release (and subsequently segfaulted, sigh). That's however not a design change. Something like that has never happened ever since.

I actually agree with you up to a certain point: The ruby ecosystem is was and still is pretty unstable. Things have settled a little lately, but gems still appear and disappear, are superseeded by newer versions or other gems that do things differently. That's good in some ways, since stuff evolves and improves, bad in other ways - the lib you depend on just disappears or falls out of maintenance. However, none of this is the core-languages fault. Behavior of ruby as a language has been pretty stable during the last couple of years.

Hahaha. People wouldn't complain. That's a knee slapper.

No more preposterous than software without bugs.

At that point I'd start making fun of your username ;)

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.

The following does not work anymore in 1.9 (at least when it was released, who knows if they reverted the change):

    {"a", "b"}
And there were plenty of gems and small scripts online I was able to get working just fine under 1.8.7 but not 1.9. Thankfully that is largely no longer the case, as things have been updated or replaced.

String class was also given a nice kick in the ass, at least in regards to iteration.

Would you say that these were not backwards incompatible changes? Code that worked before stopped working. Breaks BC in my book. And in both cases the changes were arguably for the better.

- Stop writing code with uninitialized variables - Stop iterating over stuff that shouldn't be iterated over in that way

As far as why the changes were thus, it was decided to destroy PHP 6 - do people still write books about that? - and port every change other than unicode support down to 5.x. Someone feel free to correct me on that point.

It doesn't work in the latest 1.9 either. It was a bizarre syntax that hardly anyone used from my experience (I've been a library-oriented Rubyist for several years and never saw it in production code.)

However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..

I don't "really mind" if it breaks totally (i.e. throws an appropriate exception or doesn't parse the syntax check).

I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.

Passing in an empty string to a function that states it takes float as it's argument is certainly an edge case the developer should have thought of.

The again, in PHP, interpreting strings as floats is not unusual and pretty well defined. So in PHP it's also a case the developer could have considered normal in his expectation that PHP would behave as usual (and it did, prior to 5.3, for this precise function)

Not for user-provided input. That's just a dumb thing to do in any language.

Probably. But then again, we're talking about a language where THIS happens:

php> echo "2coolforschool" + 1;


php> echo "2.1coolforschool" + 1;


php> echo "coolforschool" + 1;


So treating all kinds of garbage as valid numbers is absolutely part of PHP.

That's just the general design philosophy of the MP components of the LAMP stack.

Do the stupidest thing that could possibly work; and it probably will. For now.

> Not for user-provided input.

Not what for user-provided input? The source of a string does not matter to this rule of PHP: a string used in numeric context will be parsed and converted, if it can not be parsed as a number its numeric value will be 0. That's it. That's how the language defines strings in numeric contexts.

> That's just a dumb thing to do in any language.

Sure, you won't get any argument from me on that, but that remains how PHP works and has always worked.

It doesn't matter anyway. Semver is just a practice and not one everyone has or must sign up to, especially in its official form.

Further, you're right about Ruby 1.9's hash syntax, although in the interests of accuracy, it's more accurate to consider it an additional syntax. It certainly doesn't replace the existing one (indeed, hashes notated in the new style get returned in the old style with #inspect) and I don't believe there are plans to ever remove the standard syntax.

Why would you expect PHP releases to adhere to rules that some guy threw together? Especially considering PHP has about a decade of history using the numbering scheme they do use.

Neither Ruby nor, as far as I know, PHP follow semver. Historically all bets have been off when it comes to breaking changes on "minor" releases.

are people really looking to this as a reason why php sucks? i thought the point of the post was to mock the "bug" reporter and his clueless sense of entitlement.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact