7 ms·

What are the crawling horrors of PHP?

24 points by lox 16y ago

greenlblue 16y ago
Is there any point to this kind of discussion? These kinds of questions have maximum entropy, i.e. if you put a monkey at a keyboard and let it bash the keyboard I bet these are the kinds of questions you would get. One can type up questions of the form "What is horrible about X?" ad museum and not be any closer to creating any kind of value in any form whatsoever.
- bad_user 16y ago
  It's not the question that's relevant, it's the answers.
  - forcetenhen 16y ago
    And as usual it'll end up with the same old list of reasonable problems, 'unforgivable' omissions and miles upon miles of ridiculous hyperbole. It's started already. Is abuse of includes or goto an inherent problem of PHP? I was abusing includes 15 years ago when I messed with C and my earliest BASIC was the code equivalent of snakes & ladders. All this kind of thing tends to do is embolden the snobs, put the backs up of the faithful and be of no practical use to any reasonable person looking for honest answers. It doesn't even have the virtue of being a humourous discussion since it's been flogged to death over the whole internet for a decade.
    - regularfry 16y ago
      Just to pick on the includes example, I think it's fair to point it out as a deficiency if there exist other languages and environments which enable/encourage/force you to get it right. It's not a defence that other languages also get it wrong.
- lox 16y ago
  Yup, I tend to agree. Via that post I ended up on a post by Terry Chay with some much more interesting quantitive analysis of PHP usage at Facebook: http://terrychay.com/article/hiphop-for-faster-php.shtml/4 http://terrychay.com/article/hiphop-for-faster-php.shtml/4 One of the things that really surprised me was the observation that PHP has a much higher CPU utilization for comparable operations than other higher level languages.
- JeanPierre 16y ago
  There are no value to the discussion unless they come with the reason WHY x is a bad thing, and WHAT you can do to with the language to get rid of/fix x. They don't seem to do so here. (And some features they consider as "bad" things, I consider as good things. Lack of WHY makes me wonder why x is such a bad thing.) As a note, they complaints seems to mostly be about the lack of standards and conventions. I can agree with that issue, if they find a way to make the standards and convention better.
dfox 16y ago
Is there any reason for this: "If a function returns an array, you have to assign it to a variable before accessing an element, you can't just add an index after the function call." ? I cannot grasp why PHP's authors "designed" it this way.
- troels 16y ago
  PHP's parser/syntax is a bit of a mess. I'm guessing it could incur some sort of inconsistency.
  - randallsquared 16y ago
    Yeah, this is one of the most annoying things about PHP for me. Another similar one is that you can't use empty() on the result of a function call without assigning it to a variable first, and the error you get is something about an invalid write context, which is pretty opaque if you don't just happen to know what it means already.
- shaunxcode 16y ago
  One trick is to return an (object)array('a' => 1, 'b' => 2) and then you can do $func($x)->a.
FiReaNG3L 16y ago
# Arrays and hashes treated as the same type For me this is an advantage over other languages. I'm looking at you, Perl.
- avar 16y ago
  It's not just Perl, every language I've seen or heard of except PHP has a clear distinction between its unordered key-value datatype, and an array datatype. That includes Python, Lisp, Lua, and others. PHP has a Frankensteinian mix between the two. You /can/ implement it in any other language by just keeping an array along with your hash that indicates the order in which elements were inserted: http://search.cpan.org/perldoc?Tie::StoredOrderHash http://search.cpan.org/perldoc?Tie::StoredOrderHash But you almost never want to do this. I've only used it once in all the PHP code I've written. And having to deal with the ambiguity of PHP's key-value array datatype wasn't worth it elsewhere wasn't worth that.
  - pornel 16y ago
    Mix of array and hash types, combined with automatic type conversion has one very ugly gotcha: $x[1] === $x['1']. However, other than that I don't have problems with PHP's "arrays". I find ordered key-value datatype very useful in lots of situations — all kinds of mappings ordered by priority, queues where you can remove any item quickly, trees where order matters (e.g. stuff coming from XML). Sometimes even in cases where order doesn't strictly matter, preserving order makes operations more predictable and results easier to compare (e.g. you can load ini file to PHP "array", edit and save, and it won't get shuffled). It might be a matter of how you think about your data: whether you think of it as arrays and hashes and try to retrofit it in PHP, or whether you think of mapping it into PHP's peculiar "array" from the start.
  - silentbicycle 16y ago
    Lua is an interesting case, because while arrays and associative arrays (AKA dicts/hashes) are the same data type, when dicts have keys 1..N* , those values are kept in an array rather than a hash table. (For O(1) access with a lower constant factor.) * Yeah, Lua is 1-indexed. Ah well.
