4 ms·

If you write sloppy code, expect unexpected behavior. Your examples are as bad as any other junk out there. The advantage of php arrays (imho) is that you can

If you write sloppy code, expect unexpected behavior. Your examples are as bad as any other junk out there. The advantage of php arrays (imho) is that you can treat them as associative arrays or not dependening on the situation. The lookup behavior is the same for both though, which is convenient. i don't know python or ruby enough to compare, but it is nicer than javascript where associative arrays (ie objects) and real arrays are entirely different types.

edtechre 15y ago
I write way more PHP than Python. But dicts are MUCH better in Python. In fact, dict keys can be any data type you choose, like a true hash table in other languages like Java (e.g. HashMap).
Stormbringer 15y ago
Don't blame the tool user for inconsistencies in the tool. A claw hammer that occasionally bites your hand off is a bad claw hammer. (Bad! No biscuit!)
- Androsynth 15y ago
  The general consensus of this thread is that there are a lot of bad php developers out there that write bad code and this does serious discredit to the language. The example this poster linked to was bad code. Its not proof the language is bad, its proof the poster is no better than the truly bad programmers who use the language he is trying to make fun of.
  - jessedhillon 15y ago
    In PHP: $bool = (08 === 0); var_dump($bool); This prints bool(true) In other words, at the deepest level of identity this language can check, 08 is reported to be equal to 0. With a language like that, I think it's safe to blame the tool.
aphyr 15y ago
My examples are meant to illustrate the broken behavior, not be real-world code. I structured it this way to make the broken-ness more apparent, but I guarantee you "good code" runs into these problems. But no other language I've used would work this way. hash[8] would be the same as hash[010] and hash[0x8], and distinct from hash['8']. In addition, if anybody told you that strings would be interpreted as integers, you'd expect that octal strings (which PHP obviously understands) would be interpreted as integers as well! Instead, only decimal formats are handled. This pernicious confusion of datatypes in the name of convenience is exactly what makes writing correct PHP code so infuriating. If you want to put the blame entirely on "bad PHP developers", I have some datetime and object-equality behaviors to discuss.
aphyr 15y ago
it is nicer than javascript where associative arrays (ie objects) and real arrays are entirely different types. Actually, while we're on the topic: these should be separate types, for exactly the reasons I outlined in that code snippet. Arrays and hashes have entirely different memory characteristics, access times, growth strategies, and indexing semantics! Trying to smush both models into the same construct is what leads to PHP's befucked implementation of "arrays"/"hashes", which succeed at being neither. As an example, compare Ruby (an abysmally slow language) to PHP on array iteration--a task in which PHP loses by a huge margin on both memory and time complexity.

edtechre 15y ago

I write way more PHP than Python. But dicts are MUCH better in Python. In fact, dict keys can be any data type you choose, like a true hash table in other languages like Java (e.g. HashMap).

Stormbringer 15y ago

Don't blame the tool user for inconsistencies in the tool. A claw hammer that occasionally bites your hand off is a bad claw hammer. (Bad! No biscuit!)

Androsynth 15y ago
The general consensus of this thread is that there are a lot of bad php developers out there that write bad code and this does serious discredit to the language. The example this poster linked to was bad code. Its not proof the language is bad, its proof the poster is no better than the truly bad programmers who use the language he is trying to make fun of.
- jessedhillon 15y ago
  In PHP: $bool = (08 === 0); var_dump($bool); This prints bool(true) In other words, at the deepest level of identity this language can check, 08 is reported to be equal to 0. With a language like that, I think it's safe to blame the tool.

aphyr 15y ago

My examples are meant to illustrate the broken behavior, not be real-world code. I structured it this way to make the broken-ness more apparent, but I guarantee you "good code" runs into these problems. But no other language I've used would work this way. hash[8] would be the same as hash[010] and hash[0x8], and distinct from hash['8']. In addition, if anybody told you that strings would be interpreted as integers, you'd expect that octal strings (which PHP obviously understands) would be interpreted as integers as well! Instead, only decimal formats are handled. This pernicious confusion of datatypes in the name of convenience is exactly what makes writing correct PHP code so infuriating. If you want to put the blame entirely on "bad PHP developers", I have some datetime and object-equality behaviors to discuss.

aphyr 15y ago

it is nicer than javascript where associative arrays (ie objects) and real arrays are entirely different types. Actually, while we're on the topic: these should be separate types, for exactly the reasons I outlined in that code snippet. Arrays and hashes have entirely different memory characteristics, access times, growth strategies, and indexing semantics! Trying to smush both models into the same construct is what leads to PHP's befucked implementation of "arrays"/"hashes", which succeed at being neither. As an example, compare Ruby (an abysmally slow language) to PHP on array iteration--a task in which PHP loses by a huge margin on both memory and time complexity.