10 ms·

Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've

Rasmus comes across as a little kid. Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure." Perhaps it isn't about being paid, but about taking pride in the work you do. PHP is convenient. I use it for some piddly shit because that's what it's good for. This bug report highlights the problems you run into if you use it for serious work.

pelotom 14y ago
Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.
- masklinn 14y ago
  > APIs are allowed to change in major releases On the other hand, significant breakage of 10 years-old APIs with not even release notes...
  - gcb 14y ago
    ...of undocumented behaviour.
  - earl 14y ago
    tools shouldn't rely on undocumented behavior when passing out-of-spec parameters into functions. Relying on such behavior eventually gets you what you deserve.
    - masklinn 14y ago
      Or one could expect the language to behave coherently (tall orders for PHP, I know) and consider that it will use whatever is provided to it in the usual manner in which it treats non-numbers in a number context. Especially when the function has behaved in this manner for a decade.
      - RobAley 14y ago
        As you note, one of the problems most cited with PHP is core language functions behaving in a non-coherent/non-consistent manor. This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. It was documented, done in a major release, and done alongside a number of other (well publicised) breaking changes. Not everyone is going to be happy when things change, but I think this was a sensible development decision for the PHP team.
        masklinn 14y ago
        > This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. Well technically I believe it was done to unify argument parsing, but so far so good. > to make it behave more coherently/consistently. except this made all argument parsing (and especially this function) less coherent and consistent with PHP-the-actual-language: in PHP userland code, a string in a numeric concept will be implicitly converted to a number (to 0 if it is not prefixed by digits). This function used to behave coherently with PHP itself, as a language. Now it doesn't anymore. So all built-ins behave one way, the language itself behaves in the opposite way. > It was documented Not really, there was a note indicating plenty of shit broke (and it was ambiguous, the note says things about passing in incompatible parameters, but as far as PHP-the-language goes strings are compatible with floats), not listing functions which broke and in which manner.
        RobAley 14y ago
        With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rather than these few, but that would have messed up a lot more userland code than this change did. I think it was the most pragmatic way of dealing with the issue. With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways). Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.
  - LawnGnome 14y ago
    Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.
    - masklinn 14y ago
      > Even given that it was undefined behaviour to start with On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One could therefore expect the relevant coercitive calls to be performed as they would usually be. > it's the very first incompatible change listed It is very ambiguously worded: the clause states functions will return NULL when passed incompatible parameters, but in all of PHP's userland code strings are very much compatible with floats. I would therefore submit that — in the context of being a user of PHP — the clause does not apply to this case as the value passed in is absolutely compatible with parameter expectations.
      - rapala 14y ago
        "high-level languages have no reason to have UBs, especially for the trivial calling of a core function" What should a lisp implementation return when (car '()) is evaluated? How does a arbitrarily chosen return value differ from a undefined behavior? Is "" -> 0 a standard conversion in PHP? I get it if we consider the groups (String, +) and (Float, +), but 0 is hardly the standard identity value.
        masklinn 14y ago
        > How does a arbitrarily chosen return value differ from a undefined behavior? In it being defined, don't you think? > Is "" -> 0 a standard conversion in PHP? Erm... yes? `(float)""` returns that, `"" + ""` returns that, `0 + ""` returns that, and so do `intval('')`, `(int)''` or `floatval('')`. More generally, http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion http://www.php.net/manual/en/language.types.string.php#langu...: > When a string is evaluated in a numeric context, the resulting value and type are determined as follows [...] The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero). > 0 is hardly the standard identity value. 0 remains the standard and defined numeric value of an arbitrary string not prefixed with numeric data in PHP.
- aklofas 14y ago
  sed s/PHP/Ruby/g :)
masklinn 14y ago
> We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. Well that's pretty much PHP in a nutshell, no news there.
- mcrittenden 14y ago
  I'm pretty disappointed to see comments like these around here, and not getting downvoted. This comment adds nothing to the conversation, and criticizes PHP with no factual basis or explanation.
  - soc88 14y ago
    Why? He said that the design principle of this method is in line with the rest of PHP, that's a correct and valid observation.
    - xd 14y ago
      So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want? It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC. Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings of an obviously very inexperienced developer.
      - soc88 14y ago
        “Patching up” would suggest that they actually improved the situation. If you had read the diff you would realize they did not.
        xd 14y ago
        The change was an improvement .. I'm not sure what point you are trying to make? Maybe I misunderstood you or you don't understand the change.
