4 ms·

I believe this author just doesn't like PHP and doesn't consider that some of these "weaknesses" are actually strengths in the eyes of many. Some of the points

I believe this author just doesn't like PHP and doesn't consider that some of these "weaknesses" are actually strengths in the eyes of many. Some of the points are fair, but never show-stoppers, for the domains that PHP is used in. You're not going to want to write general purpose or especially heavy duty low level algorithmic code in PHP. It's a web/database glue language at heart. > # Arrays and hashes treated as the same type We like this! More specifically, there is no "array"; they are manufactured as dictionaries with integer keys. In practice this works fine, and it's not even algorithmically different, since a hash access is a constant time operation. > Hash syntax versus class syntax - i.e. $key['value'] versus $key->value We like this a lot! $array['key'] will access a dictionary. We know it's not going to go through things like subclass rules and overrides, the way an access would in JavaScript, avoiding one of the worst parts of the language, including having to use "hasOwnProperty" for rigorous code. > # Functions/methods always require parenthesis Yes, and it's really not clear to me that the "cure" is better than the disease here, and this comment seems a little out to lunch. The standard practice I would think would be to not expose a $person->first_name variable directly in the first place. If you want an object with a flexible key-value coding system, you're free to write one. (And you can override dictionary access [] if you like.) > No macros I tremble. > Writing an array literal requires literally writing out the characters a, r, r, a, y, ( and ). Oh boo-hoo. Comments like like this, to me, separate out perfectly the programmers who are interested in getting something done versus seeking a sort of pursuit of academic idealism for its own sake. I can tell he only just managed to resist saying it has braces and semicolons too. > It depends what version of PHP. Use PHP 5. > How do you delimit HTML from output PHP code? <?, ?>, <?php ?>, <% %>? Well, it depends on some global setting in php.ini. Use <?php ?> always. > PHP doesn't have multiple inheritance, fine, but it doesn't have mixins/modules, either. We do not want! Locality of code is worth more to us, especially for those of us who have tried to navigate a maze of categories in an unfamiliar Objective-C codebase or something like that. > If you do enable PHP's E_ALL warnings, you get warnings and errors for all kinds of crazy things you don't want warnings for. You're wrong, you really do want those warnings. If you want to turn off deprecated warnings for legacy PHP4 code, you should make that explicit. > PHP is exceptionally slow unless you install a bytecode cache such as APC or eAccelerator. So when it isn't fast enough by default (and it usually is), do that. > People often abuse include(). Rather than using it to pull in functions and classes, they use include for actual code execution, Like in a template mechanism, which is a legitimate use for it. > Because it is designed to be run in the context of Apache, PHP doesn't work very well as a command-line scripting language, A hammer doesn't drive screws very well. > There is a lack of standards and conventions. This is called flexibility. You can code within CakePHP or Zend Framework if you want conventions. > There are a variety of ORMs available all of which suck in different ways, This is not just a PHP problem:)

avar 16y ago
>> # Arrays and hashes treated as the same type > We like this! [...] Maybe you do. But I've always found it annoying. > In practice this works fine, and it's not even algorithmically different, since a hash access is a constant time operation. It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash key actually exists, or whether it exists and its value is set to NULL. The former is O(n) if you use array_key_exists. From zend_hash_exists: while (p != NULL) { if ((p->h == h) && (p->nKeyLength == nKeyLength)) { if (!memcmp(p->arKey, arKey, nKeyLength)) { return 1; } } p = p->pNext; } return 0; >> PHP doesn't have multiple inheritance, fine, but it doesn't have mixins/modules, either. > We do not want! Locality of code is worth more to us Code that I'd write in Common Lisp or Perl that takes advantage of multiple inheritance and the composition it offers is a lot uglier in PHP when I have to hack around not having multiple inheritance. It leads to bigger and monolithic classes that you can't easily compose. >> Because it is designed to be run in the context of Apache, PHP doesn't work very well as a command-line scripting language, > A hammer doesn't drive screws very well This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp etc. you can't easily run most PHP code persistently, so the execution model for most applications is to parse, compile and execute the application for each request. You can get around that in some cases, but some core language features have been blocking this until relatively recently. E.g. create_function() would always leak memory, but in 5.3 PHP finally has support for anonymous functions.
- WilliamLP 16y ago
  > It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash key actually exists, or whether it exists and its value is set to NULL. That's weird, and does seem like a wart. But is this really a problem in practice that leads to performance difficulties in real code? (This is not a snippy rhetorical question, I'd be interested in a real world example.) It seems to me that if I'm using a PHP dictionary as an array, I'd know the length, and thus I'd be guaranteed that any access exists. I also like that arrays being dictionaries gives me the ability to do foreach($array as $index=>$value) if I want, which is nicer than some other languages, though admittedly some dynamic languages do such things better. > Code that I'd write in Common Lisp or Perl that takes advantage of multiple inheritance and the composition it offers is a lot uglier in PHP when I have to hack around not having multiple inheritance. It leads to bigger and monolithic classes that you can't easily compose. This is a holy war, obviously, and you do get interfaces at least. It suffices to me to know that I do have some intelligent supporters on the side of disliking multiple inheritance and mixins very much. If you're one of the people who can be extremely productive building large programs in a Lisp style, much respect and power goes to you, and anyone has to concede that PHP will be too limiting in that case. > This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp etc. you can't easily run most PHP code persistently, so the execution model for most applications is to parse, compile and execute the application for each request. Agreed, and it is a huge pain when you want to do something after a request but yet you don't want to tie up the user in the mean time. I'm not sure I'd want PHP to be a language that makes it easy to have a persistent execution model though; that simplicity (and restriction) is one of the things that has made the language so popular and scalable. PHP's model usually works fine for the kind of web-based problems it's intended for.

