Table of Contents for Programming Languages: a survey

PHP

Because of its popularity, PHP gets its own chapter.

Tours and tutorials and feature lists

Respected exemplar code

Yii [1] (but see [2] and following thread)

Opinions

" One of the underappreciated pros of php for web development is its execution model, it's fault tolerant by default and shares little memory across requests. This kind of makes sloppy programming far more tolerable in php than in other platforms. In effect this has an impact on performance but it also helps in ensuring that a bad request can't blow out the whole application from serving other requests like is common in platforms like nodejs where you need to be extra careful. Needless to say this makes php becomes quite viable for production envs, and prevents a whole host of issues that need expertise and careful programming to fix. " [3]
https://stitcher.io/blog/php-8-before-and-after
https://bulletproofphp.dev/yes-php-is-worth-using
https://lobste.rs/s/ikp0zc/yes_php_is_worth_learning_using_current
https://www.devever.net/~hl/mildlydynamic
- https://lobste.rs/s/xqlim2/demise_mildly_dynamic_website

gotchas

Ternary if, ? ... :, has left-associativity, not right-associativity as often expected [4]
http://www.phpsadness.com

" 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.

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.

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.

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.

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!

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...

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).

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??

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.

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 ===?!"

"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?

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.

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.

Variants and implementations

Hack

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

proj-plbook-plChPhpLang