Difference between revision 5 and current revision
No diff available.Table of Contents for Programming Languages: a survey
Because of its popularity, PHP gets its own chapter.
" Half the array functions take arrays as the first arg, the other half the last.
explode and implode have different argument order requirements (one is strict, the other works either way).
Functions have a grab-bag of errors from returning null to false to 0 to strings to requiring error\_get\_last to even requiring an object specific error function (DateTime::getLastErrors).
Functions were named to make them have more randomly distributed hashes (http://news.php.net/php.internals/70691). Functions randomly do or don't have underscores, sane order, etc.
Some apis are in terms of objects (DateTime?), some are not (getdate). " [5]
dietrichepp 12 hours ago
I'm not exactly clear on how PHP == works, but you can see the MD5 for yourself:
$ echo -n 240610708 | md5sum 0e462097431906509019562988736854 - $ echo -n QNKCDZO | md5sum 0e830400451993494058024219903391 - $ echo -n aabg7XSs | md5sum 0e087386482136013740957780965295 -
All of them start with 0e, which makes me think that they're being parsed as floats and getting converted to 0.0. This is why "magic" operators like == in PHP and JavaScript? never should have existed in the first place. Operators like == should be, by default, extremely boring. PHP's just happens to be a bit more magical even than JavaScript?'s.
reply
DoubleMalt? 10 hours ago
Once I wrote a little PHP application to manage a clan in a browser game. I used an MD5 hash as session id that I checked with if(session_id)
When users started reporting that their logins would sometimes not work at the first time, I found out that strings that start with zero are coerced to 0 and then interpreted as false.
Never used PHP for anything important since.
reply
ams6110 7 hours ago
To be fair, this kind of thing (maybe not exactly this, but type-coercion bugs) can happen in JavaScript?, which is all the rage now for "important" stuff.
reply
shuzchen 25 minutes ago
This is levels worse than what Javascript does though. Most high-level languages have some sort of implicit coercion (even python lets you do truth tests on non-boolean values). The problem here is the programmer isn't confused about types at all. They're comparing two things of the same type: two strings! Nevertheless, given two strings PHP tries to coerce them into ints before carrying out the equality test. Yes, you will have coercion bugs in other languages if you're testing things of different types, but I don't know any other language where a equality test between two things of the same type are automatically coerced into another.
reply
lars 12 hours ago
This, combined with the fact that you can increment strings gives some 'interesting' results:
$a = "2d9"; $a++; echo $a . "\n"; $a++; echo $a . "\n";
Output
2e0 3
kyllo 7 hours ago
Ahh PHP, the language where true == false
php > if ((true == "foo") && ("foo" == 0) && (0 == false)) echo "yay!"; yay!
reply
shubhamjain 12 hours ago
PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable. Strings type-casted to integers are 0. Seriously? Take a look at this,
> $arr = array(0, "was", "invented", "in", "india");
> var_dump( in_array("Hello", $arr ) );
and yeah it is TRUE because "Hello" got coerced to 0. I blogged about a major bug, I faced, in PHP, where column name "10th_grade" was being type-casted to "10" failing the "bindParam" [1]. Even if they have to continue this "feature" because of backwards compatibility, the least they could have done was NOT to use it in the newer functions but no, even they have this stupid "type juggling".
[1]: http://coffeecoder.net/blog/my-perfect-reason-avoid-php-type...
reply
tragomaskhalos 9 hours ago
There are a couple of things we have learnt in our collective 50+ years of software engineering:
1. Code is not English: Nice try COBOL, and someone had to try, but a failed experiment. Bizarre holdouts: SQL
2. People are not idiots, and will not collapse into a gibbering heap if their programming language insists that 0 and "0" are different things and must be managed accordingly. Bizarre holdouts: PHP, Javascript. Honourable mention: Excel (no Excel, that is not a f&@cking date, I will tell you if I want a date).
reply
WalterGR? 11 hours ago
PHP's type coercion is nothing like I have every seen in any other language. Its horrendously messy, ugly and completely inexcusable.
Is it objectively worse than type coercion in JavaScript??
reply
oisyn 7 hours ago
Oh yes. In Javascript, the operands are only coerced if one of the operands is a number. So when comparing two strings (regardless of whether the strings can be interpreted as a number), you always get a regular string compare.
"12" == "12.0" -> false, basic string compare
Furthermore, if one operand happens to be a number, and the other operand has illegal characters to be interpreted as a number, the two operands aren't equal.
0 == "foo" -> false, "foo" is not a valid number 12 == "12 monkeys" -> false, "12 monkeys" is not a valid number 12 == "12.0" -> true, "12.0" is a valid number, and compares equal to 12.
In short, in Javascript the == operator actually makes sense. In PHP, every single one of above examples would evaluate to true.
reply
romaniv 6 hours ago
While it is obvious that PHP's == operator is horrible, JavaScript? has its share of pretty bad issues, like "x" - 1 giving NaN?.
What I don't understand is why some people agree that PHP is a horrible language, while at the same time praising JavaScript? as messiah of scripting. These two languages don't just have problems, they have very similar problems. Moreover, they gained popularity for very similar reasons (lack of choice).
Seriously, if you posted something similar to OP about JavaScript? the first thing people would tell you is "What, you're still not using ===?!"
reply
"PHP makers made their share of mistakes with their decisions - register_globals, safe_mode (which was not), inconsistent function naming in standard libs, myriad of weird bugs (like syntax error (still) throwing HTTP response 200)" -- https://news.ycombinator.com/item?id=10797375
ams6110 15 hours ago
Is it any worse than Javascript, if we're honest?
reply
pdpi 15 hours ago
Yes it is, and I really don't like JS much to begin with.
There's seriously wonky things in there like the associativity on ?: being wrong, and == being even more broken than in js. There's order of arguments on array_map and array_filter being inconsistent. It's not that there's a massive flaw in there that kills it, it's death by a thousand paper cuts.
reply
mywittyname 14 hours ago
PHP's massive flaw is that it does one thing very well (web-dev), but does everything else rather poorly. It becomes the default choice for projects that start out as a web front-end, but then gets used in other situations where it's ill-suited. A lot of PHP projects have components that are hacked together and work, but are confusing and less-than-ideal from a design perspective.
Threading/asynchronicity comes to mind. I've worked on a few projects that started out as a web-front end, but then needed to do some background processing. Eventually the background process needs to be multi-threaded and the choices are: rewrite your code to support pthread's wrappers classes, use fork and shared memory segments, asynchronous web requests. All those solutions work, but they are much more complicated than the same task would be in most other languages with native threading support.
reply
https://hacklang.org/ https://en.wikipedia.org/wiki/Hack_(programming_language)
Hack runs on HHVM. https://en.wikipedia.org/wiki/HHVM The HipHop Virtual Machine (old 2014 paper)
HHVM runs HipHop? bytecode (HHBC): https://github.com/facebook/hhvm/blob/master/hphp/doc/bytecode.specification
Hack used to be a PHP implementation but diverged: https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-hack.html
"Facebook's entire site runs on HHVM (desktop, API and mobile), both in development and production." [6]
Here's an old webpage detailing parts of PHP that HHVM did not support: https://web.archive.org/web/20190404143119/https://docs.hhvm.com/hhvm/inconsistencies/introduction