avar 16y ago

>> # Arrays and hashes treated as the same type > We like this! [...] Maybe you do. But I've always found it annoying. > In practice this works fine, and it's not even algorithmically different, since a hash access is a constant time operation. It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash key actually exists, or whether it exists and its value is set to NULL. The former is O(n) if you use array_key_exists. From zend_hash_exists: while (p != NULL) { if ((p->h == h) && (p->nKeyLength == nKeyLength)) { if (!memcmp(p->arKey, arKey, nKeyLength)) { return 1; } } p = p->pNext; } return 0; >> PHP doesn't have multiple inheritance, fine, but it doesn't have mixins/modules, either. > We do not want! Locality of code is worth more to us Code that I'd write in Common Lisp or Perl that takes advantage of multiple inheritance and the composition it offers is a lot uglier in PHP when I have to hack around not having multiple inheritance. It leads to bigger and monolithic classes that you can't easily compose. >> Because it is designed to be run in the context of Apache, PHP doesn't work very well as a command-line scripting language, > A hammer doesn't drive screws very well This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp etc. you can't easily run most PHP code persistently, so the execution model for most applications is to parse, compile and execute the application for each request. You can get around that in some cases, but some core language features have been blocking this until relatively recently. E.g. create_function() would always leak memory, but in 5.3 PHP finally has support for anonymous functions.

WilliamLP 16y ago
> It is actually. Read the array.c and zend_hash.c code. It's only a constant time operation if you're not interested in the difference between whether a hash key actually exists, or whether it exists and its value is set to NULL. That's weird, and does seem like a wart. But is this really a problem in practice that leads to performance difficulties in real code? (This is not a snippy rhetorical question, I'd be interested in a real world example.) It seems to me that if I'm using a PHP dictionary as an array, I'd know the length, and thus I'd be guaranteed that any access exists. I also like that arrays being dictionaries gives me the ability to do foreach($array as $index=>$value) if I want, which is nicer than some other languages, though admittedly some dynamic languages do such things better. > Code that I'd write in Common Lisp or Perl that takes advantage of multiple inheritance and the composition it offers is a lot uglier in PHP when I have to hack around not having multiple inheritance. It leads to bigger and monolithic classes that you can't easily compose. This is a holy war, obviously, and you do get interfaces at least. It suffices to me to know that I do have some intelligent supporters on the side of disliking multiple inheritance and mixins very much. If you're one of the people who can be extremely productive building large programs in a Lisp style, much respect and power goes to you, and anyone has to concede that PHP will be too limiting in that case. > This is actually a major problem with PHP. Unlike Perl, Python, Ruby, Lisp etc. you can't easily run most PHP code persistently, so the execution model for most applications is to parse, compile and execute the application for each request. Agreed, and it is a huge pain when you want to do something after a request but yet you don't want to tie up the user in the mean time. I'm not sure I'd want PHP to be a language that makes it easy to have a persistent execution model though; that simplicity (and restriction) is one of the things that has made the language so popular and scalable. PHP's model usually works fine for the kind of web-based problems it's intended for.