We will try to stop fixing bugs in PHP
bugs.php.net
bugs.php.net
... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months ... -- rasmus.
Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it now could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it.
Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.
As long as it's known that these are long term fixes people can prepare for them.
I love to hate PHP-the-language as much as the next guy, and I don't particularly love their design decisions for the language, but let's face it, on basic release management grounds there's nothing to complain about. On general principles I'm of the opinion that the PHP project did everything called for here and the fault is pretty much 100% on the user's side here, with the only possible counterargument being that they apparently may not have called this exact change out quite as precisely as they could have (though that implies they knew, which, well, in a sloppy-type language like this this sort of thing is easy to miss). Languages don't get to version 5 without some breaking changes, but the alternative of every language being stuck with every bad decision made in version 1 forever is worse.
Now that I remember it, it was a pretty nice setup - creating OpenVZ partitions from a template, making python from sources and testing the application within the machine. Too bad it was a one-off thing. I should have used something like buildbot or jenkins.
It's entirely possible that this fix was made in a point release - it didn't jump out at me in the changelog, and I didn't feel like digging - but that's a moot point in this case, since even if the change was made with a major release like 5.3 this guy would still be upset.
A better solution? Don't make arbitrary changes that will make months of unnecessary work for people for no reason to begin with. If you're going to eat up developer time, you should make it for a good reason.
Even if the reason is making PHP more consistent and paying off technical debt for future PHP maintenance, instead of benefitting you directly, it's still a reasonable change for a reasonable reason.
I think its very professional to not bump versions just for the sake of it.
release notes exist for a reason.
Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note.
It is not enough to ask people to read the release notes, these release notes should be complete and usable.
There's no substitute for actually testing your code with a new environment before deploying it.
And, to be honest, he is clearly demonstrating the fact that he's a pretty poor developer, and that he doesn't have the necessary qualifications to be writing software that manages people's retirement funds. Also, when dealing with something as important as that, you ought to know better than to base our technology on top of PHP.
[1]: Coming from somebody who built a very successful startup on top of PHP.
PHP has its shortcomings, but, as in any open source product, if it doesn't work for you, you have a couple options.
They can't bully their way like they tried.
The decision was defended on its own merit, so I would be really disappointed if bringing money to the table affected the outcome. Funding open source development is great as long as meritocracy is maintained. That's why Linus never accepted a job at a company that had a stake in pushing Linux in a certain direction.
I personally think this guy should ask for a full money-back refund and then shut the hell up.
I'm of the mindset to stick with what I know best when I'd rather build a working product and get it out the door quickly. I don't actually personally care too much what language I use (I feel like database selection is more crucial) but I read about so many startups running on Python or Rails that I'm starting to wonder if there's something I'm missing and if there are business advantages to using other languages/frameworks.
Contrary to the other comment, there are business advantages to using a particular language. (Though I would concede if your only choices are Ruby's Rails, Python's Django, and PHP's Yii, for many problems there isn't much to compel you to one or the other besides your preference and available talent.) I could write a large comment going over the pros/cons for different use-cases of PHP (plain or with a framework like Yii), Python (with Flask), Java (with enunciate), and Node.JS (those are the only languages/environments I've built larger-than-toy webapps with; I still need an excuse to use Clojure's Noir for something). My list would not just be language-war pros/cons but business value considerations and hypothetical consequences. It's not the most important choice you can make, but it should be considered if there's more than one option because the type of problem you're solving can be made much simpler or easier with the right tool.
I think you've got the right mindset, and that's to use what you know for anything important you need to finish soon, but I'd recommend checking out the other environments on your own time just for fun. Also before starting a project, research to see if it's a solved (or mostly solved) problem for another framework/language. Even if there's a learning cost to something brand new, depending on the problem it can be well worth it for the overall cost reduction that the tool provides. There are a lot of "We learned and used/migrated to Erlang" stories out there because Erlang solves particular problems very well.
I often find myself wanting to start new projects in $new_platform but have no idea how to really compare them before I get started, save for looking at their documentation or advertised features.
You should only use the technology that suits your company the best (in terms of needs and knowledge -never EVER start a company based on a tech you don't understand or know)
Upon reading the conversation I was amazed he didn't get that response right away.
> > Please escalate this to someone who can answer the question as to why this was changed. -- endosquid at endosquid dot com
> Escalate? Oh how I wish I had someone to escalate to. -- rasmus@php.net
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.
The bigotry from this community when it comes to PHP has left me sick to my stomach.
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.
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.
But please, tell me of one, just one, "severe flaw" you find in PHP, as it is today. And I will enter into a healthy debate with you.
That's clearly nonsense. The people who point out how terrible PHP is have huge, very detailed and very accurate lists of the problems with PHP. They don't get that from "never dealing with it".
>If you will ship faster and better with language X, go ahead and use it.
We do. Why do you think that means we shouldn't point out how bad PHP is? Did you know that for every stubborn dumbass that sticks his fingers in his ears and screams "LALALALA I CAN'T HEAR YOU!", there's an inexperienced developer who didn't know how bad PHP was or why, who was inspired to learn more because of that "PHP bashing" post, and who subsequently saved years of hardship by switching to a sane language? Just because you don't want to hear about how shitty PHP is, doesn't mean nobody else does.
The only legitimate complaints I read as someone who uses an up-to-date version tend to revolve around the wildly inconsistent naming conventions, and a couple of extensions with rather poor documentation. The recent releases (5.3, 5.4) really did a lot to make it just as feature rich as other scripting languages.
If you want to use something else, be my guest. But I for one am tired of the misinformation that PHP bashers spread. I happen to like a language that doesn't get in my way, has extremely thorough documentation, and almost any question is answered in the first search result. At the same time, I hate the lack of documentation on the actual source (I have a few things that are a huge pain to do in user land, so writing a native extension is a huge pain), and of course the wacky parameters and return values on the old functions.
Sounds an awful lot like you are just ignoring the things you don't want to hear. It isn't just that PHP is weakly typed, it is that it has absurd type conversions that no other weakly typed language does, that aren't even consistent, and explicit casts don't serve the expected purpose of forcing the correct type:
"1e1" == "10" => True
$a = "foo"; $b = 0; $c = "bar";
$a == $b => True
$b == $c => True
$a == $c => False
"22 cream puffs" == "22 bullfrogs" => False
"12 zombies" + "10 young ladies" == "22 cream puffs" => True
(string)"false" == (int)0 => True
$ perl -le 'print 07'
7
$ perl -le 'print 08'
Illegal octal digit '8' at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
$ python -c 'print 07'
7
$ python -c 'print 08'
File "", line 1
print 08
^
SyntaxError: invalid token
$ php -r 'print 07;'
7
$ php -r 'print 08;'
0
$ perl -le '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
uno
$ php -r '$foo = 1; print(($foo == 1) ? "uno" : ($foo == 2) ? "dos" : "tres");'
dos
These are not problems that are fixed in recent versions of PHP. They are not misinformation. If you want to revel in your ignorance, feel free. But don't expect the rest of the world to tip toe around the facts to avoid inconveniencing you with reality.
Well that's the biggest piece of bullshit I've ever seen spewing out of someone's keyboard here on HN. I've been developing in PHP pretty much since it came out. At least, since it was stable/useful enough for people other than Rasmus to use. I've been using it for so long that I absolutely hate it. The inconsistencies, the "bolted-on" OOP, the amount of time I'm just sitting there scratching my head wondering where the fuck my data went to, and not even being able to test the thing since there's no good testing libraries built for PHP. It's all a confusing mess that I refuse to even be paid for at this point.
Often, the best tool in web software is the one you can get the most/cheapest labor for so you can actually get your product completed and on the market.
No one cares if your software is programed in the latest tech with the very best techniques - all they care about is if your business is viable. PHP fills this niche excellently.
As a developer I make my living off PHP. I'd rather play with nicer languages, but frankly that isn't where the money is where I am.
On the other hand, significant breakage of 10 years-old APIs with not even release notes...
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.
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.
Well that's pretty much PHP in a nutshell, no news there.
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.
If you had read the diff you would realize they did not.
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.
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.
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 :/
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.
Because the input is a text box? Text is, after all, the way for people to input data into a computer.
So do Facebook.
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.
What's really important here is that people need to be aware when they are adopting a tool which brings this much technical liability.
People should not be unknowingly exposed to this relentless stream of years-old, fatal bugs. Life is too short and it's even more unfair to newbies to make them deal with nutty, random issues like 'can't use a Turkish locale'. This isn't just picking on PHP. These bugs are epic and breathtaking and impose an exceptionally high amount of effort to work around.
It is clear by now that (A) these are not just a few isolated bugs but a big pile (B) most of this pile is old and already known for years (C) the PHP team is not fixing the pile despite lots of time (D) it would be such an epic amount of work to fix that you could never reasonably expect others to do it, especially if they have no reason to be invested in PHP (how is that reasonable?) (E) you could never get the fixes and cleanups published because of all the existing code which would be broken, unless PHP adopted a risky, even more labor-intensive backward-incompatible renovation project (F) there are already multiple well developed alternatives which do not have these problems, so why would I wait for PHP to get its house in order?
I'm not saying that PHP sucks and could never be fixed.
I'm saying that PHP doesn't have enough positives to justify the huge time and effort to fix it... or to suffer through using it for years. There is no third choice.
Why on Earth would I bust my butt trying to fix this pile of bugs when I can just use anything else?
Just because I feel sentimental about the name 'PHP'?
This is a slowly sinking ship, it is not responsible to tell newbies to get on it.
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).
Actually, BASIC has been written so many times that you would probably get a pretty sane and systematic experience out of a web BASIC. Relatively speaking.
The Facebook front-end code is largely just the PHP language (modulo things like XHP) and follows the shared-nothing, request-based architecture that people who program in PHP expect. With the right abstractions and code organisation, it is fairly clean and understandable even at the relatively large size (even if I'm not generally a fan of the language and would almost certainly not make the decision to use it today).
It is somewhat less interesting whether the PHP runtime is as efficient as it can be. Partly because one can use an alternative runtime like HipHop for PHP if you want to. And partly because very few people have to worry quite as much about performance/efficiency that comes with a large capital/operational cost where you have hundreds of servers.
So while "But Facebook uses PHP so it must be good" is not the best argument, neither is fighting it with "But Facebook reimplemented it!".
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.
"PHP is full of inconsistencies! What a terrible, amateur language!"
fixes inconsistencies
"PHP broke their functions! What a terrible, amateur language!"
Haters gonna hate.
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.
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.
That's what I did or tried to do when working with PHP. At least on sensitive parts (date, string, database functions).
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. )
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...
That said, I don't see this taking 'months' either, they could just write a wrapper function that mimics the old behaviour and their tests should cover it. If their quality control or inner workflows make changes like this take months, I'd expect that upgrading to a new PHP version and the related testing and QA should take them years.
Sounds like a change management nightmare.
+ Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.
hehe, exactly the same sort of mentality that lead the person/team to somehow write code that end up depending on obscure parts of the api!
I'm the first to walk away from a PHP bash session, but a wise man once said, "the right tool for the right job."
print number_format("",0);
Warning: number_format() expects parameter 1 to be
double, string given in Command line code on line 1
print number_format((int)"",0);
0
1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways.
2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it)
You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.
> It's not a number definition, but FORMATTING. How do you format nothing in the numerical system? By having it be zero. You don't have NULL dollars in your bank account, do you?
He goes on to say that "this is tax data and has to be precise for tax planning and retirement planning."
Think about that for a minute. A guy claiming to write tax planning software doesn't know the difference between NULL and 0. NULL is not 0. It's NULL. I don't want tax software reporting that I owe "$0" instead of "$badvalue". At a minimum, I want it to throw a giant red error dialog that scares me into double-checking all my inputs.
It's trivial to turn all notices/warnings/errors into exceptions in PHP (it even provides an exception class for it, ErrorException). PHP is multi-paradigm and supports many different ways of handling errors and warnings.
> This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily.
This change was to make the output of functions consistent based on invalid input. It's specifically addressing this point. It's also the very first point listed in the migration documentation
As for handling invalid input, I think you should actually check what some of the functions output some day.
For example, decbin clearly states that the input should be an integer but if I pass it a string.....
Code/ctsr » php -r 'echo decbin("invalid input");' 0%
Zero is clearly not a NULL value. This is one I ran into this morning with php 5.3.8, I've seen this issue crop up in many other functions, they don't return NULL. Some return NULL, some return 0, some return '', some return '0', some return FALSE.
I think a simple "use strict"-type declaration would go a long way for making software that's actually reliable rather than the barrage of set_error_handler, ini_set and related calls, but oh well, I'll file a feature request. It gets more complicated when security enters the mix (remember magic quotes?), but there are about nine thousand different frameworks which deal with that better since they're actually designed for a specific purpose.
You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle
My understanding is that PHP started out as a noob-friendly page scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.
I think of this as "garbage in, garbage out". The function will return a numeric value -- if you give it proper input.
On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
Not one he'd run into at the time, since it had yet to be changed to something random and unexpected.
What kind of programmer passes "" and null on a function such as this and expects ....zero in return?
And what kind of programmer does it --as he admits-- "all around the place"?
If you give right to this guy, that's a very very short and accurate interview question --no hire.
Returning null in the math library at all just seems counter-intuitive.
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.
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?
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.
Languages are subject to bugs. If they didn't have bugs, people wouldn't complain.
The bigger question is probably whether Ruby is any safer from this now, thanks to the ISO (ANSI?) standard.
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.
Well played, sir.
{"a", "b"}
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.
However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..
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.
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.
I am sad I was not invited :(
1. Change thousands of lines of code (probably `sed`-able)
2. Patch PHP to re-introduce the original bug/feature
3. Downgrade PHP back to the version that had the
bug/feature you were relying on
Problem 2: You are delaying the unevitable; it's nice to use new features of the language, having to code in old versions is a pain for developers. Small continuous upgrades are easier to handle than rare gigantic ones.
You upgrade, you may need to change things. It's just a fact of life. Or, you pick a library / language / framework / everything that guarantees 100% backwards compatibility as documented, that never has bugs (since fixing those breaks 100% backwards compatibility), and you never use features in even remotely-unexpected ways. Like in this case.
I don't know if that's correct, but that's what was used as an excuse.
edit: actually... no, that still doesn't work. They clearly have 100% control over the interpreter since they can patch the source and use the patched version.
ADDITION: As the creator stated, it's been issuing warnings for some time now and was changed LAST YEAR. there's just no foundation to this complaint.
Linus has always been pretty adamant about not breaking API behaviour even undocumented ones. But in this case, undefined behaviour had been previously documented.
Also, was it him or Ulrich Drepper who were against changing memcpy undocumented behaviour. (mempcy used to work with overlapping regions too.)
PS. This mailing thread is from 2010. It's really old.
Linus took extra steps to no break autofs behavior, even though it was (more) due to a bug in GCC than anything else.
As an aside, I didn't realize there would be people on HN who wouldn't recognize rasmus@php.net immediately.
What you're describing is whimsical, not standardized.
If PHP has any place in the world at all, it's as a language for the web with a minimum of extraneous boilerplate. If it fails at that goal, well, wtf? If you're going to be all proper about things, why not just do it in Python or some other sane language?
Additionally, and more to the point, in PHP 0 == "" == null == false, so it shouldn't be unreasonable to expect them to be treated as equivalent. It's also a nice thing when a method can always be trusted to return the same type, or these types of issues can end up cascading.
In any case, 'should' and 'nice' things are hard to rely on in PHP, that's why you should always have the docs open and read everything when writing PHP, making even basic assumptions about a method being well behaved will likely screw you over. :)
Principle of least surprise "for the novice web developer" says empty string to zero makes sense in this case.
Meanwhile, empty string with zero decimal places returning null would be less surprising to a pro, but in PHP, the first behavior would also be unsurprising to a pro.
Speaking of which, are they going to upgrade to 5.3 without testing all those thousands of places across all their products?
This is particularly true if your applications are older and written before modern template systems made it a bit easier to abstract these concepts to filters and the like.
Just as you say older/pre-modern -- bad code or not, the same caveat applies about upgrading core language platforms. Even a strictly typed language with a much more standardized API like Java can be hard to upgrade major versions (where I would consider 5.3 a new major version).
It returned 0 previously for "", why change it now? Was "" == 0 a bug ?
B) The change was discovered as a difference in behaviour in two major releases that were three years apart.
C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful.
D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix.
E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea.
F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."
I tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..
How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0).
In this case, NULL is definitely more appropriate, because the input is invalid.
Well in PHP, the number for <silence> is 0, so it would stand to reason that the formatted number for <silence> is 0 as well.
Your analogy is a misunderstanding of null. Null is like you asking me how many apples Joe has. I say I don't know. If you write down 0, I'm going to stop you and say, "I didn't say zero, I said I don't know."
If I were in charge of PHP, release 6 would be 5.4.4 with the standard library happily throwing exceptions on invalid input. That's it. The language would be 100% more useful instantly.
What I don't get is that they are keen to modify php source. But not to just keep using the same php release?
I agree with E, they take floats not strings apparently.
The moment you run a patched build, you're IMHO not running the officially sanctioned version any more.
According to the php docs
floatval('122.34343The') == 122.34343
floatval('BLARTLBARTFAST') == 0
Why should it take the input and choose a different response than what floatval would respond with?
If floatval returns null on 'BLARTLBARTFAST' and '122.34343The' then this function should return null. If floatval returns 0 (or whatever) than this function should return the same.
It's inconsistent behavior.
Since you quite clearly have no idea what function we're even talking about or what it's supposed to do, I will just point you to the documentation rather than more explicitly explain on how many levels you are wrong: http://www.php.net/manual/en/function.number-format.php
The function requires a float, and the developer is passing in an empty string. To rely on this type of edge-case behavior is ridiculous, in my opinion.
[1] http://php.net/number-format says the first argument expects float, and does not say what happens if it receives non-floats.
php -r 'print number_format("",0) . "\n";'
PHP Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1
Sounds like that's what 'zend_parse_parameters' does, actually.
Excel team motto.[1]
While I understand Rasmus' response is legitimate, I also see that depending on something as crucial as a programming language implementation is less of a good idea than it might seem at first. Makes things like Maru (the programming language[2], not the cat) much more appealing: if there's something you don't like in your compiler, at least you stand a chance at fixing it (Maru is less than 2K lines, and counting down).
[1]: http://www.joelonsoftware.com/articles/fog0000000007.html
Considering the filer of the report goes on to say this, at what point did they fail to realise that moving from an "old PHP 5.1.6 Solaris 8 box" to an "RHEL5 with 5.3.1" should have required the same level of testing and signing off?
No sympathy for a developer who completely changes their environment (OS, PHP version, at the very least) and then bitches about stuff they failed to anticipate not working. This is not a reflection on PHP, for once.
I remember working at a company where the servers were Ubuntu, the auto-update mechanism replaced Sun Java with OpenJDK which broke countless apps and web servers, like the Concur app, the build system, etc.. God that was a nightmare. A real setup like at bigger companies I've worked at would have tested that update on developer boxes, integration boxes, testing and training boxes, and only then sent it to production.
They were never using the function correctly in the first place! Not sure what they have to complain about here...
http://techcrunch.com/2010/04/27/php-founder-rasmus-lerdorf-...
He's always been like this, best I can tell.
As for Rasmus, I think he could've explained why it's a "won't fix" type bug in a slightly more diplomatic fashion, though I can't say I would've handled it any differently. He's completely right as to why the behavior shouldn't change. Finally, bjori's response was completely unnecessary, inflammatory, and downright rude.
This has shown me the worst of the PHP community. I'm not ashamed, just more wary.
I think it's an example of how not to interact in a community, from both angles. Also, I can't stand the notion that open source developers are "volunteering" their effort. All programming is voluntary in the sense that you are making a free choice to do it and most likely gaining capital (social or financial) in the process. I voluntarily build software and give or sell it to others all the time.
Best response to the whole thing except for Rasmus' awesomeness.
Mr.Rasmus, respect, for not ending the thread at this statement.
In this case they were standardising parameter parsing code, which I think is definitely the direction you want to head.
I made a mistake, but I kept getting back zeros instead of some sort of NULL or an exception. This is a bug, in the sense of its not how I wanted PHP to behave. I'm glad PHP is fixing its string-to-numeric bugs.
First of all, why does the function even accept strings? There should be some eception happening. Second, why does it return 0, i could understand NULL but not 0 (for a function that is supposed to handle numbers, having it return a number in the invalid case, what is that?)
Why not?
> There should be some eception happening.
PHP's built-in functions do not ever throw exceptions.
> Second, why does it return 0, i could understand NULL but not 0
Well it doesn't anymore, but it used to, and that kind-of made sense in the context of the language being PHP: in PHP (userland), when using a string in a numeric context that string will automatically be converted to a number:
> php -r 'print (1 + "3") . "\n";'
4
> php -r 'print (1 + "whelp") . "\n";'
1
The problem with PHP's weak typing is PHP's hit-and-miss implementation. Check out AWK, another weakly typed language, for example:
BEGIN{printf "%5.2f\n", ""}
prints "0.00" as would be reasonable.
Because PHP was invented as a web language to process web forms and generally your inputs always came to you as a string.
They are very thorough with testing their super-important tax software. Well, except they ignore uninitialized variables, but I hear those are A-OK in accounting.
Anyone who uses PHP seriously knows when accepting user input you have to do type checking rigorously. The manual states the input has to be a float. Of course in PHP this means it SHOULD be a float but why risk sending it a variable who's type is still undecided?
Yup, indeed this is the main problem here. I work with PHP for many years, but i would not suggest using PHP layer as core of my "Taxing software", PHP is not statically typed means it's not suited well for this job, in e-commerce sites i built in past there were always problems when it gets to tax calculations, you learn to deal with it by wrapping your calculation code in the right way and testing it currently.
It is probably the case when unskilled programmers just used number_format() directly instead of wrapping it with "Tax" class that does that you want it to do, and nothing else. it was indeed common in PHP 4, but we have moved since then.
The fact that some developers think the language chosen has much effect on the success of a site is still a mystery to me.
EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take just as long to write: "Sorry about the inconvenience. We changed this undefined behavior for consistency's sake. You could cast the first argument to a float like: '[sample code]' and you'll get the old behavior back. One of our consulting partners [link] could help you with that if you'd like." Instead, Rasmus set the tone that he was superior from the onset.
If you need the features of an old version, use the old version. Simple as that. Don't expect the rest of the world to be stuck with dealing with backward compatibility just so you aren't inconvenienced. Upgrade, pay for support, move to another platform, or stop complaining.
Deleted comment
Just because we observe somebody being a dick on the internet, does not give us permission to stalk them, expose their personal information (even if it can be freely found on the internet), round up a lynch mob, etc.
This is very bad behaviour on your part. This sort of thing can ruin lives. Please take it down.
Deleted comment
wow.