Berkeley CSUA MOTD:Entry 54368
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2024/12/25 [General] UID:1000 Activity:popular
12/25   

2012/4/23-6/1 [Computer/SW/Languages/Web] UID:54368 Activity:nil
4/23    PHP sucks
        http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design
Cache (8192 bytes)
me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design -> me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
There's a lot in the world of technology I don't like, and that's really to be expected--programming is a hilariously young discipline, and none of us have the slightest clue what we're doing. Sturgeon's Law, and I have a lifetime's worth of stuff to gripe about. PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. The language, the framework, the ecosystem, are all just bad. And I can't even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. It's so broken, but so lauded by every empowered amateur who's yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all. An analogy I just blurted this out to Mel to explain my frustration and she insisted that I reproduce it here. You pull out a screwdriver, and you see it's one of those weird tri-headed things. Okay, well, that's not very useful to you, but you guess it comes in handy sometimes. You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways. You pull out the pliers, but they don't have those serrated surfaces; That's less useful, but it still turns bolts well enough, so whatever. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. Now imagine you meet millions of carpenters using this toolbox who tell you "well hey what's the problem with these tools? And the carpenters show you the houses they've built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door. Stance I assert that the following qualities are important for making a language productive and useful, and PHP violates them with wild abandon. If you can't agree that these are crucial, well, I can't imagine how we'll ever agree on much. It's a medium for expressing human ideas and having a computer execute them, so it's critical that a human's understanding of a program actually be correct. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest. New languages exist to reduce the boilerplate inherent in old languages. When something goes wrong, the programmer has to fix it, and we need all the help we can get. My position is thus: * PHP is full of surprises: mysql_real_escape_string, E_ACTUALLY_ALL * PHP is inconsistent: strpos, str_rot13 * PHP requires boilerplate: error-checking around C API calls, === * PHP is flaky: ==, foreach ($foo as &$bar) * PHP is opaque: no stack traces by default or for fatals, complex error reporting I can't provide a paragraph of commentary for every single issue explaining why it falls into these categories, or this would be endless. Don't comment with these things I've been in PHP arguments a lot. I hear a lot of very generic counter-arguments that are really only designed to halt the conversation immediately. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best. Yes, this is necessary in any system, because computers suck. That doesn't mean there's no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do. What on Earth is the point of using a high-level language if all it provides are some string helpers and a ton of verbatim C wrappers? If two features exist, someday, someone will find a reason to use them together. there's no spec, there's no need for "undefined behavior". They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform. For all we know, development time could be halved or doubled if these products were written in some other language; if this list doesn't hurt your opinion of PHP, nothing ever will, so stop arguing with some dude on the Internet and go make a cool website in record time to prove me wrong :) Side observation: I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I've just weighed its benefits against its problems and concluded it's the best fit for things I want to do. And I have never met a PHP developer who can do the same with PHP. But I've bumped into plenty who are quick to apologize for anything and everything PHP does. Core language CPAN has been called the "standard library of Perl". That doesn't say much about Perl's standard library, but it makes the point that a solid core can build great things. PHP 20 documentation, regarding + and friends doing type conversion: Once you start having separate operators for each type you start making the language much more complex. I don't see the point, especially for something like PHP where most of the scripts will be rather simple and in most cases written by non-programmers who want a language with a basic logical syntax that doesn't have too high a learning curve. When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical. Except for class support, which deserved a slew of new operators and keywords. I can't tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. func_get_arg and friends look like regular functions, but operate on the currently-executing function. In C, functions like strpos return -1 if the item isn't found. If you don't check for that case and try to use that as an index, you'll hit junk memory and your program will blow up. index methods will raise an exception if the item isn't found. If you don't check for that case, your program will blow up. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you. it will, instead, do the wrong thing with no warning, unless you remember to include the right boilerplate around every place you use strpos and certain other functions. Here, PHP has actively created a subtle trap for me to fall into, and I have to be vigilant even with such mundane things as string operations and equality comparison. So I have to fit this in here, because it bears repeating: PHP is a community of amateurs. Very few people designing it, working on it, or writing code in it seem to know what they're doing. This, right here, is the biggest problem with PHP: it is absolutely the blind leading the blind. except with objects, where === is only true if both operands are actually the same object! For objects, == compares both value (of every attribute) and type, which is what === does for every other type. If they have the same number of elements but different sets of keys, though, they are uncomparable. except other objects, which they are neither less than nor greater than. Variables that don't exist are created with a null value when first used. This is a natural consequence of the above, so it would be perfectly reasonable, except that globals can't even be read without an explicit declaration--PHP will quietly create a local with the same name, instead. I'm not aware of another language with similar scoping issues. there's nothing that's a step back, like Perl's references, and there's no pass-by-object identity like in Python. PHP is dynamically-typed, so variables generally have no type... except references, which adorn function definitions, variable syntax, and assignment. Once a variable is made a ref...