soulclap 14y ago
Bad code style will eventually get you in trouble in any language or environment, bugs can occasionally turn into features and updates will always require testing, this is not a PHP specific problem at all.
astrodust 14y ago
I think the actual translation is: "You're writing retirement planning software and you can't even handle changing a method call that's been patched to a version of your own creation which preserves the legacy behavior? Get a new job."
martenshinwarts 14y ago
"This bug report highlights the problems you run into if you use it for serious work." Indeed. Passing an empty string for a parameter which is expected to be a float is SUCH serious work. "if it breaks your stuff then tough shit because we're a bunch of amateurs." You say that, but it rather seems like it broke amateur code.
- Draiken 14y ago
  Unfortunately PHP is consistently inconsistent. It lets people do that, and it won't ever break. Until they "make it right". Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised, and that never happened until the fix. That's the big problem with PHP :/
  - martenshinwarts 14y ago
    "Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised" Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time? Any language that can do anything also allows you to shoot yourself in the foot. And I think that was the case here, brainless programming; PHP hardly pulled out the rug under something reasonable in this case, they simply defined previously undefined behaviour... and when that happens, that always breaks crappy programs that depended on it, no matter in what language they're written. It's the big problem with idiots; PHP has nothing to do with it.
    - cube13 14y ago
      >Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time? Because the input is a text box? Text is, after all, the way for people to input data into a computer.
      - jdjb 14y ago
xd 14y ago
"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.
- jbm 14y ago
  Don't sweat it. Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress). I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around with servers in order to perform my job. The critiques of the language aren't baseless, but plenty of large startups manage to do just fine with PHP. TLDR: Languages are meaningless penis measuring contests of the IT world. If you will ship faster and better with language X, go ahead and use it.
  - mogui 14y ago
    words full of wisdom, sir
  - Beltiras 14y ago
    Which is why you should use Python, not PHP ;) (Penis submitted for measurement)
    - deleted 14y ago
      [deleted]
  - spacemanaki 14y ago
    > If you will ship faster and better with language X, go ahead and use it. Absolutely, by all means, go for it. Godspeed. > Languages are meaningless penis measuring contests of the IT world. No they're not, and this is just insulting. I'm only an amateur PL nerd but there are people who have devoted their lives and careers to studying languages and thinking about the differences between them and how to design something practical, consistent, logically sound, beautiful, etc. To brush aside that work as meaningless is pretty narrow-minded. After all, some of that work helped even lowly PHP to stand taller on the shoulders of giants, and make it even possible to be a reasonable tool.
gizzlon 14y ago
"This bug report highlights the problems you run into if you use it for serious work" Why? Because they fix bugs that break backwards compatibility? What's your point? That to do "serious work" you need a language that never changes or that you need a language that gets everything right the first time? Of course can do whatever you want in PHP, you just need to account for its faults and shortcomings. If you cant do that, no language is going to save you.
- gbog 14y ago
  It is not about getting everything right the first time,it's about getting the basic things right the first time.
j_col 14y ago
> I use it for some piddly shit because that's what it's good for So do Facebook.
- gbvb 14y ago
  And his point still stands. :) Could not resist.
  - j_col 14y ago
    I know you're joking, but his point is very badly made. Anything that can support ~1 billion users is not piddly. Facebook are doing amazing work with PHP, as are many others at a very large scale. Why the unpaid work of Rasmus and many, many other open source contributors like him, who's hard work facilitated the growth of massive web sites like Facebook, is constantly being ridiculed on threads like this is sickening.
    - gbvb 14y ago
      I agree. I was commenting on Facebook "the social network" and not Facebook the "technology".. :) Anything that can be made to support such large transactions (be it with duct tape and glue) has to have a core capability to support such usage.
      - nbm 14y ago
        It is important to keep in mind that Facebook isn't just a single PHP code base, and thus one can't really make many assumptions about how well PHP is suited to solving certain problems because one doesn't necessarily know about which bits are implemented in PHP, or whether PHP is just a templating/rendering stage over work done elsewhere. Some other languages might allow you to do certain operations in the front-end more easily, but the way to approach it when using PHP might be to delegate that to a back-end service in another language. Similarly, some languages might allow you to write both most front-end and most back-end software in the same language, where PHP might be wholly unsuitable or makes certain things harder to achieve than it is worth using it for (maybe strict memory usage control, maybe where you're looking for CPU cache wins).
