Log in

previous packet | next packet

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:
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 wrong with 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 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.



( 20 packets dropped — drop a packet )
Apr. 2nd, 2012 12:22 pm (UTC)
i think it's kind of like a self perpetuating supply/demand problem

php is easy to write (or at least make things look like they're happening) ->
lots of open source projects get written in it ->
a baby developer's first exposure is to lots of php apps ->
so they use php for all their projects ->
businesses turn into php shops ->
php developers are easy to hire since there's a lot of them ->
i'm going to extrapolate from my own experience and say php shops churn a lot, so there's always php jobs, thus no pressing motivation for any of the developers to learn anything else. they can stay within their lazy comfort zone while blaming all the problems at their old company on management and coworkers or whatever

i only worked at that place for 2.5 years. engineering had the run of the company, it was a pretty good work environment and they were still /miserable/ for the reasons you describe. of about 20 people, 1-3 left every 6mo i was there, and were pretty quickly replaced each time. not only was everything written in php, they had a huge problem with Not Invented Here. i have no idea why a print-on-demand publishing site needs to write its own search engine or accounting application. they weren't even using a framework. it was shit but thank god it was at least home-made, hand-crafted shit.
Apr. 2nd, 2012 01:58 pm (UTC)
I love C++. It is shiny and there are all sorts of libraries for it.

PhP showed up when it was the most powerful thing ever and that is why people used it. It is also why it is such a disaster. It is like a house where someone started off with a bedroom and then kept realizing they needed something else and tacking it on. Eventually you get a sprawling mess where yes, there is in fact a ping-pong room that someone built on, but you have to go down this narrow hallway and take a detour through 2 bathrooms and the lion chamber to get there.

It has some major limitations. I was really sad when the person I knew who proclaimed himself the PhP expert knew jack and then I had to write some seriously awful scripting in perl and hack it into the PhP to get things to work right.

Ruby on Rails and other things were written after PhP people had already figured out what they need and were able to actually design the thing.

I still have a sick love of PhP, if only because people wrote some actual examples and documentation. *insert rant here about lack of documentation for other languages*
Apr. 2nd, 2012 04:43 pm (UTC)
Ruby on Rails and other things were written after PhP people had already figured out what they need and were able to actually design the thing.
Rails grew out of the exposure that dhh had encountered working on PHP projects and J2EE projects. See this interview of dhh by O'Reilly.

The problems that PHP has are quite fundamental and are coupled with the ideology that the community embraces. Recently, the Akka project released version 2.0 of their library, which was a nothing-sacred refactor more than much else, and that seems to have gone over pretty well overall to getting something workable and sane out the door as a 2.0.

As an outsider looking inward, it doesn't appear that the PHP development team responsible for keeping the language implementation maintained is committing to ventures like this. Each minor release introduces more bugs and regressions (like the 0x0 +2 thing between 5.2 and 5.3) without really addressing the extenuating problems with the language implementation that sorely need to be addressed.

Like I said, the problems are fundamental. Excusing them is inexcusable.
Apr. 2nd, 2012 04:57 pm (UTC)
From that own interview:

"I realize that this makes PHP sound bad, but it's really not about that. I'm grateful for PHP. It got me started with programming because of its incredible immediacy. It served me very well for a long time. I just arrived at a place that was outside what I would consider the sweet spot for that language. And Ruby proved to be exactly what I needed to get into the sweet spot again."

It has a place, it was a place to start and still is. It is not optimal, but it was a start. We have to start somewhere and we start with what we know.

Then we throw out the baby with the bathwater and make a better baby.
Apr. 2nd, 2012 05:08 pm (UTC)
The problem comes with people who refuse to throw anything out, or who continue bathing the baby even after it's soiled itself in the bath. At some point they just end up smearing green poo around, which isn't good for anyone concerned.
Apr. 2nd, 2012 05:16 pm (UTC)
Being a mother just makes that so much more graphic. Haha.
Apr. 2nd, 2012 05:53 pm (UTC)
I agree with the above-mentioned interview that the immediacy of PHP is nice. It's so easy to get a LAMP[hp] stack, or get one built into your webhost, that average people building their "personal home page" (an initialism so easy lost to time) can rename their file to .php, type "", and grin in smug satisfaction that They Have Used A Programming Language. And that's generally a good thing--technology advances when the barrier to entry is low.

I do also note that PHP is rare in that it basically its own template language. This means that setting up an HTML-generator in most other languages is exactly 2 steps harder: (1) installing the template package and (2) learning/using the template language. I do sympathize with new programmers for whom that makes a big difference.

But I definitely agree with you that way too much of the language is Very, Very Broken for it to be salvageable. My least-favorite thing is the global function namespace, but there's a laundry list and you touched on most of it. :)
Apr. 2nd, 2012 06:02 pm (UTC)
I'm going to have to argue that the fact that PHP is its own template language is yet another thing that it needlessly, confusingly, conflates. Especially when to get actually-decent templates out of the thing, you either have to use Smarty or reinvent Smarty badly.

"Immediacy" is just about the only argument in favor of PHP. I really can't argue against that, but the advances it encourages are not really beneficial in the long-term. It also greatly bothers me that people will hold up their PHP atrocities (such as the aforementioned bad Smarty reimplementation) as though they're a thing to be really, really proud of, and refuse to listen to the many voices of experience saying how bad the whole stack really is.
Apr. 2nd, 2012 06:40 pm (UTC)
Just out of curiosity, what languages do you like doing web dev in?
Apr. 2nd, 2012 06:47 pm (UTC)
I don't like doing web dev at all, but I've used Perl's Catalyst, Ruby's Sinatra, and have played around with various other frameworks.

Most of my dev time is spent at much lower levels. It really gives you a sense of perspective.
Apr. 2nd, 2012 07:22 pm (UTC)
One day, I googled my nick, just to see in what dark places of the Internet it had ended up. One such dark place was a TCL wiki where some people had gleefully coopted a rant I'd written and completely forgotten about.

Need I say the rant was about how much I hated PHP?
Apr. 9th, 2012 07:26 pm (UTC)
hey im using linux now!!!!! I installed mint 12 like 2 days ago. Im going to be a real hacker!!!

what are some good tips on how to start off. I know that im supposed to make an account that is not root for actually getting on the internet and doing unsafe things.

its like operating with a cyber condom!! The system cannot get impregnated unless you are root.

root is like unprotected sex... does that make it exciting to browse while root?
Apr. 10th, 2012 04:08 am (UTC)
Do as little as possible with root permissions. While you are at it, do not write things like "sudo su" (if you're using sudo, write "man sudo" and figure out which option gives you that behavior.

Doing everything as root is more like using the "high voltage" setting when the "low voltage" setting will work just as well. You're likely to burn yourself and shit.

also: using PHP is like unprotected sex at a gay bathhouse while on meth.

I guess you should start by reading the manpages for things like 'ls' and 'ps'. they'll be kinda hard to understand because they speak a weird language, but ask me some dumb questions and i'll do my best to answer them.
Justen Robertson
Jul. 17th, 2012 01:18 am (UTC)
Extending Analogies
"also: using PHP is like unprotected sex at a gay bathhouse while on meth"
Exactly, it's all about sanitizing your inputs. ... ;)
Jul. 17th, 2012 05:29 pm (UTC)
Re: Extending Analogies
No. It is not. "sanitizing input" throws away data. You need to use appropriate protection when passing data across boundaries, not this asinine notion of "sanitization".
Apr. 10th, 2012 08:48 pm (UTC)
More sadness
See also: http://www.phpsadness.com/
Apr. 11th, 2012 12:07 am (UTC)
PHP Hacks
Glad you like my hack! PHP is in it's own class of BAD.

Apr. 11th, 2012 01:19 am (UTC)
Re: PHP Hacks
I laughed when I first saw it — it's quite elegant, in that 'creeping-horror' sort of way. Props for making the thing, condolences for having to do it in PHP. 8)
Jul. 26th, 2012 05:01 pm (UTC)
Re: PHP Hacks
I don't get it... are you trying to help people make a good choice about programming languages to create a better, more sustainable Internet, or do you just hate your job or something?

Honestly, I code in PHP. I don't advocate coding in it. I don't advocate coding at all. If I didn't feed myself with the money that coding generates, I'd be playing baseball, or drinking another of the unlimited varieties of IPA I haven't yet tried.

Who really gives a shit what programming language anyone uses? If you're stupid enough to use the wrong tool for whatever job you're doing, then you're already suffering for it, aren't you? The intensity of posts like these for/against PHP, Python, Cojure, Java, javascript, Perl, Ruby, C, C++, blah, blah, blah, etc. is just absolutely nutty.
Aug. 2nd, 2012 05:10 pm (UTC)
Re: PHP Hacks
Honestly, I code in PHP. I don't advocate coding in it. I don't advocate coding at all.

( 20 packets dropped — drop a packet )


February 2015


Powered by LiveJournal.com
Designed by Lilia Ahner