Work, and also "PHP is a low-level programming language at the WRONG LEVEL"
So, I haven't really talked about $WORK here in a while.
It's pretty great. I'm doing all kinds of arcane things; the code base at work is a network stack, written in C, with a tcl interpreter embedded inside. It's vaguely architected in terms of The Hudsucker Proxy, a film by the Coen Brothers. As a consequence, I get to drone on about tcl parking contexts, connflows, hudctl messages, and hudevents.
It doesn't really take me very long to start talking like a native, apparently.
Also, it's been a pretty long time since I've talked about PHP, and (judging by my twitter feed and the occasional irc/forum bait) it's time for a refresher course.
When I say PHP is bad, I really fucking mean it. It's thoroughly disgusting at all possible scales. Avoid putting files through the PHP interpreter, even if there isn't any PHP in them (yes, people do this). If it is the only thing you know, learn something else. Anything else. If you don't want to learn, then what in the everloving blue fuck are you doing writing code? ("It's okay for 95% of what I do!", I hear you cry. This usually tells me you're either doing things which shouldn't be done at all, or you spend a lot of your time reinventing a square wheel. A lot of PHP people love writing the same "input sanitization" code over and over (with different flaws each time), or the same "dispatch a url to an action" thing a million different ways. that they then copy and paste and use over and over. (yes, I know this is possible in all languages. I don't really want to hear it.))
People often like to excuse PHP's behavior and bring up the Church-Turing thesis at the same time. Anyone who does this is either trolling, or full of horseshit — of course it's fucking Turing-complete. A Turing machine is a really basic model of computation, and the entire fucking reason we use programming languages is to insulate us from the inevitability of this. PHP does not give you an interesting, useful, or consistent model of computation, and it should therefore not be used as as a domain-specific language for creating web applications. People who rely on PHP as their only tool for programming soon end up with their brains warped by this broken model, especially if they 'learn' by the terrible documentation. ("But PHP has great documentation!", I hear you cry. Here, try and explain to me why this function even exists, when it was introduced after PHP had support for exceptions. That ought to quiet you down for a while.) I realize that PHP is Turing-complete. It's just frustratingingly hard to model what the actual behavior is. I'm glad that we both understand Turing-machines, but let's face it: most web programmers these days absolutely need to know about several things that PHP bungles pretty badly. My favorite gripe here is the weird lack of difference between arrays and dictionaries. These are fucking fundamentally different concepts, but in PHP they're just kind of mashed together. If you want to understand what your code is doing, you have to unravel not only that lack-of-difference, but a whole bunch of other insane shit. From the numbered breaks(1) to the php.ini, any number of things might be wrong with any given piece of code. Finding out what's wrong in your own code is already hard enough; do you really want to add these things to your list of things to worry about?
There's no reason for me to go into the whole "PHP is inherently insecure" bit. Mountains of words have been written about this, and the kindest thing I'll say in favor of PHP is that it helps keeps the web-app security field, as a whole, alive. If you really want to try and say 'PHP is secure!', I welcome your comments. The same goes for if you have a coredump and want to tell me that it's easy to debug. If you just want to stick up for your "favorite" PHP framework simply because it's the only fucking thing that you know, then go fuck yourself with a hand grenade. There are very good reasons I am advising you not to write new things in this fucking completely broken piece of shit, and security is only one of them.
Back to that json_last_error function: it has no business even existing. If a parse fails, you need to indicate failure immediately. The language has exception support. 'Throw a fucking exception!', I say, and at this point the PHP brain, since it thinks exceptions are scary and complicated, jumps to a different excuse: 'that's a core language function'. And? What makes that so fucking sacred that it can't throw an exception? There is an exceptional condition: your parse failed. You can reliably expect the parse to fail at least sometime, so you need to plan for that anyway. Why not make it something you have to deal with at parse time, so it's easy to see what fucked up? Your oh-so-precious "core" language has all kinds of utterly insane bullshit inside it, but certain kinds of functions can't throw exceptions? (Most of that crap was inexplicably lifted from C++, which is also an eldritch fucking horror. (It's as bad as PHP for almost entirely different reasons. (And a lot of the same ones))). Yes, there are some cases where a _last_error style API is appropriate. This is not one of them. (Speaking of the documentation and exceptions, read that, then go to the first comment. "You should be aware that any thrown exception will propagate up your stack until it is either caught or runs out of stack." Of course you should fucking be aware of that: that's what exceptions are for, this is what they do. There is nothing at all surprising about this behavior, except apparently to PHP programmers. The first commenter does not appear to understand exceptions, but he somehow manages to explain how they work! The documentation is of absolutely no help in explaining that this is actually expected behavior, and it in fact ties exceptions up needlessly with the OO system, leading a lot of people to assume that they're somehow inherently related. It's the blind leading the blind! (here's a much better thing about exceptions, by the by))
Another dumb goddamn thing people try and pull with me is "PHP fast and efficient and optimized and performant and all of these words meaning it goes zoooooom". These people then start stammering and babbling when they're confronted with questions like "How are you measuring your performance? Do you have a general idea of where your bottleneck could possibly even be?". No. no, they don't. Guess what: the same tricks that you use to scale PHP apply equally well to things written in any other fucking language. Other languages with reasonable semantics, meaning that a runtime or compiler can do potentially interesting optimizations. Other languages with at least halfway-sane implementations, so that you don't have to deal with persistent processes that constantly balloon, or ones that crash because they randomly stomp objects during GC. Other languages where you won't have to clobber your code with some thing you fucking copy/pasted from a comment section in order to convert errors into a backtrace of questionable readability. With nearly any other language, even when the other language implementation *coredumps*, a sufficiently advanced UNIX-beard might actually have a chance of figuring out what broke. You'll never have to potentially deal with some obscure fucking error involving the floating point unit being involved in a bug near this code. (You do not want to have to think about the FPU when you're thinking about string length. Trust me on this. (also, using the FPU is not something that's generally associated with "fast performance", for you people still stuck at the very beginning))
A snippet from an actual argument with someone defending PHP:
The language is "easy to use", yes. It's hard to figure out what in fuck it's doing, though. That makes it hard for someone working on the site to figure out what to fix. Its failure modes are mostly uninformative, silent, or security-impacting, except when they're all of the above. There is a large surface area of
People put up with incredible amounts of shit from this language in the name of 'convenience'. It baffles me. It's 'convenient' for getting something half-working and it's extremely difficult to get something right. The software goes out of its way to make it hard to do the correct thing. This is why I avoid writing in it, and this is why you should do the same. By the time you've fought with all of the things that PHP has not made "convenient" (like 'correct code'), you've implemented half of what other frameworks in other languages give you for free. It's one thing if you're writing this as a throwaway or if it's something I can kind of appreciate as a sick hack (I do admit that sometimes PHP can be used for hack value, but it takes kind of a lot to get me there.), but if you're writing something that you intend to maintain, really, write it in fucking anything else. If you're using it like a CGI (tying it directly to the filesystem), then write a CGI in something the fuck else. If you're writing some kind of fucking toy program like a "hit counter", write something else. If it's the only thing your web host provides, get another fucking web host. If you decide to have anything to do with its built-in webserver, then God have mercy on your soul: trivial implementation bugs abound. Sure, I guess the most common deployment scenario - apache and mod_php of some random description on some shared hosting - "works for you" to deploy your your hand-written phpBB clone, or your untar'd default untemplated fucking mediawiki. I mean, that's really cute, but it does not necessarily make you a web developer.
If PHP is really the only thing you know, then some of the things wrong with it can be a little hard to explain. Especially if you take the attitude of "well, it's how PHP does it, so it's the best way!" I really don't like putting up with this attitude, because it reminds me of myself when I used to do this with Perl (I was quite an irritating little shit). The problem is I can't explain it to you in other terms; I can't say "they took that feature from some other language, where it works pretty much like that, except in a way that isn't fundamentally broken" and have it mean anything to you. I can't tell you why the awful, misconcieved implementation of lambdas, relying heavily on string evaluation, is so horribly wrong, because you have no other frame of reference, and refuse to admit another one. Beyond the complaint that 'string eval is horribly wrong 99.9999% of the time', which you've probably heard a million times already, it also returns a string naming the function. Yes, you know that, and that's how it's documented to work, and it even sorta works, but have you really thought through how it operates? In order for you to call this anonymous function, PHP needs to store its name somewhere, and so it goes into the only place PHP has to store function names: the global namespace. That name kind of sticks around and is hard to garbage-collect(2), and so this gets put through a big long game of telephone among PHP devs, (again, aided by the comments page, copy-and-paste, and incompetents who don't know how these things work) and people somehow hear "garbage collection and anonymous functions are bad", instead of "PHP sucks at implementing both of these things". They never grasp how the abstraction is meant to work, so they start making up bizarre excuses to explain away the problem with the design. Then they go on to design their entire site around the concept that one file maps to one URL maps to one thing, and that you should control your application's behavior with ?act= parameters on every URL. (This kind of thing tends to make it hard for other people to interact with your site; if you think that's a feature, then you really shouldn't be anywhere fucking near an HTTP client, let alone a server.)
If you try and paper over PHP's problems (you really want to trust your data to this thing? really?) with a 'framework', not only would you be running it on top of the interpreter that invokes floating-point to calculate string length, you would be running the chance of ending up married to something that one reviewer spurted creepily inappropriate glee upon:
This review starts out saying "The truth is [Magento] is just as easy as what we’re all used to[…]". Are you seriously all fucking used to this? Where is the last fucking straw for you people? The long fucking list of easy-to-commit security vulnerabilities didn't turn you off? The fuckedness going on in the interpreter didn't chase you away? You're so inured to this kind of bullshit that you're used to not being able to navigate and understand your framework's source code with just a text editor? Do you really consider it a feature that a framework for building web applications is closer to the size of a fucking debugger than the next-largest framework I have at hand? (Perl's Catalyst contains 1.1 megabytes of crap, and I've even delved into some of it.) How does this so-called framework help you model your application's behavior at the HTTP level? What does it do for URL routing? You realize the first thing any fucking "frame"work is going to have to do by virtue of PHP's design? It has no idea what php.ini settings you're using, so it's going to go and fuck with all of these goddamn things, possibly programmatically, possibly via .htaccess, possibly by making you do it, possibly all of the fucking above! Then there's the rest of the php.ini settings, and the other framework you're used to is going to do something completely different, and there's no standard and there's no expectation that these settings remain at their defaults across releases, and new versions add new flags that then get tweaked with, and so on and so fucking forth. The madness never ceases with these goddamn people! (Also, I cannot bring myself to write "PHP framework" without feeling the intense need for another word: frame sounds much too solid for what any putative thing of that description is built on. I'm sort of taken with 'shamblework'.)
Occasionally, I get the oddball from left field: 'but PHP is good enough for $some_other_site!'. If you really want to drag me down that road, i could shift topics to some other software atrocities, and we'd shortly end up arguing about C++. God help us if you just so happen to love that fucking thing, too. (The same goes for you, Person Who Thinks "file.backup.tar.gz.2012-02-03" Is A Valid Form Of Version Control (and you, Person Who Refuses To Admit That Garbage Collection Is Ever A Good Thing (I have a big list of these (and I don't want to blow my load)))). Depending on the site you're talking about, I can respect the people who run it: they have to deal with this gigantic fucking hairball of a project on a daily basis. I wouldn't wish that on my second-worst enemy. My worst enemy is practically embodied by PHP: fucking unnecessary complexity, wrought by people who don't quite know what they're doing, and used by people who don't understand its limitations. People with no fucking appreciation for what they're doing. Asswipes who think they can learn to debug a core dump by "googling for 'how do i work gdb'". Utter cocks who hear things like this, and instead of growing the fuck up and learning that you have outgrown your fucking training wheels, take it fucking personally. PHP may in fact be good enough for that other site. The only reason it's good enough for Facebook, as an example, is because they wrote their own implementation. The entire fucking point of this gripe is that PHP is not good for your site. Other sites pay people to deal with this thing, to change the sheets when it pisses the bed, and to roll it over and change its diaper when some automated scanner makes it (or some app written in it) shit a bot onto your system because of a trivial problem. I don't know of anyone who actually enjoys working with this motherfucking thing. Stop saddling yourself and others with this thing's myriad problems. Wake up and realize that it contorts your thinking about how the web should work!
I know this rant is large, angry, and sort of elitist. I apologize for some of that. It is also not very nice. It's a lot of pent-up rage about the utter insanity of the software industry in general. It might be a good idea to read this classic article alongside mine: his words are a lot nicer, but his passion for computer science far exceeds mine. Also, keep in mind that I am not alone in feeling these things, even though I am kind of loud about it. If it helps, I wrote it in small bursts and tried not to make it too fucking inflammatory. This entire rant is not directed at any one person in particular, either. This is just me, taking aim at the head of a bad idea, and firing with an extremely large cannon. (What can I say, it's my sport.(3))
1: There is a good fucking reason that other languages don't really do this: it's hellishly impossible to maintain code that uses this feature. I also can't imagine that it has good consequences for the internals.
2: I don't know if PHP actually does manage to GC its anonymous functions. Last I heard, it couldn't; they may have somehow worked around this. Please feel free to explain to me how this actually works, because I don't want to actually expose myself to those internals, for fear of actually running across how they special-case it.
3: If you really want to argue about models of computation, I encourage you to try me. I'm sort of weak in those areas — I only recently just "got" the derivation of the Y-combinator (by studying it in perl (I am somewhat ashamed.))
PPS:
krinndnz reminded me of this article, which is approximately this rant, the other way.
It's pretty great. I'm doing all kinds of arcane things; the code base at work is a network stack, written in C, with a tcl interpreter embedded inside. It's vaguely architected in terms of The Hudsucker Proxy, a film by the Coen Brothers. As a consequence, I get to drone on about tcl parking contexts, connflows, hudctl messages, and hudevents.
It doesn't really take me very long to start talking like a native, apparently.
Also, it's been a pretty long time since I've talked about PHP, and (judging by my twitter feed and the occasional irc/forum bait) it's time for a refresher course.
When I say PHP is bad, I really fucking mean it. It's thoroughly disgusting at all possible scales. Avoid putting files through the PHP interpreter, even if there isn't any PHP in them (yes, people do this). If it is the only thing you know, learn something else. Anything else. If you don't want to learn, then what in the everloving blue fuck are you doing writing code? ("It's okay for 95% of what I do!", I hear you cry. This usually tells me you're either doing things which shouldn't be done at all, or you spend a lot of your time reinventing a square wheel. A lot of PHP people love writing the same "input sanitization" code over and over (with different flaws each time), or the same "dispatch a url to an action" thing a million different ways. that they then copy and paste and use over and over. (yes, I know this is possible in all languages. I don't really want to hear it.))
People often like to excuse PHP's behavior and bring up the Church-Turing thesis at the same time. Anyone who does this is either trolling, or full of horseshit — of course it's fucking Turing-complete. A Turing machine is a really basic model of computation, and the entire fucking reason we use programming languages is to insulate us from the inevitability of this. PHP does not give you an interesting, useful, or consistent model of computation, and it should therefore not be used as as a domain-specific language for creating web applications. People who rely on PHP as their only tool for programming soon end up with their brains warped by this broken model, especially if they 'learn' by the terrible documentation. ("But PHP has great documentation!", I hear you cry. Here, try and explain to me why this function even exists, when it was introduced after PHP had support for exceptions. That ought to quiet you down for a while.) I realize that PHP is Turing-complete. It's just frustratingingly hard to model what the actual behavior is. I'm glad that we both understand Turing-machines, but let's face it: most web programmers these days absolutely need to know about several things that PHP bungles pretty badly. My favorite gripe here is the weird lack of difference between arrays and dictionaries. These are fucking fundamentally different concepts, but in PHP they're just kind of mashed together. If you want to understand what your code is doing, you have to unravel not only that lack-of-difference, but a whole bunch of other insane shit. From the numbered breaks(1) to the php.ini, any number of things might be wrong with any given piece of code. Finding out what's wrong in your own code is already hard enough; do you really want to add these things to your list of things to worry about?
There's no reason for me to go into the whole "PHP is inherently insecure" bit. Mountains of words have been written about this, and the kindest thing I'll say in favor of PHP is that it helps keeps the web-app security field, as a whole, alive. If you really want to try and say 'PHP is secure!', I welcome your comments. The same goes for if you have a coredump and want to tell me that it's easy to debug. If you just want to stick up for your "favorite" PHP framework simply because it's the only fucking thing that you know, then go fuck yourself with a hand grenade. There are very good reasons I am advising you not to write new things in this fucking completely broken piece of shit, and security is only one of them.
Back to that json_last_error function: it has no business even existing. If a parse fails, you need to indicate failure immediately. The language has exception support. 'Throw a fucking exception!', I say, and at this point the PHP brain, since it thinks exceptions are scary and complicated, jumps to a different excuse: 'that's a core language function'. And? What makes that so fucking sacred that it can't throw an exception? There is an exceptional condition: your parse failed. You can reliably expect the parse to fail at least sometime, so you need to plan for that anyway. Why not make it something you have to deal with at parse time, so it's easy to see what fucked up? Your oh-so-precious "core" language has all kinds of utterly insane bullshit inside it, but certain kinds of functions can't throw exceptions? (Most of that crap was inexplicably lifted from C++, which is also an eldritch fucking horror. (It's as bad as PHP for almost entirely different reasons. (And a lot of the same ones))). Yes, there are some cases where a _last_error style API is appropriate. This is not one of them. (Speaking of the documentation and exceptions, read that, then go to the first comment. "You should be aware that any thrown exception will propagate up your stack until it is either caught or runs out of stack." Of course you should fucking be aware of that: that's what exceptions are for, this is what they do. There is nothing at all surprising about this behavior, except apparently to PHP programmers. The first commenter does not appear to understand exceptions, but he somehow manages to explain how they work! The documentation is of absolutely no help in explaining that this is actually expected behavior, and it in fact ties exceptions up needlessly with the OO system, leading a lot of people to assume that they're somehow inherently related. It's the blind leading the blind! (here's a much better thing about exceptions, by the by))
Another dumb goddamn thing people try and pull with me is "PHP fast and efficient and optimized and performant and all of these words meaning it goes zoooooom". These people then start stammering and babbling when they're confronted with questions like "How are you measuring your performance? Do you have a general idea of where your bottleneck could possibly even be?". No. no, they don't. Guess what: the same tricks that you use to scale PHP apply equally well to things written in any other fucking language. Other languages with reasonable semantics, meaning that a runtime or compiler can do potentially interesting optimizations. Other languages with at least halfway-sane implementations, so that you don't have to deal with persistent processes that constantly balloon, or ones that crash because they randomly stomp objects during GC. Other languages where you won't have to clobber your code with some thing you fucking copy/pasted from a comment section in order to convert errors into a backtrace of questionable readability. With nearly any other language, even when the other language implementation *coredumps*, a sufficiently advanced UNIX-beard might actually have a chance of figuring out what broke. You'll never have to potentially deal with some obscure fucking error involving the floating point unit being involved in a bug near this code. (You do not want to have to think about the FPU when you're thinking about string length. Trust me on this. (also, using the FPU is not something that's generally associated with "fast performance", for you people still stuck at the very beginning))
A snippet from an actual argument with someone defending PHP:
One is that the development time with PHP is much more rapid for some, and people just tend to find the language "easier" to use.
The language is "easy to use", yes. It's hard to figure out what in fuck it's doing, though. That makes it hard for someone working on the site to figure out what to fix. Its failure modes are mostly uninformative, silent, or security-impacting, except when they're all of the above. There is a large surface area of
things that could go wrongwith this thing. By this very notion alone, do you realize that you run a much higher probability of running into one of them? I find the language hard to use. Again, it's not one individual thing that I can point to: it's a whole stack of little things, like how you have to name the variables that you're intending to capture in their sad, sad parody of lambdas. It's the library functions, with such glorious, easy-to-use, names as imagecreatetruecolor, mailparse_msg_extract_whole_part_file, and PDF_setmatrix, all sitting there in your global namespace! (Or not! Depending on compilation/configuration! JOY!) It's how this much-vaunted "convenient" standard library is just extremely thin (which should call to mind: brittle, fragile) glue on top of some godforsaken thing's C API — come on: if I wanted to use the C API, I'd skip the middleman and write in fucking C. It's the maze of allegedly object-oriented features, with documentation that encourages you to code by haphazardly slopping together strings and making objects, veering off into multiple, almost-completely-semantically-identical, oh-so-fascinating ways to declare multiple namespaces in a single file (taking care to never exactly recommend any one), and then come to a crashing halt in a meaninglessly-deep class hierarchy: MyProject\Sub\Level\Connection. Oh, and they only added the namespace feature in PHP 5.3 — this is how it's meant to be used. It is this fucked by design!
People put up with incredible amounts of shit from this language in the name of 'convenience'. It baffles me. It's 'convenient' for getting something half-working and it's extremely difficult to get something right. The software goes out of its way to make it hard to do the correct thing. This is why I avoid writing in it, and this is why you should do the same. By the time you've fought with all of the things that PHP has not made "convenient" (like 'correct code'), you've implemented half of what other frameworks in other languages give you for free. It's one thing if you're writing this as a throwaway or if it's something I can kind of appreciate as a sick hack (I do admit that sometimes PHP can be used for hack value, but it takes kind of a lot to get me there.), but if you're writing something that you intend to maintain, really, write it in fucking anything else. If you're using it like a CGI (tying it directly to the filesystem), then write a CGI in something the fuck else. If you're writing some kind of fucking toy program like a "hit counter", write something else. If it's the only thing your web host provides, get another fucking web host. If you decide to have anything to do with its built-in webserver, then God have mercy on your soul: trivial implementation bugs abound. Sure, I guess the most common deployment scenario - apache and mod_php of some random description on some shared hosting - "works for you" to deploy your your hand-written phpBB clone, or your untar'd default untemplated fucking mediawiki. I mean, that's really cute, but it does not necessarily make you a web developer.
If PHP is really the only thing you know, then some of the things wrong with it can be a little hard to explain. Especially if you take the attitude of "well, it's how PHP does it, so it's the best way!" I really don't like putting up with this attitude, because it reminds me of myself when I used to do this with Perl (I was quite an irritating little shit). The problem is I can't explain it to you in other terms; I can't say "they took that feature from some other language, where it works pretty much like that, except in a way that isn't fundamentally broken" and have it mean anything to you. I can't tell you why the awful, misconcieved implementation of lambdas, relying heavily on string evaluation, is so horribly wrong, because you have no other frame of reference, and refuse to admit another one. Beyond the complaint that 'string eval is horribly wrong 99.9999% of the time', which you've probably heard a million times already, it also returns a string naming the function. Yes, you know that, and that's how it's documented to work, and it even sorta works, but have you really thought through how it operates? In order for you to call this anonymous function, PHP needs to store its name somewhere, and so it goes into the only place PHP has to store function names: the global namespace. That name kind of sticks around and is hard to garbage-collect(2), and so this gets put through a big long game of telephone among PHP devs, (again, aided by the comments page, copy-and-paste, and incompetents who don't know how these things work) and people somehow hear "garbage collection and anonymous functions are bad", instead of "PHP sucks at implementing both of these things". They never grasp how the abstraction is meant to work, so they start making up bizarre excuses to explain away the problem with the design. Then they go on to design their entire site around the concept that one file maps to one URL maps to one thing, and that you should control your application's behavior with ?act= parameters on every URL. (This kind of thing tends to make it hard for other people to interact with your site; if you think that's a feature, then you really shouldn't be anywhere fucking near an HTTP client, let alone a server.)
If you try and paper over PHP's problems (you really want to trust your data to this thing? really?) with a 'framework', not only would you be running it on top of the interpreter that invokes floating-point to calculate string length, you would be running the chance of ending up married to something that one reviewer spurted creepily inappropriate glee upon:
[It's] 58.8MB unpacked: 7,231 files across 2,482 folders (as of Magento 1.2.0.1). This may be one of the largest web applications you’ve worked with–and not only you, but your IDE, too. Don’t even think about letting Notepad++, UltraEdit, Textpad, or one of those programs touch this baby. The “Made with Notepad” days are long gone, man. Get yourself a decent IDE. I even had to upgrade my Eclipse IDE to 2.1.0M5 “Galileo” and switch my PHP stack to Zend Core 2.5 just to handle Magento without slowness and crashing.
This review starts out saying "The truth is [Magento] is just as easy as what we’re all used to[…]". Are you seriously all fucking used to this? Where is the last fucking straw for you people? The long fucking list of easy-to-commit security vulnerabilities didn't turn you off? The fuckedness going on in the interpreter didn't chase you away? You're so inured to this kind of bullshit that you're used to not being able to navigate and understand your framework's source code with just a text editor? Do you really consider it a feature that a framework for building web applications is closer to the size of a fucking debugger than the next-largest framework I have at hand? (Perl's Catalyst contains 1.1 megabytes of crap, and I've even delved into some of it.) How does this so-called framework help you model your application's behavior at the HTTP level? What does it do for URL routing? You realize the first thing any fucking "frame"work is going to have to do by virtue of PHP's design? It has no idea what php.ini settings you're using, so it's going to go and fuck with all of these goddamn things, possibly programmatically, possibly via .htaccess, possibly by making you do it, possibly all of the fucking above! Then there's the rest of the php.ini settings, and the other framework you're used to is going to do something completely different, and there's no standard and there's no expectation that these settings remain at their defaults across releases, and new versions add new flags that then get tweaked with, and so on and so fucking forth. The madness never ceases with these goddamn people! (Also, I cannot bring myself to write "PHP framework" without feeling the intense need for another word: frame sounds much too solid for what any putative thing of that description is built on. I'm sort of taken with 'shamblework'.)
Occasionally, I get the oddball from left field: 'but PHP is good enough for $some_other_site!'. If you really want to drag me down that road, i could shift topics to some other software atrocities, and we'd shortly end up arguing about C++. God help us if you just so happen to love that fucking thing, too. (The same goes for you, Person Who Thinks "file.backup.tar.gz.2012-02-03" Is A Valid Form Of Version Control (and you, Person Who Refuses To Admit That Garbage Collection Is Ever A Good Thing (I have a big list of these (and I don't want to blow my load)))). Depending on the site you're talking about, I can respect the people who run it: they have to deal with this gigantic fucking hairball of a project on a daily basis. I wouldn't wish that on my second-worst enemy. My worst enemy is practically embodied by PHP: fucking unnecessary complexity, wrought by people who don't quite know what they're doing, and used by people who don't understand its limitations. People with no fucking appreciation for what they're doing. Asswipes who think they can learn to debug a core dump by "googling for 'how do i work gdb'". Utter cocks who hear things like this, and instead of growing the fuck up and learning that you have outgrown your fucking training wheels, take it fucking personally. PHP may in fact be good enough for that other site. The only reason it's good enough for Facebook, as an example, is because they wrote their own implementation. The entire fucking point of this gripe is that PHP is not good for your site. Other sites pay people to deal with this thing, to change the sheets when it pisses the bed, and to roll it over and change its diaper when some automated scanner makes it (or some app written in it) shit a bot onto your system because of a trivial problem. I don't know of anyone who actually enjoys working with this motherfucking thing. Stop saddling yourself and others with this thing's myriad problems. Wake up and realize that it contorts your thinking about how the web should work!
I know this rant is large, angry, and sort of elitist. I apologize for some of that. It is also not very nice. It's a lot of pent-up rage about the utter insanity of the software industry in general. It might be a good idea to read this classic article alongside mine: his words are a lot nicer, but his passion for computer science far exceeds mine. Also, keep in mind that I am not alone in feeling these things, even though I am kind of loud about it. If it helps, I wrote it in small bursts and tried not to make it too fucking inflammatory. This entire rant is not directed at any one person in particular, either. This is just me, taking aim at the head of a bad idea, and firing with an extremely large cannon. (What can I say, it's my sport.(3))
1: There is a good fucking reason that other languages don't really do this: it's hellishly impossible to maintain code that uses this feature. I also can't imagine that it has good consequences for the internals.
2: I don't know if PHP actually does manage to GC its anonymous functions. Last I heard, it couldn't; they may have somehow worked around this. Please feel free to explain to me how this actually works, because I don't want to actually expose myself to those internals, for fear of actually running across how they special-case it.
3: If you really want to argue about models of computation, I encourage you to try me. I'm sort of weak in those areas — I only recently just "got" the derivation of the Y-combinator (by studying it in perl (I am somewhat ashamed.))
PPS:
krinndnz reminded me of this article, which is approximately this rant, the other way.