jheriko 14y ago
i think you miss the larger point... any half way decent developer would never have this issue - breaking changes happen on every platform - or you should assume they will. use encapsulation properly (i.e. actually encapsulate, not just use a keyword meaning 'class' in the OO sense) and problems like this require single line of code changes to fix. even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency, then encapsulate it, then fix. even on multi-million line code bases this will not take a month. inexperienced programmers are terrible at estimating tasks like this, which often take less time than you think, and less time than it feels has passed as you are doing them. php is a fine language - the various arguments i've heard against it boil down to "i'm to shit of a programmer to do my job", either by choosing the wrong technology or not being able to just suck it up and get on with making stuff work.
- Terretta 14y ago
  > even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency Take this line of reasoning far enough, and you're saying wrap every PHP function in your own function, so your programmers program in your synonym language instead of PHP, something like CoffeeScript vs JavaScript, perhaps. I don't think using PHP (or any language) directly means you're a "shit programmer". I think the care Python has taken between 2.x and 3.x is a better example of the type of care and concern and community awareness building around this exact sort of change that a language's benevolent dictators (Larry, Rasmus, Guido) should take when altering the philosophy of how the language should behave.
  - gbog 14y ago
    > wrap every PHP function in your own function That's what I did or tried to do when working with PHP. At least on sensitive parts (date, string, database functions).
    - columbo 14y ago
      Hrm... if you don't trust your core to that extent... then why use it?
sp332 14y ago
The behavior was deprecated with a warning for how many versions?
GlennS 14y ago
I disagree completely. This is example of the PHP team working to fix a common criticism of their language: that it's full of inconsistencies. And when encountering push-back from users who depend on those inconsistencies, the developers have stuck to their guns. Well played to Rasmus.
- Domenic_S 14y ago
  Indeed. "PHP is full of inconsistencies! What a terrible, amateur language!" fixes inconsistencies "PHP broke their functions! What a terrible, amateur language!" Haters gonna hate.
batista 14y ago
>Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code Really? You read it wrong. It is "he have a public API that had a bug --that only surfaced when using it in a brain damaged way, anyway-- and we fixed it along with doing several DRY improvements to our code base. We also gave ample time of advance warning with our beta releases". "so if it breaks your stuff then tough shit because we're a bunch of amateurs." An ad-hominem? And its Rasmus that cones out as a little child, to your "mature" reading of the situation? Priceless. >I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure." Perhaps it isn't about being paid, but about taking pride in the work you do. That includes fixing bugs and brain damaged edge cases of the public API. The complainer and your reading are so off the mark, I can't even begin to comprehend such attitudes exist...
larrys 14y ago
"Perhaps it isn't about being paid, but about taking pride in the work you do." Even if you take pride in what you do you expect to be treated with a certain level of respect. ( Not that being paid means you should be disrespected of course. )

pelotom 14y ago

Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.

masklinn 14y ago
> APIs are allowed to change in major releases On the other hand, significant breakage of 10 years-old APIs with not even release notes...
- gcb 14y ago
  ...of undocumented behaviour.