nuclear_eclipse 16y ago
Some of these complaints don't even make sense: He doesn't like the lack of strict mode, but complains that E_ALL tells him too much; maybe it's telling him too much because he's not writing things correctly, just like 'use strict' would. He complains that you need to remember the parenthesis for a function call, but short of Ruby, I can't think of any other "normal" language that doesn't. C/C++/C#, Java, Python... He complains that a whole bunch of things are considered false, but when using the === operator, they aren't. Always use <?php ?>, and your code will always work, everywhere. Just because people abuse include() doesn't make it a flaw of the language. Strawman ftw. Plugins written for one framework won't work in another. Gasp! News at 11...
- adamc 16y ago
  Python has properties to abstract away function calls.
  - nuclear_eclipse 16y ago
    So does PHP: http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members http://www.php.net/manual/en/language.oop5.overloading.php#l...
- wazoox 16y ago
  > He doesn't like the lack of strict mode, but complains that E_ALL tells him too much; maybe it's telling him too much because he's not writing things correctly, just like 'use strict' would. "use strict" makes compilation errors. E_ALL only does runtime errors. Both are useful, and having one is no excuse for missing the other.
lox 16y ago
Most of these gripes are fixed in PHP 5.3, although the lack of ability to access $this in closures drives me nuts. Aside from that, all languages have minor syntactic issues. Take your pick. I think the far bigger problem with PHP comes from the culture that surrounds re-use. Writing re-usable PHP is hard, we lack decent package management systems and systems for distributing light-weight packages of code with simple dependancies (I'm looking at you PEAR). The end result is a culture where re-inventing the wheel is standard practice or at best copy and paste.
RyanMcGreal 16y ago
There's plenty to hate about PHP, but most of my gripes have been repeated ad nauseam all over the internet. Yet one issue that really drives me bonkers doesn't seem to have received the opprobrium it deserves: Functions can take default named arguments, but insist on referencing named arguments by order, not name. This is just utterly asinine.
- nuclear_eclipse 16y ago
  That's because PHP is heavily influenced by C and Perl, both of which exhibit the same behavior.
  - RyanMcGreal 16y ago
    What's the point of named arguments if you can't do something like the following (e.g. Python)? >>> def some_func(a=1, b=2, c=3): return (a + b) * c >>> val1 = some_func() >>> val1 9 >>> val2 = some_func(b=3) >>> val2 12 >>> val3 = some_func(c=5) >>> val3 15 >>>
    - nuclear_eclipse 16y ago
      I completely agree with you, and I much prefer Python's method of handling it. I was at explaining why PHP acts the way it does.
      - RyanMcGreal 16y ago
        Yes, of course. I wasn't holding you responsible. :)
  - phaylon 16y ago
    Raw core Perl doesn't have named arguments. You can pass in a list of key/value pairs and the function can simply pull those in a hash, but you don't need to have them in the right order for that. I don't know all libraries on CPAN that implement some kind of function signature or argument validation, but I can't remember seeing one that requires ordered named arguments.
WilliamLP 16y ago
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:)
scotty79 16y ago
I'm extremely annoyed about how there is no native datatypes for HTML and SQL and they are just plain strings and are allowed freely to be created from strings glued together with any arbitrary data without any default escaping what leads to SQL injections and XSS attacks. Oh wait. That's true for (almost?) all languages that are used to writing webapps.
ErrantX 16y ago
There are a variety of ORMs available all of which suck in different ways, such as bloated syntax, forcing you to write SQL statements as a bunch of function calls (i.e. $something->select('column')->where('condition > 0')->...), or excessive configuration. The one decent ORM (DMZ Datamapper: http://www.overzealous.com/dmz/ http://www.overzealous.com/dmz/) is maintained by one person, and limited to the Code Igniter framework. This is a complaint I'v made before... Currently I am using Jelly [1] for the Kohana framework and it is wonderful compared to most of the PHP ORM offerings. 1. http://jelly.jonathan-geiger.com/ http://jelly.jonathan-geiger.com/
- shaunxcode 16y ago
  hah http://jelly.jonathan-geiger.com/docs/api/Jelly_Field_Behavior http://jelly.jonathan-geiger.com/docs/api/Jelly_Field_Behavi... - I wanted to see what his approach was in regards to defining custom types etc.
  - ErrantX 16y ago
    Uh, there is no class Jelly_Field_Behaviour, instead you need to look at the various classes in Jelly_Field_Behaviour_* - I don't know where it linked you to that but it was obviously in error. Here are the behaviours: http://github.com/jonathangeiger/kohana-jelly/tree/master/classes/jelly/field/behavior/ http://github.com/jonathangeiger/kohana-jelly/tree/master/cl...
    - shaunxcode 16y ago
      Thanks, if I can find where I got that link I'll try and ping the owner on github.
mildweed 16y ago
I thought this was going to be an article about the difficulties in writing a web spider in PHP (which is not PHP's strong suit). I once wrote a crawler loosely based off Snoopy (http://snoopy.sourceforge.net/ http://snoopy.sourceforge.net/) and it was a nightmare.
Goladus 16y ago
I don't have much experience with PHP, so I don't hate it and curse the people who inflict it on me the way I curse, say, perl programmers. My complaints are basically: I tried it once and didn't like it. It was hard to write the abstractions I wanted and the results were buggy. It could just be me. Several years ago I wrote a feature simultaneously in Python, Perl, and PHP. It was a fairly simple task-- retrieve a list of formatted strings, parse the data with regular expressions, and transform the 3-dimensional information into a 2-dimensional table. In the python version, the regexp functions were ugly, but idiomatic and also separated into independent functions. The logic was clear and 3 years later it's still easy to understand what it's doing. I can't find the perl version, but I remember having to use a retarded workaround because references weren't working as documented in one tiny (but essential) edge case. Basically I had to duplicate the entire program to handle two different cases. There is was probably some completely different strategy that would work better, but I didn't have three days to spend digging through perl docs to find it. In the PHP version, I seem to have had some trouble using abstractions. The program is just one monolithic while loop with some comments. Also, I see some weird hacks in the PHP version and I don't remember why I had to use all of them. At one point I'm populating an array with empty values using 'array_fill()' and I see some temporary-looking variable names like $start_end, and there are a bunch of comparisons to arbitrary index values. For example $start_end[1] is 'start' and $start_end[2] is 'end'. There's none of this crap in the python version. Ultimately I went with the PHP version. Because the rest of the app was already written in PHP it was far easier to deploy. A year later the feature broke for some reason and I never had the time to fix it. So ultimately, I would probably tend to avoid PHP in the future because it doesn't seem to support my style of programming very well and I don't see many advantages to indoctrinating myself to its quirks.
- shaunxcode 16y ago
  can you post the code in a pastebin or is it proprietary/too involved w/ rest of the system to make sense in isolation?
kls 16y ago
There are at least three ways of handling errors - return codes, trigger_error(), and exceptions, all of which are handled differently and used inconsistently by functions and libraries, and require messing with various combinations of global settings to cause errors display or not display to the user. There are furthermore no agreed-upon conventions for handling errors, so libraries freely mix all of these methods along with directly printing errors to the output which is impossible to trap. For me this was a show stopper for using PHP for anything other than maintaining existing stuff that we inherit (and only for clients we really like). error handling is at its core a foundation to quality, without proper error handling you have to put in significant effort to build a quality product because the structure has to be reinforced at every level. Having multiple ways to handle errors is almost worse than having none at all. This is one area that really needs to be standardized and have "the one way" to do it. Good or bad, it allows everyone to know what to expect. It is just my opinion but, this one flaw makes PHP one of the worst languages I have ever use, which is sad because Wordpress and Drupal are great products but I can't stand to have to work in PHP, if I have a project that I know will not require custom development, I use Wordpress or Drupal I really wish they supported alternative languages for writing custom modules,It would be nice to be able to write them in Python or hell even JavaScript has proper error handling.
bhiggins 16y ago
One problem is that the people in charge of PHP and their ongoing bad choices.
- revolvingcur 16y ago
  Yeah. I'm cherry-picking here, but if the creator of the language says something like the following, it's probably a bad sign. "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I'll just restart apache every 10 requests." But because that could sound like either DHH or Rasmus Lerdorf, there's also this: "I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." The lack of overall direction and ball-o-mud hackery is exactly what one would expect to underlie PHP in its present state.
  - robryan 16y ago
    It's a feature though, it's not like there aren't web development languages that have been designed in a much beter way. I think it's good to have one from the "it get's the job done" mindset.

24 points by lox 16y ago

Is there any point to this kind of discussion? These kinds of questions have maximum entropy, i.e. if you put a monkey at a keyboard and let it bash the keyboard I bet these are the kinds of questions you would get. One can type up questions of the form "What is horrible about X?" ad museum and not be any closer to creating any kind of value in any form whatsoever.

bad_user 16y ago
It's not the question that's relevant, it's the answers.
- forcetenhen 16y ago
  And as usual it'll end up with the same old list of reasonable problems, 'unforgivable' omissions and miles upon miles of ridiculous hyperbole. It's started already. Is abuse of includes or goto an inherent problem of PHP? I was abusing includes 15 years ago when I messed with C and my earliest BASIC was the code equivalent of snakes & ladders. All this kind of thing tends to do is embolden the snobs, put the backs up of the faithful and be of no practical use to any reasonable person looking for honest answers. It doesn't even have the virtue of being a humourous discussion since it's been flogged to death over the whole internet for a decade.
  - regularfry 16y ago
    Just to pick on the includes example, I think it's fair to point it out as a deficiency if there exist other languages and environments which enable/encourage/force you to get it right. It's not a defence that other languages also get it wrong.
lox 16y ago
Yup, I tend to agree. Via that post I ended up on a post by Terry Chay with some much more interesting quantitive analysis of PHP usage at Facebook: http://terrychay.com/article/hiphop-for-faster-php.shtml/4 http://terrychay.com/article/hiphop-for-faster-php.shtml/4 One of the things that really surprised me was the observation that PHP has a much higher CPU utilization for comparable operations than other higher level languages.
JeanPierre 16y ago
There are no value to the discussion unless they come with the reason WHY x is a bad thing, and WHAT you can do to with the language to get rid of/fix x. They don't seem to do so here. (And some features they consider as "bad" things, I consider as good things. Lack of WHY makes me wonder why x is such a bad thing.) As a note, they complaints seems to mostly be about the lack of standards and conventions. I can agree with that issue, if they find a way to make the standards and convention better.

dfox 16y ago

Is there any reason for this: "If a function returns an array, you have to assign it to a variable before accessing an element, you can't just add an index after the function call." ? I cannot grasp why PHP's authors "designed" it this way.

troels 16y ago
PHP's parser/syntax is a bit of a mess. I'm guessing it could incur some sort of inconsistency.
- randallsquared 16y ago
  Yeah, this is one of the most annoying things about PHP for me. Another similar one is that you can't use empty() on the result of a function call without assigning it to a variable first, and the error you get is something about an invalid write context, which is pretty opaque if you don't just happen to know what it means already.
shaunxcode 16y ago
One trick is to return an (object)array('a' => 1, 'b' => 2) and then you can do $func($x)->a.

FiReaNG3L 16y ago

# Arrays and hashes treated as the same type For me this is an advantage over other languages. I'm looking at you, Perl.

avar 16y ago
It's not just Perl, every language I've seen or heard of except PHP has a clear distinction between its unordered key-value datatype, and an array datatype. That includes Python, Lisp, Lua, and others. PHP has a Frankensteinian mix between the two. You /can/ implement it in any other language by just keeping an array along with your hash that indicates the order in which elements were inserted: http://search.cpan.org/perldoc?Tie::StoredOrderHash http://search.cpan.org/perldoc?Tie::StoredOrderHash But you almost never want to do this. I've only used it once in all the PHP code I've written. And having to deal with the ambiguity of PHP's key-value array datatype wasn't worth it elsewhere wasn't worth that.
- pornel 16y ago
  Mix of array and hash types, combined with automatic type conversion has one very ugly gotcha: $x[1] === $x['1']. However, other than that I don't have problems with PHP's "arrays". I find ordered key-value datatype very useful in lots of situations — all kinds of mappings ordered by priority, queues where you can remove any item quickly, trees where order matters (e.g. stuff coming from XML). Sometimes even in cases where order doesn't strictly matter, preserving order makes operations more predictable and results easier to compare (e.g. you can load ini file to PHP "array", edit and save, and it won't get shuffled). It might be a matter of how you think about your data: whether you think of it as arrays and hashes and try to retrofit it in PHP, or whether you think of mapping it into PHP's peculiar "array" from the start.
- silentbicycle 16y ago
  Lua is an interesting case, because while arrays and associative arrays (AKA dicts/hashes) are the same data type, when dicts have keys 1..N* , those values are kept in an array rather than a hash table. (For O(1) access with a lower constant factor.) * Yeah, Lua is 1-indexed. Ah well.

nuclear_eclipse 16y ago

Some of these complaints don't even make sense: He doesn't like the lack of strict mode, but complains that E_ALL tells him too much; maybe it's telling him too much because he's not writing things correctly, just like 'use strict' would. He complains that you need to remember the parenthesis for a function call, but short of Ruby, I can't think of any other "normal" language that doesn't. C/C++/C#, Java, Python... He complains that a whole bunch of things are considered false, but when using the === operator, they aren't. Always use <?php ?>, and your code will always work, everywhere. Just because people abuse include() doesn't make it a flaw of the language. Strawman ftw. Plugins written for one framework won't work in another. Gasp! News at 11...

adamc 16y ago
Python has properties to abstract away function calls.
- nuclear_eclipse 16y ago
  So does PHP: http://www.php.net/manual/en/language.oop5.overloading.php#language.oop5.overloading.members http://www.php.net/manual/en/language.oop5.overloading.php#l...
wazoox 16y ago
> He doesn't like the lack of strict mode, but complains that E_ALL tells him too much; maybe it's telling him too much because he's not writing things correctly, just like 'use strict' would. "use strict" makes compilation errors. E_ALL only does runtime errors. Both are useful, and having one is no excuse for missing the other.

lox 16y ago

Most of these gripes are fixed in PHP 5.3, although the lack of ability to access $this in closures drives me nuts. Aside from that, all languages have minor syntactic issues. Take your pick. I think the far bigger problem with PHP comes from the culture that surrounds re-use. Writing re-usable PHP is hard, we lack decent package management systems and systems for distributing light-weight packages of code with simple dependancies (I'm looking at you PEAR). The end result is a culture where re-inventing the wheel is standard practice or at best copy and paste.

RyanMcGreal 16y ago

There's plenty to hate about PHP, but most of my gripes have been repeated ad nauseam all over the internet. Yet one issue that really drives me bonkers doesn't seem to have received the opprobrium it deserves: Functions can take default named arguments, but insist on referencing named arguments by order, not name. This is just utterly asinine.

nuclear_eclipse 16y ago
That's because PHP is heavily influenced by C and Perl, both of which exhibit the same behavior.
- RyanMcGreal 16y ago
  What's the point of named arguments if you can't do something like the following (e.g. Python)? >>> def some_func(a=1, b=2, c=3): return (a + b) * c >>> val1 = some_func() >>> val1 9 >>> val2 = some_func(b=3) >>> val2 12 >>> val3 = some_func(c=5) >>> val3 15 >>>
  - nuclear_eclipse 16y ago
    I completely agree with you, and I much prefer Python's method of handling it. I was at explaining why PHP acts the way it does.
    - RyanMcGreal 16y ago
      Yes, of course. I wasn't holding you responsible. :)
- phaylon 16y ago
  Raw core Perl doesn't have named arguments. You can pass in a list of key/value pairs and the function can simply pull those in a hash, but you don't need to have them in the right order for that. I don't know all libraries on CPAN that implement some kind of function signature or argument validation, but I can't remember seeing one that requires ordered named arguments.

WilliamLP 16y ago

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

scotty79 16y ago

I'm extremely annoyed about how there is no native datatypes for HTML and SQL and they are just plain strings and are allowed freely to be created from strings glued together with any arbitrary data without any default escaping what leads to SQL injections and XSS attacks. Oh wait. That's true for (almost?) all languages that are used to writing webapps.

ErrantX 16y ago

There are a variety of ORMs available all of which suck in different ways, such as bloated syntax, forcing you to write SQL statements as a bunch of function calls (i.e. $something->select('column')->where('condition > 0')->...), or excessive configuration. The one decent ORM (DMZ Datamapper: http://www.overzealous.com/dmz/ http://www.overzealous.com/dmz/) is maintained by one person, and limited to the Code Igniter framework. This is a complaint I'v made before... Currently I am using Jelly [1] for the Kohana framework and it is wonderful compared to most of the PHP ORM offerings. 1. http://jelly.jonathan-geiger.com/ http://jelly.jonathan-geiger.com/

shaunxcode 16y ago
hah http://jelly.jonathan-geiger.com/docs/api/Jelly_Field_Behavior http://jelly.jonathan-geiger.com/docs/api/Jelly_Field_Behavi... - I wanted to see what his approach was in regards to defining custom types etc.
- ErrantX 16y ago
  Uh, there is no class Jelly_Field_Behaviour, instead you need to look at the various classes in Jelly_Field_Behaviour_* - I don't know where it linked you to that but it was obviously in error. Here are the behaviours: http://github.com/jonathangeiger/kohana-jelly/tree/master/classes/jelly/field/behavior/ http://github.com/jonathangeiger/kohana-jelly/tree/master/cl...
  - shaunxcode 16y ago
    Thanks, if I can find where I got that link I'll try and ping the owner on github.

mildweed 16y ago

I thought this was going to be an article about the difficulties in writing a web spider in PHP (which is not PHP's strong suit). I once wrote a crawler loosely based off Snoopy (http://snoopy.sourceforge.net/ http://snoopy.sourceforge.net/) and it was a nightmare.

Goladus 16y ago

I don't have much experience with PHP, so I don't hate it and curse the people who inflict it on me the way I curse, say, perl programmers. My complaints are basically: I tried it once and didn't like it. It was hard to write the abstractions I wanted and the results were buggy. It could just be me. Several years ago I wrote a feature simultaneously in Python, Perl, and PHP. It was a fairly simple task-- retrieve a list of formatted strings, parse the data with regular expressions, and transform the 3-dimensional information into a 2-dimensional table. In the python version, the regexp functions were ugly, but idiomatic and also separated into independent functions. The logic was clear and 3 years later it's still easy to understand what it's doing. I can't find the perl version, but I remember having to use a retarded workaround because references weren't working as documented in one tiny (but essential) edge case. Basically I had to duplicate the entire program to handle two different cases. There is was probably some completely different strategy that would work better, but I didn't have three days to spend digging through perl docs to find it. In the PHP version, I seem to have had some trouble using abstractions. The program is just one monolithic while loop with some comments. Also, I see some weird hacks in the PHP version and I don't remember why I had to use all of them. At one point I'm populating an array with empty values using 'array_fill()' and I see some temporary-looking variable names like $start_end, and there are a bunch of comparisons to arbitrary index values. For example $start_end[1] is 'start' and $start_end[2] is 'end'. There's none of this crap in the python version. Ultimately I went with the PHP version. Because the rest of the app was already written in PHP it was far easier to deploy. A year later the feature broke for some reason and I never had the time to fix it. So ultimately, I would probably tend to avoid PHP in the future because it doesn't seem to support my style of programming very well and I don't see many advantages to indoctrinating myself to its quirks.

shaunxcode 16y ago
can you post the code in a pastebin or is it proprietary/too involved w/ rest of the system to make sense in isolation?

kls 16y ago

There are at least three ways of handling errors - return codes, trigger_error(), and exceptions, all of which are handled differently and used inconsistently by functions and libraries, and require messing with various combinations of global settings to cause errors display or not display to the user. There are furthermore no agreed-upon conventions for handling errors, so libraries freely mix all of these methods along with directly printing errors to the output which is impossible to trap. For me this was a show stopper for using PHP for anything other than maintaining existing stuff that we inherit (and only for clients we really like). error handling is at its core a foundation to quality, without proper error handling you have to put in significant effort to build a quality product because the structure has to be reinforced at every level. Having multiple ways to handle errors is almost worse than having none at all. This is one area that really needs to be standardized and have "the one way" to do it. Good or bad, it allows everyone to know what to expect. It is just my opinion but, this one flaw makes PHP one of the worst languages I have ever use, which is sad because Wordpress and Drupal are great products but I can't stand to have to work in PHP, if I have a project that I know will not require custom development, I use Wordpress or Drupal I really wish they supported alternative languages for writing custom modules,It would be nice to be able to write them in Python or hell even JavaScript has proper error handling.

bhiggins 16y ago

One problem is that the people in charge of PHP and their ongoing bad choices.

revolvingcur 16y ago
Yeah. I'm cherry-picking here, but if the creator of the language says something like the following, it's probably a bad sign. "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I'll just restart apache every 10 requests." But because that could sound like either DHH or Rasmus Lerdorf, there's also this: "I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way." The lack of overall direction and ball-o-mud hackery is exactly what one would expect to underlie PHP in its present state.
- robryan 16y ago
  It's a feature though, it's not like there aren't web development languages that have been designed in a much beter way. I think it's good to have one from the "it get's the job done" mindset.