- earl 14y ago
  tools shouldn't rely on undocumented behavior when passing out-of-spec parameters into functions. Relying on such behavior eventually gets you what you deserve.
  - masklinn 14y ago
    Or one could expect the language to behave coherently (tall orders for PHP, I know) and consider that it will use whatever is provided to it in the usual manner in which it treats non-numbers in a number context. Especially when the function has behaved in this manner for a decade.
    - RobAley 14y ago
      As you note, one of the problems most cited with PHP is core language functions behaving in a non-coherent/non-consistent manor. This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. It was documented, done in a major release, and done alongside a number of other (well publicised) breaking changes. Not everyone is going to be happy when things change, but I think this was a sensible development decision for the PHP team.
      - masklinn 14y ago
        > This change was in-fact to bring this particular function in line with most of the others, i.e. to make it behave more coherently/consistently. Well technically I believe it was done to unify argument parsing, but so far so good. > to make it behave more coherently/consistently. except this made all argument parsing (and especially this function) less coherent and consistent with PHP-the-actual-language: in PHP userland code, a string in a numeric concept will be implicitly converted to a number (to 0 if it is not prefixed by digits). This function used to behave coherently with PHP itself, as a language. Now it doesn't anymore. So all built-ins behave one way, the language itself behaves in the opposite way. > It was documented Not really, there was a note indicating plenty of shit broke (and it was ambiguous, the note says things about passing in incompatible parameters, but as far as PHP-the-language goes strings are compatible with floats), not listing functions which broke and in which manner.
        RobAley 14y ago
        With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rather than these few, but that would have messed up a lot more userland code than this change did. I think it was the most pragmatic way of dealing with the issue. With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways). Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.
- LawnGnome 14y ago
  Even given that it was undefined behaviour to start with, it's the very first incompatible change listed at http://au2.php.net/manual/en/migration53.incompatible.php http://au2.php.net/manual/en/migration53.incompatible.php — you'd hope a professional developer would at least glance at that document when migrating a codebase to 5.3.
  - masklinn 14y ago
    > Even given that it was undefined behaviour to start with On the other hand, 1. high-level languages have no reason to have UBs, especially for the trivial calling of a core function and 2. one could expect behavior in this context to be coherent with behavior in userland contexts. In PHP, using strings in a numeric context wasn't — last time I checked — considered abnormal, no matter how little sense it makes. One could therefore expect the relevant coercitive calls to be performed as they would usually be. > it's the very first incompatible change listed It is very ambiguously worded: the clause states functions will return NULL when passed incompatible parameters, but in all of PHP's userland code strings are very much compatible with floats. I would therefore submit that — in the context of being a user of PHP — the clause does not apply to this case as the value passed in is absolutely compatible with parameter expectations.
    - rapala 14y ago
      "high-level languages have no reason to have UBs, especially for the trivial calling of a core function" What should a lisp implementation return when (car '()) is evaluated? How does a arbitrarily chosen return value differ from a undefined behavior? Is "" -> 0 a standard conversion in PHP? I get it if we consider the groups (String, +) and (Float, +), but 0 is hardly the standard identity value.
      - masklinn 14y ago
        > How does a arbitrarily chosen return value differ from a undefined behavior? In it being defined, don't you think? > Is "" -> 0 a standard conversion in PHP? Erm... yes? `(float)""` returns that, `"" + ""` returns that, `0 + ""` returns that, and so do `intval('')`, `(int)''` or `floatval('')`. More generally, http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion http://www.php.net/manual/en/language.types.string.php#langu...: > When a string is evaluated in a numeric context, the resulting value and type are determined as follows [...] The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero). > 0 is hardly the standard identity value. 0 remains the standard and defined numeric value of an arbitrary string not prefixed with numeric data in PHP.
aklofas 14y ago
sed s/PHP/Ruby/g :)

masklinn 14y ago

> We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code so if it breaks your stuff then tough shit because we're a bunch of amateurs. Well that's pretty much PHP in a nutshell, no news there.

mcrittenden 14y ago
I'm pretty disappointed to see comments like these around here, and not getting downvoted. This comment adds nothing to the conversation, and criticizes PHP with no factual basis or explanation.
- soc88 14y ago
  Why? He said that the design principle of this method is in line with the rest of PHP, that's a correct and valid observation.
  - xd 14y ago
    So how would you propose changes are made to an "API"? Never? The change was made in a new version, with the changes clearly laid out in the changelog .. what more do you want? It's funny. PHP gets a bashing for the rotten bits .. when the rottern bits get patched up it gets a bashing for breaking BC. Anyway, I don't think you understand just how empty that attack was. Frankly it was nothing more than the ramblings of an obviously very inexperienced developer.
    - soc88 14y ago
      “Patching up” would suggest that they actually improved the situation. If you had read the diff you would realize they did not.
      - xd 14y ago
        The change was an improvement .. I'm not sure what point you are trying to make? Maybe I misunderstood you or you don't understand the change.

soulclap 14y ago

Bad code style will eventually get you in trouble in any language or environment, bugs can occasionally turn into features and updates will always require testing, this is not a PHP specific problem at all.

astrodust 14y ago

I think the actual translation is: "You're writing retirement planning software and you can't even handle changing a method call that's been patched to a version of your own creation which preserves the legacy behavior? Get a new job."

martenshinwarts 14y ago

"This bug report highlights the problems you run into if you use it for serious work." Indeed. Passing an empty string for a parameter which is expected to be a float is SUCH serious work. "if it breaks your stuff then tough shit because we're a bunch of amateurs." You say that, but it rather seems like it broke amateur code.

Draiken 14y ago
Unfortunately PHP is consistently inconsistent. It lets people do that, and it won't ever break. Until they "make it right". Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised, and that never happened until the fix. That's the big problem with PHP :/
- martenshinwarts 14y ago
  "Sure the guy didn't test the parameter as being empty, but if you pass a string instead of a float, an error should be raised" Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time? Any language that can do anything also allows you to shoot yourself in the foot. And I think that was the case here, brainless programming; PHP hardly pulled out the rug under something reasonable in this case, they simply defined previously undefined behaviour... and when that happens, that always breaks crappy programs that depended on it, no matter in what language they're written. It's the big problem with idiots; PHP has nothing to do with it.
  - cube13 14y ago
    >Just like you should not pass strings in place of numbers, in accounting software of all things. Why can't just everbody get it absolutely right the first time? Because the input is a text box? Text is, after all, the way for people to input data into a computer.
    - jdjb 14y ago

xd 14y ago

"I use it for some piddly shit because that's what it's good for." The bigotry from this community when it comes to PHP has left me sick to my stomach.

jbm 14y ago
Don't sweat it. Some of the people who raise the biggest fuss about PHP are also people who never dealt with it (except through Wordpress). I mostly program in Python these days, but I used PHP for years beforehand without much drama. I even enjoyed it at times. Yes, I do have a Comp Sci bachelors degree and I probably should care more - but I found it a lot more interesting not to have to deal with fiddling around with servers in order to perform my job. The critiques of the language aren't baseless, but plenty of large startups manage to do just fine with PHP. TLDR: Languages are meaningless penis measuring contests of the IT world. If you will ship faster and better with language X, go ahead and use it.
- mogui 14y ago
  words full of wisdom, sir
- Beltiras 14y ago
  Which is why you should use Python, not PHP ;) (Penis submitted for measurement)
  - deleted 14y ago
    [deleted]
- spacemanaki 14y ago
  > If you will ship faster and better with language X, go ahead and use it. Absolutely, by all means, go for it. Godspeed. > Languages are meaningless penis measuring contests of the IT world. No they're not, and this is just insulting. I'm only an amateur PL nerd but there are people who have devoted their lives and careers to studying languages and thinking about the differences between them and how to design something practical, consistent, logically sound, beautiful, etc. To brush aside that work as meaningless is pretty narrow-minded. After all, some of that work helped even lowly PHP to stand taller on the shoulders of giants, and make it even possible to be a reasonable tool.

gizzlon 14y ago

"This bug report highlights the problems you run into if you use it for serious work" Why? Because they fix bugs that break backwards compatibility? What's your point? That to do "serious work" you need a language that never changes or that you need a language that gets everything right the first time? Of course can do whatever you want in PHP, you just need to account for its faults and shortcomings. If you cant do that, no language is going to save you.

gbog 14y ago
It is not about getting everything right the first time,it's about getting the basic things right the first time.

j_col 14y ago

> I use it for some piddly shit because that's what it's good for So do Facebook.

gbvb 14y ago
And his point still stands. :) Could not resist.
- j_col 14y ago
  I know you're joking, but his point is very badly made. Anything that can support ~1 billion users is not piddly. Facebook are doing amazing work with PHP, as are many others at a very large scale. Why the unpaid work of Rasmus and many, many other open source contributors like him, who's hard work facilitated the growth of massive web sites like Facebook, is constantly being ridiculed on threads like this is sickening.
  - gbvb 14y ago
    I agree. I was commenting on Facebook "the social network" and not Facebook the "technology".. :) Anything that can be made to support such large transactions (be it with duct tape and glue) has to have a core capability to support such usage.
    - nbm 14y ago
      It is important to keep in mind that Facebook isn't just a single PHP code base, and thus one can't really make many assumptions about how well PHP is suited to solving certain problems because one doesn't necessarily know about which bits are implemented in PHP, or whether PHP is just a templating/rendering stage over work done elsewhere. Some other languages might allow you to do certain operations in the front-end more easily, but the way to approach it when using PHP might be to delegate that to a back-end service in another language. Similarly, some languages might allow you to write both most front-end and most back-end software in the same language, where PHP might be wholly unsuitable or makes certain things harder to achieve than it is worth using it for (maybe strict memory usage control, maybe where you're looking for CPU cache wins).

jheriko 14y ago

i think you miss the larger point... any half way decent developer would never have this issue - breaking changes happen on every platform - or you should assume they will. use encapsulation properly (i.e. actually encapsulate, not just use a keyword meaning 'class' in the OO sense) and problems like this require single line of code changes to fix. even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency, then encapsulate it, then fix. even on multi-million line code bases this will not take a month. inexperienced programmers are terrible at estimating tasks like this, which often take less time than you think, and less time than it feels has passed as you are doing them. php is a fine language - the various arguments i've heard against it boil down to "i'm to shit of a programmer to do my job", either by choosing the wrong technology or not being able to just suck it up and get on with making stuff work.

Terretta 14y ago
> even if you have them scattered across your code base what you then do is realise that you have failed to encapsulate a platform dependency Take this line of reasoning far enough, and you're saying wrap every PHP function in your own function, so your programmers program in your synonym language instead of PHP, something like CoffeeScript vs JavaScript, perhaps. I don't think using PHP (or any language) directly means you're a "shit programmer". I think the care Python has taken between 2.x and 3.x is a better example of the type of care and concern and community awareness building around this exact sort of change that a language's benevolent dictators (Larry, Rasmus, Guido) should take when altering the philosophy of how the language should behave.
- gbog 14y ago
  > wrap every PHP function in your own function That's what I did or tried to do when working with PHP. At least on sensitive parts (date, string, database functions).
  - columbo 14y ago
    Hrm... if you don't trust your core to that extent... then why use it?

sp332 14y ago

The behavior was deprecated with a warning for how many versions?

GlennS 14y ago

I disagree completely. This is example of the PHP team working to fix a common criticism of their language: that it's full of inconsistencies. And when encountering push-back from users who depend on those inconsistencies, the developers have stuck to their guns. Well played to Rasmus.

Domenic_S 14y ago
Indeed. "PHP is full of inconsistencies! What a terrible, amateur language!" fixes inconsistencies "PHP broke their functions! What a terrible, amateur language!" Haters gonna hate.

batista 14y ago

>Here's how I read it: We have this public API that we're not exactly sure how it works version to version, and, oh, we've just changed our parsing code Really? You read it wrong. It is "he have a public API that had a bug --that only surfaced when using it in a brain damaged way, anyway-- and we fixed it along with doing several DRY improvements to our code base. We also gave ample time of advance warning with our beta releases". "so if it breaks your stuff then tough shit because we're a bunch of amateurs." An ad-hominem? And its Rasmus that cones out as a little child, to your "mature" reading of the situation? Priceless. >I especially liked this quote: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure." Perhaps it isn't about being paid, but about taking pride in the work you do. That includes fixing bugs and brain damaged edge cases of the public API. The complainer and your reading are so off the mark, I can't even begin to comprehend such attitudes exist...

larrys 14y ago

"Perhaps it isn't about being paid, but about taking pride in the work you do." Even if you take pride in what you do you expect to be treated with a certain level of respect. ( Not that being paid means you should be disrespected of course. )