"(And strictly speaking, Facebook isn’t written in PHP; it’s written in a C++ macro language with a striking resemblance.)"
I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop.
It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language really is warts-and-all PHP.
PHP as a language is, at present, defined by the behaviour of the canonical PHP.net implementation. Change the implementation, and de facto you've changed the language; Perl 5 is similar in this respect. A claim that an alternate implementation or tool chain supports _that_ very same language is a curious statement. It is an alternate implementation, and surely it must differ behaviourally, even if only by having unique bugs.
IIRC Facebook engineers must use HipHop for all their development, with PHP.net's php being now incompatible (hence the push to speed up the interpreter.) Wouldn't that make the language-supported-by-HipHop a PHP flavoured superset at the very least?
Which canonical PHP.net implementation? They differ across minor revisions, in intentional and unintentional ways.
In the absence of a standard, saying what is and is not PHP is necessarily a practical matter: useful PHP implementations are those that run non-trivial PHP applications. HipHop qualifies.
FB's dependence on HipHop is because of backwards-compatible extensions to the language (like yield, e.g.). These extensions don't prevent HipHop from running normal PHP programs, though our use of them does prevent us from using Zend. The extensions are under flags that default off, if you don't want to use them.
This was the same argument I was having in my head, and in the end I couldn't draw a clear enough line between something like Jython and something like HipHop.
Does warts-and-all PHP include that eval wart, or is it more like most-warts-and-a-subset-of-all PHP? Not snarky, just curious if there was something I missed.
The HipHop compiler will optimize much, much more effectively if non-trivial eval() is disallowed, as it is in FB's production code. Obviously, since it's an ahead-of-time system, complex code in eval() will run slowly. The HipHop virtual machine is perfectly happy with eval().
Name one. I can't think of any that aren't better served by other constructs.
eval does have one huge, honking problem though: it permits text to be interpreted as code. This is just asking for code injection attacks.
If you really need incremental/multi-stage evaluation, see MetaOCaml (http://www.metaocaml.org/) for the proper way to do it (without exposing yourself to injection vulnerabilities). It's a consequence of PHP's by-the-seat-of-your-pants approach to language design that the PHP devs settled for eval instead.
"Name one. I can't think of any that aren't better served by other constructs."
User input of code. It's hard to implement a REPL without it. Even if you do implement without it there's still an "exec" implementation hiding in there somewhere.
Also, on rare occasions, it is actually an optimization when used carefully, like the Python nametuple example mentioned nearby.
I'm just answering your challenge. I totally agree that in general it's a bad idea and that's an unusual case. While for it to work properly it has to ship with the interpreter, if I were designing a language I would move it out of the global namespace at least, and require some sort of explicit module import with lots of dire warnings in the documentation.
Even in the case of a REPL, what you want isn't "interpret this string as code in the language in which this program is written and apply it to the state of the currently executing program". What you're really looking for is "interpret this string as code in language X and apply it to the state of the given sandbox".
The problem with using eval for a REPL is that you want an interpreter, but eval gives you unprincipled incremental compilation.
Javascript (and I'm sure other languages) is moving in the right direction with sandboxed evals, but those are very difficult to get right in an imperative language, where a lot of code relies on global state (e.g. the DOM). Purely functional languages solve this problem well by disallowing side-effects. Of course there remain the issue of unconstrained resource usage but this is much easier to solve.
I use this in my Python data processing scripts. That is, when I generate data, I generate it as Python literals, either lists or dictionaries. When I have to process it, minimal parsing needed, I just eval it into my code.
def parse_and_append(line, seq, str):
if str in line:
seq.append(eval(line[line.find(str) + len(str):]))
nums = []
mappings = {}
for line in data_file:
parse_and_append(line, nums, "nums: ")
parse_and_append(line, mappings, "mappings: ")
Terribly insecure for webpages, sure, but very efficient use of my time.
I see no reason to use JavaScript to process my data files - keep in mind this is data post-processing of experiments, not a user-facing application. And I enjoy Python, so I'll stick with it. But thanks for the pointer to literal_eval, I have not explored that part of the standard library.
For some reason, I can't reply to colanderman's comment above/below, but Python's namedtuple is implemented using eval (technically it uses exec, but it's the same idea in Python).
They have an interpreted version of HipHop as well. Can't use the PHP interpreter due to a couple added features (python-esque yield is the only one I know of)
I find it to be an interesting philosophical question about what defines a language.
If you write code in Java, but compile it to native format (using gcj, for instance) instead of using the JVM, is it still Java? In doing so, you lose what is probably the language's biggest selling feature.
Or, perhaps less relevant now, but I remember the days where people would go on about how Ruby didn't support native threads. Except there were interpreters that did use native threads with the exact same Ruby code. Was Ruby code running under one of those other interpreters still a Ruby application?
PHP too comes with expectations about the environment, like how it integrates into the web server stack, which if not met, is it still PHP? I'm not really familiar with HipHop, but, for instance, if you have to compile your code before deployment, you're not meeting one very prominent expectation of PHP: The ability to edit the code in-place on the live server (best practices notwithstanding).
So, what does define a language? Is a language just the syntax? Standard library APIs? Standard library behaviour (see Ruby example)? Runtime environment? I'm not sure you will find a generally accepted answer.
There used to be a generally accepted answer, which is that there were languages, and there were implementations of languages, and that those were separate things. C++ was not g++, and vice versa.
But the lines got very much blurred by the rise of scripting languages, in which - typically - the language was defined by the implementation. So for a few years there, it really was difficult to tell whether this was Python or CPython.
Fortunately, nearly all the languages to which this applies matured and got new implementations. Rubyists often to refer to the C ruby implementation as MRI (Matz' ruby interpreter), and there are lots of different Ruby implementations now. Python went out of its way to document behaviour which was specific to CPython, and put a lot of weight behind Unladen Swallow and Pypy.
But your Java example is bonkers. Compiling Java to native is still Java, its just not JVM. Compiling clojure to JVM is just JVM. The language feature is not the language. In Java's case, the language is specified, the VM is specified, the bytecode is specified. There really should be no ambiguity at all there.
Somehow i find that very comforting that such a heavily trafficked site relies on it. I 'm a happy PHP programmer for at least 10 years. Not overly happy about it but in the end not disappointed about it. I haven't found an overall better alternative tool for the domain yet.
Hm, I'll admit I've spread a bit of misinformation on that matter myself, thanks for the correction. The source for my confusion (and I suspect others as well) was some comments around the time hip hop was made public that it basically wasn't worth using unless you were willing to put in a significant effort to write your php according to some strict guidelines. That made me peg it as something akin to pypy's rpython.
I seem to remember reading that Facebook was using XHP, which allowed XML literals. That would certainly be an improvement over "warts-and-all PHP", in my opinion.
Of course, I'll trust what an actual engineer from Facebook is saying over some article that I can't even cite. Is this not the case?
"Prosaic license"? If the essay was written in iambic pentameter, it certainly escaped me. Anyway, "C++ macro language with striking similarities" has a pretty precise technical meaning, which sane, literate people might actually mistake.
I'm going to be unfair and quote just two words from the article:
> empowered amateur
PHP is a gateway drug to web development. And that's awesome.
With almost every other popular web development language I've heard of[1], there's this grey area between "my app works on my local machine" and "my app works on the server" that is really hard to grok as a beginner. There's a reason entire businesses are built on the idea of making this easy.
With PHP? You get an apache box with PHP, you put the files up, and you're done.
For a professional web developer? PHP is probably nuts. I've purposefully left out things like PHP frameworks, setting up a database, or doing any sort've advanced web development. And yes, it is possible to create a large, successful, stable web app with PHP. It seems kind've hard given the legitimate criticism in the article.
But, honestly? Once you've started doing web development, you should be able to improve your own skills without the community pushing you. It's the people who are just starting out who need all the help they can get.
[1] Which isn't at all exhaustive. I'd love to hear about alternatives that are beginner-friendly.
I agree with you and I'm really surprised in 15 years, or how over old PHP is, THERE IS NOT ONE SINGLE ALTERNATIVE!!
Why? For PHP I sign up for one of the million LAMP ISPs, I upload a .php file with .php embedded in HTML and I'm done.
Where's the Ruby version of this? The Python version? The JavaScript version? The Perl version? THEY DON'T EXIST. You wanna use Perl or Python. You either have to use slow slow cgi or you have to RUN YOUR OWN SERVER. (virtually or otherwise)
PHP sucks, I hate it. I don't code in it unless I absolutely have to. But it's not the language that makes it popular. It's the combination of pre-installed + no setup + plus faster than cgi + works on a shared host + inline templating that's made it popular.
mod_perl? mod_python? As far as I understand them they're not useful on shared web servers so they don't fit the niche PHP is filling. Node? Ruby? They are the server rather than a plugin for apache. Again, not filling the same niche.
Someone with some chutzpah needs to step up and bring the EXACT SAME COMBINATION OF FEATURES except with a different language to the Web. They can be rich writing books and running conferences.
--
Ok, now, I suspect most would want this to be in Python or Ruby but I'd argue if you really want it to succeed make it JavaScript. Because most PHP programmers have to learn JavaScript as well for their webpages. Less to learn = more likely to succeed.
But honestly, if anyone could get any of those languages to fill the niche PHP is providing it would be a huge boon over today.
We don't WANT to replicate PHP's deployment model! It's hard to scale, it's hard to configure, it's hard to secure, it's hard to make work across different web servers. It's convenient for newcomers, sure, but even for something like phpbb the model is strained. We need better deployment tools, not worse forms of deployment.
With PHP, you have a file with a .php file suffix on your server.
That file has code in it. Navigate to that file on your browser. You have a dynamic website.
No installation of external programs is necessary. No terminal. Often, you don't even need an FTP client, since you can use your hosting provider's GUI.
That blinding level of simplicity gets the non-programmer started in under an hour.
To run Heroku (on a Mac), you need to download (1.8GB) and install XCode (or another version of GCC for Mac, but the moment you say GCC, the beginner's eyes glaze over). Once you install XCode, you need to open up terminal (no GUI). Then you install homebrew in order to install the dependencies that Heroku tools require (some JSON libs, if I recall). Once that's installed, you need to install the heroku cli tools. Now you can deploy your heroku app, which requires registering (or, in the case of beginners, generating) ssh keys.
Every single one of those steps is too difficult for the beginner. That is why PHP wins.
mod_python was notoriously unstable and is now disgustingly obsolete, it has been replaced by mod_wsgi for some years now (with the additional advantage that apps which work on mod_wsgi will work on many other servers).
The reason you have trouble deploying Python is purely that the hosts you are trying to use CHOOSE not to support it.
You can get really excellent, easy $10/mo Python hosting but if you ask for 'free,' beggars can't be choosers, so you will get whatever they feel like giving you. This is not a function of the underlying technology.
Don't blame other languages if you have not ever figured out how to do anything other than PHP
You can get really excellent, easy $10/mo Python hosting but if you ask for 'free,' beggars can't be choosers, so you will get whatever they feel like giving you. This is not a function of the underlying technology.
Well this is why I guess php wins. Because the other communities have complete disregard for what the common newbie considers valuable.
The question is whether something matches php's economic model. If the answer is no, its no.
You can get the hosting for $x/mo is not an answer nor a solution for most people.
Instead of blaming "the other communities" blame the web hosts which decide that they only like to support PHP out of the box. Many other languages can be made easy to deploy on shared hosting, it is up to the host to actually do so. Nobody can force them.
> You can get really excellent, easy $10/mo Python hosting...
Any recommendations? I need one for a small biz (in the US), so this is a serious question. I would pay 2-3x that much for a "really excellent" platform I could build a business site on without having to be the entire sys admin.)
Webfaction[1] is really quite good, and well inside your budget. It's shared hosting, but it's good shared hosting, and they're very Python friendly. One click to create a Django app, and you can easily install your own frameworks and stuff. Depending on what your neighbors are doing you may get varying performance, but what can you do?
If you need more reliability than shared hosting can give you, then you either head into the VPS/IaaS/dedicated space (and need to do your own sys admin stuff), or you head into the GAE/Heroku/PaaS space (and need to pay a lot more).
There are always tradeoffs. :) (And no, I have no reason to recommend them other than being a happy customer. <shameless>...unless you want to use my affiliate link[2] to sign up, of course.</shameless>)
The Perl equivalent to the PHP model (request handler entry point is already your template) is called Mason. It's had a pretty huge customer for about a decade now.
I find it odd how many people keep saying it's that simple to push PHP code to a box and get it working. Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc. I've been dealing with PHP for a long time, and getting a local dev setup to match the remote version (or getting code to work on both environments) is just a pain to do.
Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.
With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.
I think you're mistaken to assume the beginner even has such a thing as a local development environment. When first learning PHP I wrote all my code on a $10/month web hosts, saving directly to the FTP server.
Only later did I install a local dev (now made very easy with MAMP), learn about version control, PEAR etc.
Yes, this is why PHP is easy for beginners. The standard practice is to edit directly on the server. It's a hard habit for a lot of PHP devs to break. It's very straightforward and direct: Edit a file, hit reload, see the result live.
Something like, e.g., Heroku is awesome, yes, but not only do you need to learn how to debug a thing which you can't really touch in production, not only do you have to master the distinction between "the file I just edited here" and "the file on the remote machine"… but you have to use Git for that. I love Git, but years of watching PHP devs try to figure out Git have taught me just how intuitive it isn't.
Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc.
Although PHP suffers from this, I'm not sure it is alone. I suffer a lot of pain setting up Ruby environments (I don't think I've ever managed it the same way twice) and getting everything to play nice. Even Python, a language I am about as familiar with as PHP, has it's annoyances on this front.
I suspect the difference is familiarity; I can deploy a working PHP environment in my sleep, because I've done it so many times.
The other day I had to set up Java/Tomcat - literally the worst experience of my life...
Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.
You're thinking like a seasoned pro :) For a newbie there is xampp - a familiar looking windows installer configures the Apache/PHP/MySQL (and others) stack, then it disappears into the backround and, largely, can be forgotten.
This is huge for a new developer.
Think about it this way; if you had a class called "Learn to Write Websites", for absolute beginners, I argue PHP is a good initial choice. Because you don't have to worry about the environment, how to server it, command line, package management - which, say, Ruby would require. You just chuck in a brief overview of how servers work in general, and then get them working on some PHP scripts, with instant results.
I love this!
I like Ruby, of course - it's powerful, has modern standards, and Rails is brilliant. But for a beginner, and even moderate, developer it is a bit of a pain to work with.
With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.
I have a feeling you've gotten so used to deploying PHP that you've forgotten all the headaches involved in it. I idle in about 3 irc channels that provide PHP support, and pretty much every day someone comes in with some deployment related problem. Someone will come in complaining that they can't read some file (the user apache is running as can't traverse into that directory), complain about some missing function (did you install gd? -> show how to get phpinfo -> show how to install gd -> show how to modify php.ini to enable it -> show how to restart apache), or just general errors on their server (is your error reporting on? -> figure out what error reporting is locally -> figure out what error reporting is remotely -> explain how to change the setting -> etc.)
I'd consider myself a seasoned PHP dev and it always takes me a few hours to figure out what happened when I get the white screen of death.
XAMPP isn't any sort of solution to this, because not all servers are configured in the same way that XAMPP is (and the fact that they compile in most packages doesn't help).
Developers at a local makerspace did a project last year using PHP, and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.
Understanding how to set up virtualenv isn't trivial for a beginner, but that doesn't stop a beginner from jumping into my python projects with no pain. All they need is to get easy_install (which is included in all distros I've seen) and do a git/hg pull (both probably also available from distro). The rest can be handled by a shell script in the repo that grabs pip+virtualenvwrapper, sets up the virtualenv and installs all the required packages. Then you tell them "if you need to work on this project, just type `workon projectname`", and with that they're ready to start hacking.
I have a feeling you've gotten so used to deploying PHP that you've forgotten all the headaches involved in it.
That's precisely my point! :)
and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.
As mentioned, I can rattle out a PHP environment in minimal time (basically as long as it takes for the installers to run). But task me to work on a Python project, or Rails, it will take a lot longer.
I think my larger point was that for an absolute beginner PHP offers some key advantages over other languages (even you simple description of jumping into Python involves some major pain points - like using Linux, the command line, package management, what is git/hg?).
The advantage to PHP is purely that it is intended as a web language; Python, Ruby et al require additional steps to get to that stage (or, at least, steps that are not braindead-automated for beginners).
I'm not trying to defend PHP too much here; I like it, but it is a horrible language on many levels (as are other languages).
I started writing a long rant which essentially boiled down to exactly that - PHP may be shit, but so is everything else. I hate all the languages that we're stuck with, and every time I start a project it's more a matter of picking the least shittily inadequate tool for the job than a matter of picking a language that I actually like, because there are none. They quite seriously all suck, very badly in most cases. The pain comes in different places, in varying degrees, but it's always there, whether it's coding pain, tools pain, ops pain, installation pain, documentation pain, etc. I have yet to find a development stack that didn't make me want to scream "fuck!" at least a dozen times over the course of a week of using it.
The real problem with most non-PHP stacks is that they front-load that pain: I have to say "fuck!" and hit Google many more times before I see a page generated from Ruby, Python, Scala, C, Java, or Haskell running on my webserver than I do to see a dynamic PHP page. Is it any surprise people tend to go with PHP pretty often, given that?
I think detractors would be wise to focus a little bit more about what's awesome about PHP, rather than what sucks about it (there's a lot, nobody argues otherwise). Because there's got to be plenty that's great about the language (or perhaps the environment overall) if it attracts people in such large numbers. We should be trying to add that to other languages/environments, not merely looking down on the newbs that still use PHP.
I can attest to PHP deployment being an absolute nightmare. Of course, the difference is that we're not beginners here; far from it, really.
While the beginner will love being able to open up an FTP client (probably one that's a browser extension) to upload a few files they've changed, that's not going to fly for us.
We want proper deployment, source control, and for it to be used properly. We don't want to go anywhere near patching code directly on the live server. Just make sure the fixes are committed, nothing's broken, and run the deployment script of choice.
The requirements for 'simplicity' are completely different. And it's for this reason I think Rails and Django* and the like become attractive prospects for developers who want a more reliable, consistent environment.
* I'd struggle to list a PHP framework here because each one has a different vision of what the 'PHP way' is, probably because there is no 'PHP way'.
I don't understand how deployment, source control and not patching your live code have anything to do with PHP.
Keep your source in a svn or git repo, export the new release branch or bug fix release to a testing box and once you're happy move it over to production. What does any of that have to do with PHP itself?
If you're talking about moving from one version of PHP to another, just compile the new version of php in a different directory from the old version (e.g. /var/lib/php/5.4 ), create a new virtual server definition in apache and point it to the newly compiled php version (e.g. using Apache's mod_fcgid) and test your site. Once you're happy, make that virtual server live to the public and retire the older one.
And what "EXACTLY" is the problem with having a devlopment system that mirrors the live production one?
I worked at one place where our hardware guy who wanted the dev test and live systems to come from the same production batch from SUN just to make sure there where no strange MB rev problems.
Ok having identical hardware is high end but seting up a system where your running the same linux distribution an the same version of mysql php etc is not exactly rocket science.
It's not awesome if the applications so developed by amateurs grows to store PII, financial information or do anything that has any security consequences whatsoever since it is likely to be riddled with "game over" security vulnerabilities.
Most applications developed by professionals in Big Freaking Enterprise Languages working in regulated industries will also have game over security vulnerabilities. Most applications developed by the cool kids in Ruby/Python working for startups will have game over security vulnerabilities.
The current state of information security: basically, we're screwed.
Agreed. While PHP apps are definitely more likely than others to be vulnerable to systemic SQL injection, XSS, and other vuln classes of that sort, all applications are equally vulnerable to things like command injection, authorization bugs, etc. No one gets that stuff right, and if you can execute code on the system, well, it doesn't really matter if you can't find SQLi.
Why is PHP more likely than others to be vulnerable to SQL injection attacks? Most people (and likely All newbies) will be using PDO which automatically protects them.
Searching for PHP and MySQL yields tons of tutorials, code examples, and documentation related to the now-deprecated mysql interface. When I wrote my first comprehensive PHP application last year I spent half a day trying to determine best practices before finally settling on PDO. Newbies won't go through that effort, and will naively land on mysql rather than PDO or mysqli as likely as not.
Actually, I agree with you and I think this is often missed as one of the main contributing factors to PHPs bad rep. If I had enough spare time (and a wider personal network of php pros to draw from) I'd love to make something like www.betterphp.org with short tutorials and guides teaching newbies the current best practices. As it is, anyone picking up PHP for the first time is confronted with a minefield of conflicting and out of date information, some of which is dangerous.
PHP has been around forever and Google has a long memory. Unfortunately, for every good blog post/tutorial on PHP development there are 100 or more bad or out of date ones.
It's not a matter of preference: it's a matter of secure or insecure. The mysql extension for PHP doesn't support prepared statements and as such is inherently less secure than any other mechanism for working with MySQL (The mysqli extension and PDO being the two alternatives for PHP). But losvedir's point is that the number of tutorials that use the mysql extension's API far outweighs the number of tutorials that use PDO or mysqli, and that those tutorials are often very poor quality (ie: contain SQLI).
How do other dynamic languages (e.g. Ruby, Python) deal with this?
Also, if you've reached the point where PDO is too restrictive for what you want to do, you should be knowledgeable enough to write your own db class that incorporates sql injection protection (since all that largely consists of is escaping strings).
PHP sites will have a hell of a lot more of them, though. You're not shielded against CSRF, XSS or SQL injection attacks unless you use a framework - at which point you're back to being a programmer with no "empowered amateur" in sight...
I posit that one of our modern "Things You Can't Say" is that the widely-held belief that the world would somehow be better if every single average Joe learned to program just might be totally bogus.
As was pointed out by djmdjm below, there are Real Consequences when amateur hour overflows into the real world. In many cases it simply would be better had many of these apps not been made by the unskilled - even if that means they hadn't been made at all.
What's so wrong about a barrier to entry that is effective against those who have not yet figured out what the fuck they are doing? We learned despite such barriers, did we not?
You can put up whatever barrier to entry you like. Invent a certificate for Haskell programmers with Ph.Ds. Require everyone who works on your website to have your certificate. Have fun.
But most of the world will tell you where to stick that certification and will cheerfully walk around your "barrier to entry". Then they will hack together a web page using whatever programmers and tools they can find, certified or not, because web pages are very important in the twenty-first century and even the lousiest, slowest, buggiest PHP site is often more valuable than a paper sign stuck on the wall, an entry in the Yellow Pages that nobody reads anymore, a bunch of people sending individual text messages to friends-of-friends, or a static web page from 1997 with a little animated GIF on it.
I wonder if that's only true because we as a society don't (yet) hold people accountable for the code they write, in the way we hold them accountable for the bridges they build or the cars they manufacture?
I wonder what the costs of, say, the Gawker password database breach were? Or perhaps the Sony DRM rootkit on CDs? (Or Apples unpatched Java bug?)
What if the people who wrote and/or deployed the code knew (before they shipped/installed it) that they were going to be held responsible for the costs of any future failures? My guess is we'd then have training and certification and insurance, and professional organisations rising up to certify people as being skilled enough to qualify for insurance for themselves and/or their companies. Much like "Engineers" (who's titles the software industry loves to assume) or "Pilots".
I can torture the "Pilots" analogy further - much like you can do very little training to get a car license, perhaps you'd be allowed to write software that affects only a few people at once, your family and friends, perhaps a colleague or two, even occasionally a stranger, but never more than 6 or 7 other people at once. If you want to store data for more than 6 or 7 people, you need a different class of license - a mini bus license for a dozen or two, then a full bus license, then a train or passenger jet license...
Who _should_ be held responsible for a website's password database getting compromised? At what stage in the progression from "shared GoDaddy hosted out-of-date-wordpress blog about my cat" to "Gawker network with a million or so login credentials inadequately secured" do we draw the line and say "Here is the line in the sand across which more care needs to be taken, and lines of responsibility drawn up and accepted"?
'Cause _surely_ there _should_ be that line somewhere, right?
Even if hypothetically, such a barrier to entry was desirable, it's not viable to maintain one. It'd be treated as damage, and routed around. It's better in the long term to funnel people through something which teaches them the "right way" from the start, by making that "right way" easier than anything else.
Interesting point, and I agree that PHP has some properties that make it easier for beginners to get started with (which doesn't necessarily make it the best language to learn with, but definitely an easy one). I wrote my first few programs in BASIC before I graduated to C. Like BASIC, PHP makes it easy to get something running quickly, and horrible to do anything more complex.
The problem comes in when people don't quickly figure out that the language that they started out in should not remain their primary language for any serious project.
Meh, I've written a lot of PHP code. I also work in Ruby and Python. All three have problems, but I like all three.
With PHP, you have to develop a coding style that naturally avoids PHP's weird areas. It's not really that hard to avoid the mines, but you do have to be aware of them.
In exchange, you get a scalable web server and a language that requires minimal babysitting. Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine. 99% of the time, this is better behavior from a user's perspective as long as functioning perfectly isn't mission critical. It may feel offensive to your OCD programmer nature, but from a pragmatic engineer's standpoint, it's oftentimes a better choice, especially when dealing with the dirty data that's so common in webapps. Do not use PHP in a banking setting.
Compared to running a rails app, administering and scaling mod_php is pleasantly hassle-free. A single webserver with a modest amount of memory can handle an large number of concurrent PHP processes and requests without needing to resort to reverse proxies or anything more exotic than a simple apache install. That's nice not only for the ease of setup, but also because it means fewer moving parts, and less maintenance. That's a very real plus, and I'd say that the shared-nothing architecture of PHP was great engineering choice.
Yes, the language is weirdly architected and oftentimes inconsistent. It can also be extremely productive, and many of its weird choices are extremely pragmatic. The security holes are pretty horrifying, though - the defaults should be much more locked down, and I've always been a bit mystified that they're not.
Instead of automatically throwing a 500 on a random, unimportant, uncaught exception, PHP makes a best effort, and most of the time the result is fine.
And how precisely does PHP "know" which exceptions are important and which are not? In my experience of 6 years as a web developer, the faster and the more explicitly something fails the better. If the user gets a 500, that's a pretty clear sign of a problem, I get an email notification about it, including user id, session data etc. Then, in most cases, I can easily see what the problem was, decide what the correct behaviour is and create a fix immediately and even notify the user after releasing it if I wish to do it. If there is no exception there is a case in the code I was not aware of when writing it and it will still not be brought to my attention. In the best case, the user will report some problem with the functionality and I will have to spends hours trying to find the logs for this user and reproduce the problem, which will now be much harder, quite some time could have passed since the error, the database entries for the user could have change meanwhile (including corruption caused by the system continuing to operate despite an error) and so on. In the worst case, the bug will continue to affect users (which might not even know what the intended behaviour was) and I will learn about it a year from now, accidentally.
Reproducing bugs is hard enough in web applications due to their distributed nature, some of the applications I worked on had serious business-affecting bugs that went unnoticed for months and failure to clearly signal errors is one of the common cases. It doesn't matter whether you are in banking or just building another social CMS/CRM "kind of thing", if you have bugs you loose users and with them money.
Catching exceptions and returning a 200 OK blank page is about the worst thing that PHP is doing. A simple error can trash your google index (Oh, page replaced by blank content, fine!) or mess up API communication when the receiver does not explicitly check for the response content (POST to endpoint, 200 OK, ok, nice). And while you can catch and handle some of those errors with your own error handlers, there are error classes that you can not handle and which will always be handled internally. It's a pure mess.
I understand fail fast, and errors do still get logged and made visible (New Relic is great like that). I would rather fail a bit slower, silently, though. It's much less jarring to users, and therefore you lose fewer.
It's less jarring for the users that you have to tell them weeks after they entered some important data that all this data has been lost? Is it less jarring if they order something and the order confirmation does not arrive and they don't know whether to try again or not?
If there's an issue that affects business logic I'd like my app to display "Sorry, something blew up. Please leave a message and we'll get back to you." instead of chugging along quietly. If the error is not critical (some external feed gone, whatever) _I_ as a developer can decide to catch the error and handle, log or even ignore it. But it's not PHP that can decide to do so.
Lets say for someone who is new to PHP, how long does it normally takes to learn where the minefields are? Is there anyway to start on this? I know in JS there is Javascript The Good Part. Is there anything equivalent in PHP?
Hm, not that I know of. The biggest thing is to read about PHP's security issues (especially how to avoid SQL injection attacks). After that, it's mostly writing code in it. If you start by writing PHP like you'd write C and then branch out, you can figure it out. Stay away from running anything shell related from your PHP code or anything that manipulates the file system unless you know what you're doing. If you're doing anything that's very critical to your users, I'd probably do it in a different language.
I enjoy Eevee's posts. I was first introduced to him through a handful of Pokémon sites where users would reverse-engineer the Pokémon games and protocols. He writes good code and knows his stuff. He even offered some assistance when I was writing a .pkm file manipulation package.
I completely agree with most everything in this post, too. It can all be summarized in this sentence later down the page:
> PHP is a minefield.
You can measure a language's design by how often you shake your head at something. I've run in to pretty much every problem he outlines in the Operators section alone. Too often, a problem I'm having is due to a quirk in the language itself and not in my logic. Too often, I find myself needing to check the docs to see which order I need to supply arguments to core functions.
It's hard to imagine the pain of working in PHP without working in it. All those little things you take for granted in Python, Lisp, Ruby, etc. are gone. The only consistent thing about PHP is its inconsistence.
If you don't mind, I'd like to save this for future reference when someone tells me, "PHP isn't that bad." Yes, as others have said, it was beating a dead horse, but we shouldn't forget just how bad a language can be and still become wildly popular.
I had a one-to-one talk with Rasmus Lerdorf a few weeks ago. This is one of the few things he said:
"I wrote PHP as a hammer to do my stuff. Around 1993, the only way to write web apps was by hacking C and Perl. This was extremely painful, and you would have to do the same thing over and over again. So I started writing a tool which would make my work easier."
"I never thought while writing PHP that someday millions of people will be looking over my shoulder into my code. If I would have known that, I would have surely done a few things differently. But nobody knows that. Some appreciate the language, some don't. I don't blame them."
"PHP is a hammer. Use it for the right purpose at right place. Learn Python, Ruby, Haskell, Scala, etc. every language and use them where they fit. No language is perfect. There are trade-offs involved in each of them."
"When anything is too popular, criticism naturally follows. When people compare a language which is used in, say, 35% of the web apps to a language which is used in, say, 5%, their comparison is highly skewed because then they directly compare the number of things that have gone wrong in one with respect to another. They don't scale them to the same level and then see the faults. I don't blame anyone for that."
"You can scale horizontally with PHP as much as you want. There are many companies doing that, and they have been very successful."
"I can teach a semi-intelligent monkey to code in PHP in three hours."
There were many other cool and brilliant things he pointed out. What I learnt: Accept what it is. If you don't like it for your purpose, use another language which fits in.
P.S. In the new release of PHP, there are even driven servers (libevent), Support Vector Machine (SVM), Traits, Instance Method Call, built-in web server for testing, improved error messages, broad performance improvements, and many others. This language is not going to go away soon.
As far as I understand it, the real tragedy is that PHP as used at scale. PHP as Lerdorf intended it was the quick fix, the we-need-to-get-it-done-now fix. And then that fix grew and grew until the things that PHP fixed were eclipsed by the things in PHP that needed to be fixed--but PHP was already too big to be fixed; people were using PHP not just for fixes, but for everything, and to fix everything would break everything... And that's how we got here. Because nobody will understand your intention when your code is on the screen and the intention can only be inferred from someone who is not in the room with you.
Popularity doesn't determine how many design flaws exist in a language, merely how many people actually get screwed over by each of them. Python and Ruby aren't perfect, and they've had more than enough attention for the flaws to have been found. Even if every developer in the world migrated to one of those languages overnight (o happy day) that language would not suddenly become as profoundly inept as PHP.
There is a quote from Bjarne Stroustrup saying along the same line...
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
― Bjarne Stroustrup, The C++ Programming Language: Special Edition
Sorry, there is no audio/video of it. This was supposed to be just a casual chat, but it turned out to be an incredible exchange of more than one hour. I wasn't prepared to record the conversation, but I wish I had.
This is just another example of someone beating a dead horse (which has already been beaten) for page views. Next week we'll have another "bash php" post, and the week after that another.
I wish people spent as much time creating new things as they did bitching. As well written as this article is, it contains absolutely nothing that hasn't been said ten thousand times already- in fact, most of this seems to be regurgitated from those other articles rather than being actual original thought. Some of the issues brought up have been depreciated and removed a long time ago- too bad the author didn't limit his google search to the last year when looking for other people's examples to post.
Until people stop using PHP I welcome detailed critiques of the language. There are still enough PHP apologists out there that we can use all the ammunition we can get.
Because it's bad for the industry as a whole. Clueless managers are looking exclusively for PHP developers because all they know is that there are a ton of them around. Meanwhile, people who've mastered more powerful tools and can produce more work of higher quality are being excluded from contracts for trivial reasons.
Why is it not good for the web? Unless an insecure website is leaking personal information, I don't see how that affects you. Besides, how many websites designed by newbies reach hundreds of thousands of daily visitors (or even tens of thousands for that matter)? If said website is so terribly designed, no one would visit it because it would load slowly and be ridden with bugs; no fun.
Even if it's a dried up subject, the blog is comprehensive and concise enough to almost be reference material. Everyone knows PHP sucks but this is a damn good illustration of why.
You probably also shit after a bad meal to get it out of your system, but although you may have convinced someone to not eat the chicken, the rest of the office has to deal with the terrible stench you left behind, when you could have just gone home and taken care of things in private.
People have been writing murder mysteries for the past hundred years, and some people are still writing murder mysteries, and some people write them in the hope of selling millions of copies. There’s nothing wrong, in itself, with writing about a topic that has been written about before.
For someone coming from other language background, including C#, JavaScript, Ruby, I find PHP absolutely unconventional, odd, unexpected, and inconsistent.
This is not a language, where you expect intuitively on what method to call unless you do a StackOverFlow search on existing problems, raised by others like me.
Yet, I currently develop a web app on PHP. Certainly, I can't wait to move over to Ruby or other languages in my next project.
The author is stating the obvious. But he/she has every right to do so, because PHP is simply not user friendly enough to programmer. If PHP truly targets non-programmer, they totally succeed in their goal.
I'm not defending PHP, and I'm not claiming the author "has no right" to make their post. What I am saying is that this post has no value, as it's simply a summary of the same posts we see here week after week. This isn't just stating the obvious, this is literally rehashing the posts (he even cites the sources, which I do commend him on) that have already been made.
The point is the PHP circle jerk is getting old. I don't see the value in repeating the same discussions every day, and most of these posts just reek of exploitation- these authors know php bashing will get upvoted, so they write an article, submit it here, and wait for the traffic to pour into their otherwise unknown blog. I just think we'd all be better off if they actually wrote something useful.
To be fair, while the author is a friend of mine, he's not the one who submitted it, nor did I consult him before doing so. So if anyone can be claimed to be exploiting this for upvotes, it's myself, not him.
What I am saying is that this post has no value, as it's simply a summary of the same posts we see here week after week.
Actually, I would state that, "a summary of the same posts we see here week after week," does indeed have value. Now you can bludgeon the next guy who posts a PHP rant with a link to this one.
Yeah, I'm tired of PHP bashing too -- BUT! -- this is probably the best written article on what's wrong with PHP that I've ever seen. So... kudos to the author for a good argument.
I admit, PHP sucks. But there is one thing it has going for it. It's simple to configure and secure a server that your general userbase can run applications on. I work at ITECS, the Engineering IT department at NC State University. ITECS is responsible for maintaining the server infrastructure for dozens upon dozens of university Web sites, most of which have dynamic content. Not to mention the people server, which anyone affiliated with the College of Engineering can get directory space and a MySQL database on.
I was once talking to our Systems people about, why not allow Python applications. They said that every time they have experimented with allowing CGI scripts in any language supported by their Web servers, someone has always found a way to exploit their sandbox. With PHP, the applications can still get exploited, but they have never had a breach that affects the servers themselves.
So if you're a startup or a major tech company who can spend time customizing a Web server and trust everyone who has access to it, then you're crazy for using PHP. But if you're a college with 8,000 students, almost 1,000 faculty, and a bunch of support staff in addition, and a good quarter of them need Web sites, PHP's pretty much the only option that will keep you sane.
In my opinion, that's something that seriously needs fixing. But it's certainly an explanation for why PHP is still around now.
That's odd, because usually servers get owned from faulty wordpress/joomla instances. I rarely hear of web servers getting rooted via web apps run on python. I'm not really an experienced php dev myself, and when I installed joomla on my vm last year, it was rooted within the hour -- I was notified by a data center admin saying my vm was using an insane amount of bandwidth. I'm sure it was some script scanning for boxes with slightly old versions of joomla. I haven't had the same kind of bad luck installing python apps.
The PHP on our servers is also ridiculously locked down due to a combination of php.ini sandboxing settings including open_basedir (which AFAIK no other language has out of the box) and very strict AFS permissions (the server only has access to your specific Web locker, and it only has write permissions if you specifically enable them in the locker portal).
Whoa. Definitely don't run Python as CGI. Use WSGI, run your app as a devoted low-priv user, proxy to it. Then you have only one entry point; there IS no sandbox, and nothing to exploit.
I agree. Why not run the webapp as the user account the code belongs to. With virtualenv and pip, normal users can install modules into their own site-package in their home folder, and any runserver started as them will only have permission to access anything they have access to. The only thing that is possible to exploit is what they've allowed in their code, but that's pretty much the same issue you have with php.
Because (a) mod_wsgi is nowhere near as easy to sandbox as PHP (again, php.ini settings), (b) configuring proper production servers to run as specific users is a pain, and (c) this is a university where people have access to sensitive student information and research data in the AFS system. How bad do you think it would be if a random student could exploit their professor's site and change their exam grade?
Since my day job is PHP-centric and I was already aware that PHP is awful, this is theoretically helpful to me, but oh lord, it makes my liver hurt.
If I could get away with it, I'd never again trust my credit card number to a system based on PHP, but I suspect that that's about as easy as never trusting your credit card to an ATM/point-of-sale machine based on Windows.
I can't believe that this is a real thing. The fact that a (purportedly) serious language runtime designed for web applications would have this in it seems like a staggering breach of professionalism.
A nice long list of things all concisely put into one blog - I'm sure this took some time to write. Can we move on though? Seriously - no one's forcing you to use PHP, so in your own worlds "It has paltry few redeeming qualities and I would prefer to forget it exists at all." do just that - forget it exists and wake up tomorrow a bit less grumpy. Trust me, you'll feel better!
There are those of us who have been forced to use PHP, and quite honestly, we could use a few good round-up posts of why there are better choices for a project these days than PHP.
Sometimes we can't forget that it exists, so we try to educate people so that with a little luck, they won't pick PHP for their next project.
You may be able to do some fancy (i.e. useful and profitable) stuff in another language and show it to your boss. Maybe do this in your spare time while learning another language for fun. It may impress them!
No offense, but you should really find the time to learn. That's not a hit against PHP (which I don't care much about one way or another; anything good enough for Facebook but full of such a large number of gotchas can obviously be read either way) and it's not even a comment about the marketability of your particular skill set.
Instead, it's just intended as a friendly reminder that you, not your boss, are in charge of your life. :)
Hm. I think my choice of words weren't adequate to describe my situation.
It's not that I don't know how to do other things. It's that the things that I'm capable of doing put me in a narrow niche. With a long-standing back injury and medical problems resulting from exposure to chemical allergens, there's very little work I can do in the light industrial sector.
I have training as a carpenter (and I can do everything from foundation and framing to roofing and finishing - I have the training), but I'm no longer physically able to do it.
The list of programming environments I'm comfortable in is quite long, too. It's just that my choices are PHP, C#, and Ruby. And the PHP guys are the only ones hiring. I really should move to Seattle or something, but the cost of just getting there is a little over what I can do.
I got into the web space through WordPress and naturally progressed into learning PHP. There are times that I wish I could work with another language just as well as I can in PHP.
I've attempted to learn Ruby. I know C++/C#/Java/Objective C. Yet I still come back to PHP. I can't explain it. I like PHP. I understand PHP. There are nice people willing to help me with PHP. PHP does what I ask.
It's not the greatest. It's no MIT Graduate. But I like working with it. PHP works hard and fast, plus it's a little fun.
I feel there is more important stuff for me to do with my life than worry about the structure of a common language.
I don't know, if anyone can help me understand my attraction it would be most appreciated.
If I had to guess I'd say it's fear of the unknown combined with a reluctance to embrace new ideas on some subconscious level.
You should give Ruby or Python a shot as an alternative. C# comes with all the .Net baggage, it's a whole different game, and Java is far too enterprise for someone living in PHP-land.
There are things that are stupidly easy to do in Ruby and Python that are virtually impossible to do in PHP, and these are things you do all the time. PHP's feeble list transformation routines, which are a fundamental operation in even Perl, are a huge problem.
If you think PHP is fun, you would love a well designed language.
I actually have to agree. I started out my programming experience with C# -> PowerPC (strangely) -> C++ -> touched upon PHP -> Java -> Python -> Objective-C. Out of all of these languages, Python was by far the easiest and most flexible language to learn.
I've never done any sort of web development at all (no HTML, CSS, JavaScript, etc.), but I set up a local Django server to do stuff with, and I absolutely love it. I learned Pyton for web development, but I can really see it coming a part of my future projects.
> EDIT: note to self "-x points" = x many people with limited sense of humor or very old and don't get it.. /sigh..
HN is not a site where you just drop a meme image and walk away. Humor on the site is appreciated if it's contextually relevant and clever. This isn't Reddit.
I'll preface things with, I don't care about the cleanliness/consistency/correctness of languages, I really just care about tools to get a particular job done.
PHP isn't sexy, hell, it might be classified as a backwater these days. Fact is, it is a simple language, it works, and a whole lot of useful tools are built on top of it. I've done many bad things with PHP, some I will admit to, some I won't. Hell, I built a bunch of authentication services and prototyped a storage backup system using PHP because it was the most mature language at the time (this was years ago, and mod_php was light years ahead of mod_python, ruby wasn't even in the discussion). It worked, the security issues were known, and we knew how to scale the system.
The first post on http://anodejs.org a couple of weeks ago was pretty amazing. The title "We work at Microsoft and we use node.js". That statement in itself was amazing (you wouldn't have seen that 5+ years ago), but the use of Javascript in a large company/large team environment is an interesting exercise. My experience is that a team of 4-6 people working in the Javascript/Node server side have to put tools in place to ensure code quality and consistency that was never needed in PHP.
Each language has it's strengths and weaknesses. In the case of PHP, it isn't sexy, it is pretty homely, but a lot of people are still getting a lot of stuff built using it.
You know, with Microsoft people using node.js, Microsoft is actually really friendly towards JavaScript at the moment. They have made proper JavaScript debugging tools and Visual Studio integration!
PHP is just an interpreted C and standard libs all rolled into one. The first version was literally a set of macro's. PHP has baggage that other languages don't because of its immediate and rapid super popularity.
If you look behind each one of the features you will find that they aren't 'design decisions' but rather a consequence of circumstance.
Most of what is being discussed in this post doesn't really matter because:
a) most PHP developers will never touch some of the smaller nuances
b) newer versions of PHP are changing things (and people still keep using older version. there was an entire holdout movement with version 4). this entire post could have been pulled from the PHP issue tracker.
c) super duper huge websites and web applications are being built with PHP
I don't consider myself a PHP developer, but the argument about it being useless in spite of all the evidence is just ridiculous.
Like many, I've grown up with PHP, and grown to dislike it big time over the years. However, it has its virtues. Now, my rule is: use PHP iff it feels like the entire script could comfortably fit inside one small PHP file. The moment my very first design feels like it's better to, say, separate the view from the controller, use a real language. Sometimes this estimation is wrong, and I end up rolling my yet-another-PHP-microframework over again, but usually this is a pretty decent rule of thumb. I don't want to have to go through setting up a VPS and a rails environment for something that'd take me the same time to coe and deploy in PHP.
Really, PHP is excellent for what it was originally designed for: little server-side scripts that do relatively simple things. I know that its authors would currently like it to be used for more than that, but, well, don't.
As long as you're not making a massive application, PHP's massively filled global scope, decent batteries-included approach, documentation-with-examples, and its support on virtually every web host (and then some) make it an excellent choice.
Therefore, I disagree with the author's notion that it's bad for everything. It's excellent for little scripts, which is was mr Lerdorf originally intended it to be for anyway.
I used to concede that PHP is appropriate for little scripts, but I changed my mind over time, because so few of those scripts stay "little". Where is the line drawn? Do we find we need a new feature one day, decide that's enough to tip the scale, and set out to rewrite the thing—wasting all the time purportedly saved by writing it in PHP in the first place? We're lazy, so probably not.
I tried writing a little one-off Python thing in Flask last year and was actually surprised by how little effort it took. I spent more time learning Flask (and Flask is really, really simple) than I did actually deploying the thing to a VPS with spare cycles. It could stand to be slightly more turnkey, but running a tiny app server isn't nearly the nightmare it's made out to be.
All those words, and yet the word template only appears once. And that's to assert that PHP has:
…no template system. There’s PHP itself, but nothing that acts as a big interpolator rather than a program.
As if that was a bug and not a feature. PHP succeeds because there is one PHP templating syntax and it is called "PHP".
PHP started life as a templating language, and that's where its soul lies. Which is important, because if a non-programmer wants to start editing dynamic HTML pages, most likely the first thing they open in their text editor will be a template. And if a customer wants to change the website, but doesn't want to pay a highly-trained programmer (we're very expensive, especially because none of us really wants to be paid to edit templates all day), they'll hire someone who knows how to edit the theme. For every seasoned programmer in the world, there are half a dozen themers who know how to edit HTML and CSS, and maybe how to embed a "foreach" loop that calls a stock WordPress function, or edit an argument list, or swap one Drupal function name for another. And for every themer there's a dozen non-programmers who dream of knowing enough to be themers.
This class of user is what every other platform tends to neglect. Ruby and Python programmers tend to design tools that are intuitive to other programmers. We build "frameworks", where one must tinker and monkey-patch and fork to such a degree that only another programmer can download and assemble a working system, let alone customize it. (One word: Gemfiles.) We write programmer-centric documentation filled with jargon terms from Javaschool, like "object". (PHP themers often do not understand OO, and often don't need to. This, all by itself, could be why PHP is so popular.) But one leaves a lot of money on the table when one designs software systems exclusively for users whose programming education entitles them to six-figure salaries. There aren't enough such people on earth; that's why they earn six-figure salaries.
Designing the minimum viable product for borderline-non-programmers who want to tinker with dynamic web pages is hard work, though. PHP evolved into that niche, but if you don't start there it's hard to steer there deliberately. For me, trying to remember when object inheritance and version control and function definitions were mysterious is like trying to remember when I didn't understand algebra. (And, believe me, I really didn't understand, once. But I'll be damned if I can remember why not.) It's so hard to keep one's eye on that ball that even the PHP developers lost the plot long ago: PHP has long since bulked up with features borrowed from other languages. But if you ignore its newer features the soul of PHP is still a little templating language that you can edit into the HTML on your server; change a filename extension and reload and you're good to go. And, the thing is: You can write a crazy-complicated core system in PHP, but then expose it as an API at the template layer, and those tinkerers hacking at the HTML on their servers will be able to use it.
Yeah, but what drives programmers nuts is that most of the problems in the language are totally independent of that ease of accessibility.
Is there something about consistent naming, or consistent behavior of different library functions, or consistent syntax and operators -- they can be lenient and type-coercing, but consistent, like Javascript's -- that would make it a worse language for people to wade into in the form of templated HTML? Of course not. That's what irritates people, the endless parade of bad design decisions that appear totally bad, with no upside, where they could have just as easily made a good decision and didn't.
But these irritations are only apparent once you're inside the PHP conversion funnel. And, as I have observed time and again as a pro PHP developer, once a PHP programmer knows ten lines worth of PHP it is easier for them to struggle through the eleventh line than to start over with another system.
The entrance to the funnel matters, a lot! Everyone passes through it, and the bulk of your user base will never even leave it. That's my theory of PHP's apparently inexplicable success. (It also explains a lot about every other platform's userbase, by the way.)
And it's not as if one can't master PHP to the point that one could build, say, Facebook: It's empirically evident that one can build Facebook, WordPress, and Drupal in PHP. And, though PHP eventually turns into one gotcha after another - almost immediately, actually; the array() semantics are an absolute horror show - at every single step of the PHP experience there are ten people stuck on that step along with you, and you're all being coaxed ahead live, on the internet by the ten people who are stuck one step above you. So it eventually works out, at least as well as any good hack does, and trying to pretend otherwise doesn't fool anyone. You can try to tell people that PHP can't possibly fly, like the scientists in the urban legend who allegedly tried to claim that the bumblebee can't fly, and they'll smile at you and go back to struggling with PHP.
The question implicit in your comment is: Could we design a system that offers the ease of accessibility of the first few steps of a PHP programmer's career but, as one climbs the learning curve, eventually blossoms into Python or Ruby or even Lisp? I wish I knew. My best guess as of this morning is that a demigod could design such a system, but it's very difficult for mortal humans to do so, because once you know how to program it's hard to avoid overdesigning, putting in things that will eventually be useful in year two but are discouraging in year zero. We make terrible pedagogical mistakes, like turning everything into an object. (Does your ORM seem intuitive to you? That is why PHP is beating your system in the marketplace.)
I’ll never understand why people feel the need to criticise another language. Certainly between PHP, Ruby and Python all the languages are great and have their own pros and cons. Its not like any of them are evil corporations trying to do the world a dis-service. They’re all open source and there’s enough room on the internet for all of them. Heck there’s even enough space to get a bit of C programming in.
I don't think that those problems are really independent, but rather, share a common cause with some of the things that made PHP a success. PHP evolved as it did in large part because its benevolent dictator refused to think about more than one problem at a time. I don't argue that that's the optimal way to do things, but it did provide a unique experiment for us all to learn from.
PHP is not a good tool for quickly getting a minimum viable product. Despite its flaws it is a good weapon for fighting 'the last war' - that is to say, it makes it quick and easy to make what are essentially the CGI pages of 1996 - but if you're doing anything more complex than that (for instance interacting in any way with a database), and I would suggest that even relatively non-technical people looking to use computing technology for a business are in Anno 2012, there are many better systems available which do not expose the novice or intermediate programmer to nearly so many pitfalls.
An important thing to remember about PHP is that it really isn't stuck in 1996: When we say PHP you need to think WordPress, or Drupal, or CakePHP or Symfony, since that's what one actually uses nowadays. Novices are steered away from code that pipes SQL injections directly to the database, and toward one of these frameworks, which does the heavy lifting for you so that you don't need to reinvent the wheel.
For years I consoled myself by calling myself a "Drupal developer". I'm not a PHP developer; if I weren't using Drupal I wouldn't touch the language with a ten-foot pole.
But I agree that basic PHP is optimized for the style of web development that dates back to 1996: Server-side rendering of HTML templates. (More powerful PHP - the underpinnings of the PHP frameworks, the stuff one gets in the latest versions like objects and namespaces and closures - basically turns the language into the equivalent of every other scripting language, though obviously much more inconsistent; there's no great reason to choose any of that over Python or Ruby except that it degrades gracefully to PHP, which may actually be very important, but only so long as what you're building looks superficially like a server-side-rendered HTML template from 1996.)
One reason why I'm spilling 10,000 words on PHP is that I've been working with it for five years now, but I'm having trouble getting excited by its future. It has a long future, because 1996-style web sites are not going anywhere: WordPress.com has a zillion users and Drupal is taking over the enterprise and, well, Facebook. But one eventually gets tired of living in 1996. And PHP is useless for client-side-rendered "HTML 5" views, or mobile app client development, and its advantages as a templating language become moot if your server-side code is just an API coughing out JSON objects RESTfully. No newb can figure out that stuff today - even wizards can't agree on the proper semantics of REST, for example - and if ever we do develop a framework for designing RESTful APIs that's as easy for novice programmers to pick up as PHP is for 1996-style templating, I'm betting that framework won't be built in PHP.
I actually find php well suited to client-side rendering. Implementing a web service in php is pretty easy. The only thing i use php for is building json-rpc and soap services using zend framework's service classes, wrapping around zend framework's database classes. The app itself is all javascript.
True, and if this is all your server-side needs to be, while there's not much reason to prefer PHP for this above anything else, there's also no reason not to just keep on cruising with PHP.
My experience running PHP cloud services suggests that, operationally, PHP is a dream. It's the least problematic layer of the LAMP stack, at least once you've learned what the words "APC cache" mean.
What would you recommend as a starting language to build a MVP? The extent of my experience is html/css, manipulating wordpress php files, and a weekend hacking together a couple of learning projects (a PHP blogging platform and a "rank this list of items by number of upvotes/this number" website).
Given my past experience I was planning to use PHP as it is the only language I have any experience with and while the functionality I'm shooting for is totally different, I don't envision it being any more difficult to code than the blogging platform. I will be interacting with a database.
Are the other options as easy to pick up as PHP? Is it as easy to google for help?
I'd say that using Ruby with Sinatra is really easy to pick up - the documentation of Ruby itself is great and Sinatra is also documented really well, not that i think it's particularly complicated. Use an easy template-engine or stick with the default (erb) and (at least for the beginning) the sqlite-gem.
Of course, that was my impression given my prior knowledge, which of course influenced my start with that environment. But i found it to be great almost instantly.
I'm not surprised. A big advantage of PHP's database layer is that it doesn't reinvent the SQL wheel.
[set Greenspun Cynicism Level to MEDIUM HOT]
Other platforms wrap up SQL to the extent that you are encouraged to pretend it does not exist. This is an irreplaceable killer feature if you are trying to encourage new programmers to design things that will eventually prove difficult for them to optimize, or are trying to drum up membership in the NoSQL-silver-bullet-of-the-month club, but in the end what was good for 1996 is still pretty good for 2012: Pull the data from the database using classic SQL from the 1970s, loop through the result set, paste each row into the template, and ship it out to Apache.
PHP does this transparently, which makes it relatively easy to figure out what is going on. Of course, what is going on may be "the novice PHP programmer is staring directly at the SQL but still cannot optimize it", but hey, at least now you can see the problem.
There are also modern libraries for a plethora of other RDBMS and NoSQL systems (I think PHP is even going to support mongodb natively soon i.e. no third party client library required).
I've done quite a bit of PHP development, a lot of more advanced stuff (Earlier in this topic I linked to a PHP Daemon library of mine on Github).
But PHP has either missing or NOTORIOUSLY inferior Memcached/Redis/Mongo/Cassandra/HBase/Riak/etc clients. They get the job done, but they underperform, say, Python or Java versions in benchmarks and introduce far more bugs and quirks than I've experienced in other languages.
This has actually been a positive thing, because when you're using these data stores/queues/etc at scale and you need bulletproof client libraries, you naturally are led to a SOA. You end up with Python/Erlang/Clojure/Java services that interact with the datastore, that you consume from PHP using Thrift et al.
But being so bad that it pushes you into building a better architecture is kinda a preverse benefit
I haven't used a PHP nosql client library at serious scale so I will bow to your better experience (although in the case of Redis clients, some links would be nice as I wasn't aware that the two major PHP clients had any performance/reliability problems - I'm very surprised that https://github.com/nicolasff/phpredis under performs given it's a C extension).
Having said all of that, if you are building a site that uses NoSQL and needs to scale to millions of simultaneous hits you'd be insane not to develop it with SOA in mind. Using just PHP (or any other single language) wouldn't make sense.
I may have been making that up re: redis, honestly. It's guilty by association in my mind, but I've used redis in PHP a lot without any first hand problems.
But Memcached, certainly (and even doubly so for the `Memcache` extension that ill-informed developers install instead of the better `Memcached`), and the others listed, either are slower/etc or just don't exist.
Fair enough, I'm sure you're right with some of the other lesser used libraries e.g. Riak. It's probably fair to say it takes PHP longer in general to get a good client library than say Python. Not sure about Ruby.
Please, the PHP industry is stuck on Wordpress and CodeIgniter which are amateur software.
Yes, you can enjoy these wonderful modern tools for PHP at home meanwhile you suffer with old-tier libraries at work because everyone refuses to move forward.
You're right. This is a supply-and-demand problem : which choices does non-programmers or casual programmers have when they want to create an app ? How can someone who's working or studying 40+ hours a week find the time to learn the basics of MVC, inheritance etc ...
There is a demand for easy to create template-based websites and PHP is the only kid in town for this kind of things.
This is no excuse. If you want to learn how to do something, effort is required. How much time will that person waste in the long run battling all of the problems and traps PHP brings with it?
I contend that learning a proper language will be of greater benefit to a person just starting web-development, and putting in just a few extra hours at the beginning to get a solid foundation will in fact save them time in the long-run.
Also, giving complete amateurs this loaded, rusty .44 magnum and pointing them at the battlefield is bad for web security and the web in general, they will inevitably lose all the plaintext usernames and passwords they have in their database.
I agree, but lets say your car breaks down somewhere in the middle of the road.
Now you have two options. One is to learn the entirety of automobile engineering before touching your car, second is to learn enough fix the problem for the moment. Needless to say any normal person will prefer the second approach.
Now some mechanical engineer may make an argument that this small quick fixes are harmful for long term mechanical engineering practices. But for the guy who does this quick fixes, none of this matters or is even relevant.
The effort required to learn something better than PHP is not equivalent to learning everything about automobile engineering, its more like reading a maintenance manual. Sooner or later, the guy who fixes his car in the middle of the road without knowing anything is going to replace his brake-pads with bits of wood he found on the sidewalk (Not really his fault, someone on a PHP forum has already labeled all the bits of wood as "brake pads")...
A better analog than fixing a literal car might be changing the tire of a car which doesn't have any tires when it is parked but which instantiates some with the help of an instance of ITireFactory. Obviously it makes no sense for a car to use a tire factory instead of just having tires. That is exactly how everyone who prefers PHP feels about everything.
There are far better solutions to this ITireFactory problem than PHP, which puts the tires directly onto the car, but forces you to buy a new car as soon every time you get a flat.
Also, the tires are likely to explode every 16 left turns unless you know about the secret tire fixing button under the dash.
It is true that PHP may save people a few hours in the beginning, but at what expense? How longer does it really take to get a noob running a Sinatra, web.py, dancer or something similar?
>This is no excuse. If you want to learn how to do something, effort is required.
Some people doesn't want to learn web programming. They want to get things done.
Think of PHP as an equivalent of Bootstrap on the server side. People don't use Bootstrap because it's beautiful but because they can't design and in fact don't need anything fancier.
Thing is, if we were to consider PHP a templating language in comparison with a DSL like Jinja2 or Twig, we would reject PHP because it is overly verbose, does not have inheritance, is inconsistent, and has no caching by default.
It is so easy to write a fully functional php templating engine too. Here is a quik and dirty example (without error checking etc/ the php way i kid :)
I can't believe this article is on the top of this site. At least 50% of what's written in there is totally wrong/false. Other information is terribly out of date. And even more information is merely half-truths and lack of understanding of the language. Even pure supposition like "PHP was originally designed explicitly for non-programmers" is incorrect.
This article is garbage -- don't be taken by it.
I'm not going to argue that PHP is a great language, but this article is a complete disservice to anyone who has bothered to read it.
Having used php and run across many if not all of the issues the article lists personally I can pretty confidently say it's as close 1o 100% correct as anything I've read on the subject.
The article lists "E_ACTUALLY_ALL" as if it's really a PHP constant. I'm not sure the author has even used PHP -- this is just a bunch of information culled together from different blog posts with very different levels of understanding. There are many things that are just factually wrong with it.
I could complain about PHP all day but at least I know what I'm talking about!
really? that's your example? I read that constant name very clearly as "snark". If that's the best you can come up with then I think you just made my point for me.
> Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter.
The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?
> == is useless.
Actually, it's not useless. It does have a few stupid edge-cases and I will admit that. But in most common cases actually does the right thing and the truth table isn't too different from JavaScript.
> Objects compare as greater than anything else… except other objects, which they are neither less than nor greater than.
Strict-equals on objects compares the references; but regular equals compares the contents of the objects. Two objects compare equal if the contain exactly the same fields and values. Seems pretty reasonable to me.
> + is always addition, and . is always concatenation.
This is a good thing; JavaScript gets this wrong.
> There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
Variables that don't exist issue a notice. You can deal with that just like any other error.
> Global variables need a global declaration before they can be used.
Actually there is also the $GLOBALS array for this. I'll agree that's not much a solution. Globals should just not be used; if you want to use static class variables, it's a much better choice with a sane syntax.
> there’s no pass-by-object identity like in Python.
I'm not sure if I understand this but all objects are passed-by-reference in PHP (since 5) and PHP references act appropriately when used as function parameters, etc.
> A reference can be taken to a key that doesn’t exist within an undefined variable (which becomes an array). Using a non-existent array normally issues a notice, but this does not.
I just discovered this recently and it's a great feature. Obviously an attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly. This can be very handy.
> Constants are defined by a function call taking a string; before that, they don’t exist.
You can declare constants in classes and namespaces with the const keyword.
> There’s an (array) operator for casting to array. Given that PHP has no other structure type, I don’t know why this exists.
You can cast scalars to single element arrays and objects to arrays with the same structure. Both are actually very useful.
> include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.
PHP is interpreted; I'm not sure what kind of module system you think it needs. Most projects don't use include() directly and instead have autoloaders.
> Appending to an array is done with $foo[] = $bar
You state this like it's a bad thing!
> empty($var) is so extremely not-a-function that anything but a variable,
Empty is equivalent to the not operator but will also work on undefined variables -- that's why it requires a variable.
> There’s redundant syntax for blocks: if (...): ... endif;, etc.
Useful inside of templates where matching { } is much more difficult.
> PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.
Yup. I find it very useful on the unlink() function which will raise an error if the file you're trying to delete doesn't exist.
> PHP errors don’t provide stack traces.
Not true. Debug_backtrace() will give you a stack trace in an error handler.
> Most error handling is in the form of printing a line to a server log nobody reads and carrying on.
Assuming, of course, the programmer doesn't do anything to handle errors. How is this different from any other language?
> E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does.
E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will "warn you about code usage which is deprecated or which may not be future-proof." -- quote from the manual.
> E_ALL includes all error categories—except E_STRICT.
Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.
> Weirdly inconsistent about what’s allowed and what isn’t.
Then you go on to be confused why syntax errors would be parse errors but logic errors are not.
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.
This is sort of true; PHP errors and exceptions exist in different universes but it's easy to unify them and PHP even provides a built-in exception ErrorException to do so. You can turn every PHP error into an exception with 4 lines of code complete with stack traces. You could even turn exceptions into errors but I wouldn't recommend that.
> There is no finally construct
C++ also doesn't have a finally construct. But C++ and PHP support RAII -- class destructors run when the stack is unwound so you can do your cleanup. You could that finally would be a welcome addition to both languages.
> function foo() { return new __stdClass(); } leaks memory. The garbage collector can only collect garbage that has a name.
I am unsure where you got this idea from. PHP is reference counted with a cycle-detecting GC. That would not leak memory.
> Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type
This is true, but it's an ongoing discussion on how to correctly handle scalar type hints. For all the discussion about how PHP isn't designed you take issue with the thing they're taking their time on.
> Closures require explicitly naming every variable to be closed-over. Why can’t the interpreter figure this out?
Because of the dynamic abilities of PHP, there is simply no way for the interpreter to ever figure this out. I thought the solution provides was actually a rather simple way of resolving the problem.
> clone is an operator?!
Of course! Why wouldn't it be.
> Object attributes are $obj->foo, but class attributes are $obj::foo. I’m not aware of another language that does this or how it’s useful.
C++ does it. $obj::foo doesn't make any sense, if you're accessing class attributes then you use the class name.
> Also, an instance method can still be called statically (Class::method()). If done so from another method, this is treated like a regular method call on the current $this. I think.
Only static methods can be called statically. A non-static call can be made that way and passed on $this. This can be useful and isn't terribly confusing -- similar syntax as calling parent methods.
> new, private, public, protected, static, etc. Trying to win over Java developers? I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language
PHP classes are basically statically compiled. The class code isn't run, it's compiled into byte code before the execution of the script. This is similar to if you just ran the Java compiler on Java code before each run. It's a design decision that has it's pros and cons.
> Subclasses cannot override private methods.
That is the definition of private methods!
> There is no method you can call on a class to allocate memory and create an object.
You can use reflection to create an object without calling the constructor.
> Static variables inside instance methods are global; they share the same value across all instances of the class
Again this is the definition of a static variable in any language!
> Yet a massive portion of the standard library is still very thin wrappers around C APIs
That is, in fact, the point. PHP is supposed to be a thin scripting language layer over C. It's expanded beyond that. Many of the poor naming conventions are not because of PHP but rather are the exact API of the underlying C library.
> Warts like mysql_real_escape_string, even though it has the same arguments as the broken mysql_escape_string, just because it’s part of the MySQL C API.
Both the C API and PHP have both these functions for backwards compatibility reasons. Of course, this entire API is pretty much depreciated with both the mysqli library and PDO.
> Using multiple MySQL connections apparently requires passing a connection handle on every function call.
How would you expect that to work?
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it.
Unless you use a code cache like APC. It will eventually be built in but an easily added option. I suspect most people, however, don't need it.
> For quite a long time, PHP errors went to the client by default
If you don't handle your errors, they go somewhere.
> Missing features
Most of these are provided by frameworks just as they are in Python, Ruby, C#, etc. Why would PHP be any different.
> Insecure-by-default
Only if you're using an ancient version. Some of these things are now removed from the language after being depreciated for years.
I'm actually getting a bit tired so I'm going to bed. I didn't comment on everything in the article: some of them are right. But some of them are just different. Some of them have even been replaced by newer methods of doing things.
PHP has been around for a long time -- I remember when I switched from Classic ASP (yes, VBScript) to PHP and it was a dream. Many of things to complain about now, like the kitchen-sink standard library, were a godsend. It also evolved very quickly during that time and I suspect if it hadn't then it wouldn't have caught on enough to be bitched about now.
Just because once you've learned an unintuitive, quirky, magic trick in a language that becomes useful doesn't mean it was worth being added. Many of your counterpoints seem to be "you don't like foo? I find foo useful." miss the main argument: nobody ever said bizarre things like "@" aren't useful in cases where you need them. The criticism is that things like this were just thrown into a giant pile with no regard to consistency, expectations, elegance, etc.
Only a couple of these things are outright wrong; I removed the offending bullet points earlier tonight. A few things I listed because they're weird, not outright wrong, and I stand by those.
For the most part you've defended PHP's behavior as design decisions or offered workarounds. Workarounds just demonstrate that the language is Turing-complete. Design decisions are only okay if they actually make a useful tradeoff; these generally do not.
I can give you individual responses if you really want, but I suspect you won't be swayed no matter what I say. I will comment:
PHP doesn't need a module system? What? Once your program consists of more than two files, you're going to want to import stuff from one into the other in a structured manner.
> A few things I listed because they're weird, not outright wrong, and I stand by those.
But a few things are weird to you but not some objective view of weird. Many of your points I didn't comment on are not unique to PHP at all (such as octal numbers)
> For the most part you've defended PHP's behavior as design decisions or offered workarounds.
You could say that unifying PHP error codes and exceptions is a "workaround" but the language provides specific support for it (The ErrorException class) so it's pretty much a standard pattern. The end developer has the choice of development style.
> PHP doesn't need a module system? What?
I have projects with thousands of files -- as someone else said, Namespaces and Autoloaders covers this.
Let me put it this way: Lisp hackers think that one of the major problems with Emacs Lisp is that it basically uses one big namespace for everything, forcing awkward naming conventions and contortions to avoid collisions. That is possibly the one part of any Lisp that works like PHP ... and the Lisp community pretty much universally agrees that it's a bad idea, not because it's like PHP, but because it's a bad idea.
Of course one big namespace is a bad idea and everybody knows it. I'm not sure why that's relevant here. Namespaces was always the #1 requested feature for PHP.
PHP does things differently; you don't import things before you use them -- PHP loads modules/classes as necessary when they're used. If you don't use a class, it's not loaded.
Other features of PHP make things like "import *" impossible (or at least very expensive) but at the same time it's also much less necessary.
>PHP doesn't need a module system? What? Once your program consists of more than two files, you're going to want to import stuff from one into the other in a structured manner.
PHP has a module system: Namespaces and the class autoloader.
So, do you want the PHP to be a clone of python? PHP works for some and python works for others. Do we really need a FUD to convert people? Hint: read python sucks articles from Ruby rockstars.
Nearly every other item is wrong; I didn't bother listed them all because it would just take too long. I'm actually still reading the article since I posted that comment and I'm still finding errors.
You would do us all (author included) a favor by pointing them out. Why would you take the time to complain about the articles veracity without providing a single correction?
If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery. A selection from the OP:
> Because of the @, the warning about the non-existent file won’t be printed.
So your complaint is that when you use @ to suppress an error it... suppresses the error?
> The language is full of global and implicit state.
"Global" is one of those dogmatic points. Nothing is truly "global" in PHP. The "global" in PHP just means it is request-scoped (ignoring $_SESSION, which is explicit anyway).
Do people complain about request-scoped data in any other language? No. The PHP haters just decide to hate this largely due to the (somewhat incorrect) label of "global".
> There is no threading support whatsoever.
That's a good thing. It forces you to use async HTTP programming or something like beanstalk, both of which are better than the complexity of threading.
> array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don’t find it at all.
So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?
> In, say, Python, the equivalent .index methods will raise an exception if the item isn’t found.
I, for one, hate throwing an exception when an item isn't found. This sucks:
try:
index = a_list.index(a_value)
except ValueError:
# do something
- 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
Yes, you have to use --- and basically understand that otherwise 0 == false. So what? In C/C++ you also have to remember to use == not -.
> [] cannot slice; it only retrieves individual elements.
Much like Java/C/C++. PHP has array_slice() if you want it.
It's since been redacted but the OP originally claimed that Facebook doesn't really use PHP (because, hey, that fits his world view).
Look, I could go on but really what's the point? Haters gonna hate.
Sure it would've been nice if PHP had been consistent with, say, parameter ordering (needle, haystack vs haystack, needle) and function naming (sometimes using underscore, sometimes not) but really none of that matters. If you use it, you soon remember. Humans are built to understand inconsistent languages. If we weren't, we wouldn't be able to speak to each other.
Some like to argue that PHP is a beginner's language. I disagree. I think PHP is a fine language for just throwing something together... if you know what you're doing. Otherwise it's just a recipe for SQL injection and XSS vulnerabilities.
A common mistake with PHP is people try and turn it into Java with complicated object frameworks. There is typically lots of hand-wringing about OO'ness.
The procedural style is actually very natural for serving HTTP requests. The core of PHP is a stateless core of API functions. This is incredibly useful for keeping resource usage down. Much like the old CGI model, the entire environment is created, used and destroyed on each request.
This is a feature not a problem. Anyone who has done Java Web development (with stateful servlets or any derivative) should know this as it is virtually impossible not to have come across resource leakage and concurrency issues at some point. The stateful model, while useful, has a significant cost.
I really don't understand this need to complain so vocally about something like this. Possible reasons:
- It affirms the OP's sense of superiority somehow;
- It's about "street cred" with [Python, Ruby, Node.js, insert other language here]; or
- One is so obsessed with "purity" that one spends all one's time complaining about how everything isn't Lisp.
Use it or not. I don't care. If you're not going to use it, why complain about it? If you are using it, what does the public snobbery (which is really adding nothing new to all the other PHP rants) really add?
I'm a big fan of pragmatism and the fact is that 4/20 of the most visited sites on the Internet are written in PHP.
EDIT: /sigh/ I get the inevitable "you must be a PHP programmer" retort (like that's actually a retort and not just more snobbery). For the record, I've only used PHP for ~6 months. My main experience is Java (~14 years), Python (~2 years), C (~5 years) and C++ (~4 years).
> So your complaint is that when you use @ to suppress an error it... suppresses the error?
From your edit, you've only been working with PHP for about 6 months, so you may not have seen some of the code most others have. Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything. Now your client/boss/friend is pissed because when someone submits their form and they have a space in their name, the entire site crashes, and you have to figure out what's causing it through a tangled web of spaghetti code with no errors.
This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code.
> If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery.
This isn't anti-PHP snobbery. To write it off as such is an attempt to dismiss most of the (quite valid) complaints. And complaining about someone complaining is really only highlighting your own hypocrisy.
As you said, you really don't understand his need to complain. That's fine, but many on HN do. This was a great write-up for all of PHP's downfalls. Some of it is really only complaining about how PHP isn't Python, but there are a lot of fantastic points about language design and how PHP sacrifices consistency for... really no reason at all. So don't assume every complaint about a language is "snobbery" or an attempt at "streed cred" (wut?) Instead, ask yourself why there are so many people writing so many complaints about this one language. Then, ask yourself why you're writing them off.
> This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code.
I do maintenance for a lot of PHP sites at my job, and the code is staggeringly difficult to debug or modify. It's punishment for my sins.
PHP was a tool for generating textual data structures (HTML) and it should've been leveraged by another tool for control flow and business logic, but it wasn't. The code I maintain is pre-frameworks; it's got no DRY, no separation of concerns, no design forethought at all. It's just HTML generation that satisfies its needs as they arise.
Now PHP is a quirky, mediocre, and capable language that's still really good at generating HTML.
> Can you imagine, then, diving into a website's back-end to see @ all over? It turns out, the previous developer realized all those nasty notices and errors stopped happening if he slapped a @ on everything.
You've turned something that's a person's fault into something that's the language's fault.
Other languages have some sort of warning suppression as well, like Java's @SuppressWarnings or C#'s #pragma warning disable. Although they won't suppress all errors like PHP does, it can still bite you if you don't fix them.
It IS snobbery. You're taking a look at other people's code, and judging the language from it. I've written PHP for about 3 years and I've never once used the @ to suppress errors.
GC is not about preventing memory leaks, it's there to make managing memory easier not automatic. One of it's biggest advantages is the ability to deal with memory fragmentation which is ridiculously hard to do well in C++ style languages.
You can write bad code in any language. It's the programmers responsibility to make sure the stuff they are writing is good and that only comes from experience with the language.
Of course you can. But is it always an equal share of bad code for each language?
If not, then you have to admit that the language itself will encourage or discourage bad code or bad coders.
The article tries to be a comprehensive list of problems with PHP and @ is a notorious one, even if you personally are disciplined enough to avoid it.
Not to mention that I have no idea why the original commenter picked on this. It was listed as one of the 7 or so things that can go wrong with that one single, not unusual line of code. It's not like he had a whole paragraph about why @ is bad.
> The article tries to be a comprehensive list of problems with PHP and @ is a notorious one
Nonsense. The @ error suppression is a tool, just like any other. It should be used sparingly, but it does have its uses. I have been writing in PHP for over a decade and I have used it exactly one time. And yes, it irritates me when I see it in other's code all over the place ... which is why I refactor all external PHP code before I place it inside of mine.
The amazing thing about PHP is that it has a plethora of tools available and the language doesn't force you to write code in some constrained manner according to what some snob perceives as the right way. The only right way is the way that works and works well.
You don't like a feature of PHP? Don't use that feature. Simple as that.
Ok, let me fix that: "The article tries to be a comprehensive list of problems with PHP and @ is an error suppression tool that is notorious for being misused throughout the community".
> I refactor all external PHP code before I place it inside of mine
> You don't like a feature of PHP? Don't use that feature. Simple as that.
I don't know anything about you, but judging from that attitude you haven't worked in many teams. Of course it's not as simple as that. If I had a penny for every time I had to fix someone not checking that strpos() === FALSE, well, I could fund my own startup. You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.
> I don't know anything about you, but judging from that attitude you haven't worked in many teams.
I haven't worked on any teams. I've always written software solo. What of it?
> You may have the luxury of refactoring all over the place, but the reality out there is that horrible code like this is left to fester until it causes real business damage.
Refactoring is not a luxury, but a necessity. Not only do I refactor other peoples' code, but I refactor my own. That's the only way to get to a quality code base.
> I haven't worked on any teams. I've always written software solo. What of it?
Well, that means you have zero experience with the majority of concerns expressed in this thread, and so are not qualified to opine on them. You work in a happy bubble and I envy you for it, but in the real world you very very rarely get the go-ahead to refactor old code. So in the real world, you very very rarely get to see a quality code base. In any language, really, but PHP compounds this problem with its idiosyncrasies. But you wouldn't know about that.
Isn't the fact that you have to refactor so much of other peoples code an indication that something might be wrong? I'm not familiar with the PHP ecosystem but I don't know of many people having to refactor Ruby gems.
> Other languages have some sort of warning suppression as well
But there is a huge difference here. PHP directly encourages it, making it so easy to do "just prefix it with @" and dedicating a part of the core language syntax to it (thus spending such a nice character for such a triviality). I believe (correct me if I'm wrong) that in Java, it is just another annotation, and in C# just another preprocessor directive.
And I think that's what the article is about - so many things are wrong in the very foundation of the language.
In Java annotations can be used to ignore compiler warnings, not runtime errors.
To get the same effect as @ you'd have to use try {} catch {} blocks all over the place and leave the catch blocks empty, as with any other language with runtime exceptions. Sadly this is done more that one would think...
But that was exactly my point. When you do it in Java, you are obviously doing something wrong (or at least not intended to be done). It just looks wrong at the first glance, with empty blocks and all. In PHP, it's just a single character prefix, no bother at all to add, and looks just like any other sigil. Its usage is definitely not discouraged by design, quite the contrary.
> I've written PHP for about 3 years and I've never once used the @ to suppress errors.
Is it so wrong to use @? I've always used (@$_REQUEST['foo'] === 'bar') as a shorter way of writing (isset($_REQUEST['foo']) && $_REQUEST['foo'] === 'bar') - I'm curious if there's a problem with that approach.
"This is the norm in PHP because, like the author said, it makes it incredibly easy to write bad code."
PHP makes it extremely easy to write ANY code. But since article saying "I've noticed this piece of good code in PHP" is not going to get on HN anytime soon, you get much more attention to bad one. That's like saying Internet is the source of filth because it makes easy to post bad stuff. It makes easy to post all stuff, that's the point.
"This was a great write-up for all of PHP's downfalls."
These "downfalls" are known and discussed 1000 times. Really, who needs another article about "PHP sucks because I can find 3 functions with inconsistent parameters"? How exactly it is going to make anything better? What exactly does it contribute to the world?
No. PHP makes it easy to write bad code and between normal and challenging to write normal code. This is why Doctrine, the closest thing PHP developers have to SQLAlchemy, needs three ways to declare table and column metadata: a separate YAML file, a separate XML file, and in PHP comments. All three of those methods are awful, and only one allows you to keep the metadata and class in the same file.
> These "downfalls" are known and discussed 1000 times.
And, like a wiki, it's useful to have them all in one place.
And again you make the same mistake. You take one solution, you say it doesn't work like your favorite solution (while obviously all proper solutions should be done exactly like the one you prefer, since there's only one right way to do anything and it's, not surprisingly, exactly the way you prefer) and you make it the fault of the language used for it's implementation. How that even makes sense?
I write code in a number of languages, and there's nothing "challenging" in writing proper code in PHP. The fact that your example has nothing to do with code quality or language only underlines that.
> "And, like a wiki, it's useful to have them all in one place."
Maybe, but that article isn't it.
PHP has a wiki: http://wiki.php.net/. You want to list things you want fixed in PHP and have it in one place? Ask for an account and maintain a page there. Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.
Maybe my point wasn't clear. It's not a difference in how those two ORMs accomplish their goal; it's that PHP doesn't let you do what SQLAlchemy does, even if you wanted to. Want to write an ORM that uses YAML, XML, or comment annotation in Python? Great! Want to write an ORM that uses classes or objects as column declaration in PHP? Too bad.
> Rehashing old tired "strpos doesn't have underscore and str_rot13 has, oh noes!!! I can't use language with missing underscore!!!" is really stale by now and doesn't contribute anything new.
Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.
> Want to write an ORM that uses classes or objects as column declaration in PHP? Too bad.
I'm actually doing just that; it's not as clean as you can do in Python but it's not outrageously verbose either. Trying to map one languages features onto another is not a valid critique.
I have no idea what you mean by "what SQLAlchemy does" - I'm sure it does lots of things and most of these are perfectly doable in any language out there. You must be meaning some specific thing that is a favorite of yours - and indeed maybe it is hard to do it in PHP (or maybe not - since you didn't tell what this thing is nobody can have any idea). Who cares? I can name a bunch of things that is harder to do in Python that in some other language, but I don't run around shouting "Python sucks".
> Now I think you're just being petty. Obviously an underscore isn't what we're talking about here. Take your straw man elsewhere, please.
What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem. Yes, we know old function names are inconsistent. No, we can't change them because that will break code. If that's what makes or breaks language for you, PHP is not for you, and most languages are not for you, because you're obviously not interesting in solving the problem, you're interesting in boosting your self-esteem by boasting shiniest tool out there. Nothing wrong with it, but PHP is not created for that. If that means for you that PHP sucks, fine, but for 99.99% out there shininess is very low on the list of priorities. So if you want to discuss important stuff, leave old stale stuff like ranting about strpos alone and discuss important stuff.
> I have no idea what you mean by "what SQLAlchemy does"
You must have missed the rest of that paragraph. I specified what it does.
> What he's talking about here is known and talked about for 10 years. It's just function names, it's not that big a problem.
Again, missing the point. Python has these same minor inconsistencies in its stdlib. It's the combination of all these minor inconsistencies with a language that gives you more tools to write bad code than good that makes PHP torturous. It's everything that the author wrote about in one neat little package.
From the very (very) long article you picked somewhat weird collection to defend.
> So your complaint is that when you use @ to suppress an error it... suppresses the error?
This was one bullet-point from a 7-item list. Also it didn't say that @ is bad in any way (perhaps its use is), it was there only to demonstrate error configuration which is clear by the bullets after it.
> > There is no threading support whatsoever.
> That's a good thing.
You are right that for many tasks not even thinking about threads is a good idea, but there are cases where threads are very appropriate. Having the feature wouldn't hurt, would it? (Considering how tied the php is to C)
> So, it's a problem that array_search returns 0 when something is at... position 0? And returning false is just a sentinel value, much like functions in other languages might return -1. So what?
He explained the "so what" in the next few lines. I'll cite it for you: "If you use FALSE as an index, ..., PHP will
silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning"
Having a try statement is same as having to check for the value to be FALSE/-1/whatever, we can agree on that. But letting users write code that appears to work (yet it does not) is not a good property of a language.
> Much like Java/C/C++. PHP has array_slice() if you want it.
PHP's arrays are very different (uniform types) from those of C/C++/(Java?). So why compare them? Other than that, I agree, having slice function is enough. The author could've left this one out.
So two of your points were taken out of context, one was your opinion (two if we count your preference of if over try when checking for errors), and only two were probably justified. Rather strange choice considering you had dozens of options.
> But letting users write code that appears to work (yet it does not) is not a good property of a language.
I still don't see the point that's trying to be made here. Whether it returns -1, FALSE, or you need a try/catch, the programmer still needs to check. To successfully program in any language with an 'index of' function, a check needs to exist regardless...
In PHP, if you forget the check, and have error reporting turned off (which you should), you'd never KNOW you forgot the check, because missing it is only a logic error, whereas an exception blowing up a python script will be caught by the runtime.
> have error reporting turned off (which you should)
No, you should not. You should never have error reporting turned off. You should certainly have it set to not display errors to the client, but all errors should be sent to a log, preferably syslog, and they should be reviewed. Your code shouldn't generate any errors.
The settings related to displayed errors in the page are error_reporting and display_errors. The error logging is a totally sperate group of keys starting with log_
Yes, I know. Like I said, error_reporting on (set to E_STRICT) and display_errors off. And yes, where the error goes is a completely different question.
In production, you should have error_reporting set to something like: E_ALL & ~E_DEPRECATED
And then:
display_errors = Off
display_startup_errors = Off
track_errors = Off
html_errors = Off
ignore_repeated_errors = Off
ignore_repeated_source = Off
log_errors = On
error_log = /path/to/log/file (or syslog)
It isn't just snobbery (though I'm not denying that there's going to be an element of that in the comments, languages make people get religious and weird). Being called in to do maintenance on a php project sends a stab of dread through the heart of an experienced programmer and it's worth understanding why. This article goes a long way towards doing so.
It's important to re-iterate what the article is NOT saying. It's not saying that you can't do awesome work in php, there's tons of great counterexamples. It's not saying that you can't change the world with php. It's not even saying that you can't write a maintainable, legible, beautiful app with php.
The problem with php is that the core language ignores a ton of what we as a community have learned about language design: Be consistent. Make it easy to do the right thing. Make unwise code look awkward. Pick a type system and embrace it. Don't try to magically do the right thing. Be predictable. Avoid action at a distance.
It's not that PHP makes for a great beginner language. So does Python. It's not that PHP has flaws, so does every language. Many darlings of the Hacker News crowd even have some of the flaws from this list. But I'd challenge you to make a list a quarter of the size of this one with Python, or Haskell, or frankly even Javascript.
For the record, the back of "Javascript: The Good Parts" actually has that. It has "The Bad Parts" and "The Awful Parts," in which Crockford goes into more detail with each error than Eevee does, and I believe it's still shorter than Eevee's blog post.
So you disagree strongly. Fine. I happen to totally agree, but that's not an argument I'm going to get in to to since it never gets anywhere.
I am confused by why you think this is "anti-PHP snobbery". What about HN's attitude to cold fusion or to VB? How can you tell which criticism is valid criticism from experienced developers about which tools are good and which are bad and which is "snobbery"?
It's not like experienced developers who dislike PHP for being poorly designed and having a poorly managed community is a rarity. It's very common among respected developers. I suppose that to be a respected developer you must conform to the anti-PHP bias? Does the conspiracy go all the way to the top?
Or maybe a lot of these criticisms are valid, but you disagree for your own specific reasons?
It seems that many people disregard the fact that PHP is a very accessible language to a programming newcomer. You can quickly and easily install LAMP or MAMP and in minutes have a working, dynamic web page (albeit local) along with a plethora of examples and tutorials. This is huge. This shows the newcomer that this mysterious code stuff is actually accessible; that they can create something that works. That's a nice intro to programming.
More programmers===better programs. How can this be a bad thing?
As far as the snobbery goes, to me it just seems like natural human behavior. People need to believe that their beliefs, their choices are the right ones. For some, the easiest way to do that--rather than being honestly objective or introspective--is to degrade what others do.
I agree with the general point but this seems more of an indictment of other languages than a plus for PHP: with PHP, it's easy to get started with the most simple features - and then it takes years to learn how to cope with the language quirks and inconsistencies, deal with outright bugs, and learn a number of non-obvious ways in which your “working” site might be hacked due to a hidden language feature.
There are two ways in which this could be dealt with: one would be for PHP to have a change of religion by the core developers and start a massive cleanup project fixing API warts, adding placeholders to or deprecating the default MySQL driver, etc. This wouldn't be easy but it wouldn't be especially difficult except that the core developers are usually hostile to suggestions that they fix, or even document, mistakes.
The other would be for other languages to start simplifying the learning process - Google AppEngine is probably the easiest intro of all, albeit with a severely non-standard architecture, Rails.app, etc.
I think a language like Python or Ruby is likely to gain a smooth dev server install before PHP becomes less treacherous.
(Pro-PHP flamers: I started using PHP back in 1999. Your arguments are not new.)
Yes, that would be great. An alternative intro would be most welcome. It should, though:
- Be able to start and serve in minutes, across most platforms
- Allow for portable code e.g. the code you create locally should be able to be ported over to an actual webhost with only [S]FTP.
- Not require the command line to "work". At all.
I tried to learn django ~a year ago, and it was an experience wrought with frustration and pitfalls. The documentation was so-so, and limited in resources (or I couldn't find it). The main trouble was getting all the packages/dependencies correct. I am quite comfortable with linux and terminal (again thanks to PHP), and though I eventually got it working, I was turned off enough by the whole process that I didn't do anything with it. My accomplishment was that I got it to work, which for me was certainly still worthwhile as I was still learning, but a newcomer would likely have gone back to Facebooking long before that...
What is dangerous about the PHP bashing in my eyes (speaking with some current experience as a newb), is when someone decides to try and learn programming and they google some stuff about PHP and read endless diatribes on how horrible it is. So they go off and try django or RoR, are met with tough situations with little to no documentation; can't get anything to work, and give up all together.
Whether or not PHP is pretty, it is accessible. The divide that is created by language ideology only serves to hurt the community as a whole, IMO.
HN's fascination with cloud computing and massive scalability is not representative of web dev in the rest of the boring world. The vast majority of web sites out there are powered by shared hosting, where the norm is to cram 1,000 sites on a cPanel server. Apache+PHP makes economic sense in this environment because when your site isn't getting any requests, it uses no resources. But if everybody started running a persistent Django or Rails process in the background, or if every customer had to be given a VPS, hardware and maintenance requirements would quickly exceed what the provider can profitably offer.
I can host a small website on NearlyFreeSpeech for $0.30 per month plus bandwidth, even less before they introduced a surcharge for dynamic websites. One of my old clients is hosted on another pay-as-you-go shared host, where she incurs all-inclusive charges of $0.07 per month on average. (The site is mostly static, with a PHP guestbook.) Like it or not, PHP makes this possible by folding the app server into the web server, and a lot of effort has gone into making such an environment reasonably secure without blowing up resource requirements. Even if you use a regular shared host that charges $8.95 per month, that's still cheaper than a medium-quality managed VPS.
The current state of shared hosting might not be anything to write home about, but the low cost (compared to a VPS) allows anybody, including dirt poor students, to run a web site without being held hostage to a less customizable service that might or might not exist tomorrow, e.g. Posterous. I think this contributes to technical literacy and independence in a small but unique way. Any realistic alternative to PHP had better meet the same requirements.
"The main trouble was getting all the packages/dependencies correct. "
This is the one big problem python has; terrible package management. I can think of 3 different package management systems for python. All of them barley work and the various libraries all require different mangers and different python versions.
This package requires python 2.6. This other package requires 2.5. And now we have separate python 3.x packages. Ridiculous.
Well, to be fair, "package management" in PHP usually means bundling every single package you need with every single app that needs them. Then you upload the whole thing by FTP.
Maybe I'm missing something in your comment here, but - Python and Ruby already have smooth dev server installs. In fact, much smoother than PHP, as you don't need apache or fancy permissions to just run something local.
Start as J. Random Noob: they need to install python, virtualenv, etc. before learning how to create a module, create multiple config files and so forth.
Technically PHP isn't much easier if you need to compile it, configure Apache, etc. but in practice they just pay $1/mo for a crappy hosted account where they simply upload a file and start fiddling.
This is a trivial distinction for a professional developer but there are quite a few PHP users who started with a personal homepage and grew from there – and despite the stereotype, they're not all designers, either. That's why I like the Rails.app idea: give today's bright 13-year-old a nice, easy path to getting something visible and let them get hooked before they need to learn all of this other stuff.
Very low barrier to entry is also one of the reason why PHP ecosystem sucks. More than 95% of PHP programmers never grow up from beginner(at least what I've seen) even after more than few years of use. And those who grow up starts to use other language.
The PHP crowd is mostly filled with "Internet Programmers" [A person who copies code from the internet and pastes in one's codebase, without even reading it, and expects it to work.] And this also applies to all the javascript programmers who can download a jquery plugin and successfully use it in a website.
They even don't know that you can install PHP, apache and mysql separately and use it. For them XAMPP is all there it is, armed with dreamweaver and a ftp client. Most of them will be lost without cpanel.
I've tried teaching a few but all I get is :"go away don't try to be smart in front of me, I know what I'm doing."
Most of you here are smart people. But out there this is what you get from most of the PHP programmers.
Exactly. I don't actually agree that low barrier to entry is a good thing. Languages should be easy for people who've learned them, not necessarily easy for newbies.
That's the real idea with the principle of least surprise. It shouldn't surprise experts. But programming is hard. It's modeling real world processes in the abstract. That's hard. It isn't going to be simple for people who don't know how to program.
More programmers===better programs. How can this be a bad thing?
I'm not sure this is true. Going with the articles example, that's like saying "the more people who know how to use a hammer, the better houses we will have".
OK, say there were only 2 people working on the (any open-source project). How do you think it would look today?
I think it pretty basic an assumption that the more eyes looking at something, the better the chances of finding (and fixing) mistakes as well as finding room for improvement.
It's true in the sense that giving everyone desktop publishing software in the early 90s led to lots of beautiful typography and well thought-out layouts.
I assume that you are being ironic, and you’re right: there was a lot of ugly graphic design in the 90s. This is partially due to the whole grunge-trend…
However: I think today we have more beautiful design that we would have had if the design tools had not become democratized, maybe not in percentage, but certainly in amount.
My speculation: programming --> more programs. Both crap and great ones.
No, but the more kids who have exposure to an easy-to-get-started language will result in more kids that are actually really into it getting that early start they need.
That's kind of over the top, but I'd like to see everyone spend their first six months in any language that doesn't hide your mistakes from you by quietly guessing what you might have wanted and doing something random.
> If you're not going to use it, why complain about it?
I can tell you my reasons: the market. Not all of us can roll a globe, close our eyes, pinpoint a place and tomorrow have a job there. Here where I live, about 80% of webdev jobs are PHP. Even when I do manage to get a Ruby or a Python job, chances are that I will be doing lots of PHP code maintenance and migration anyway. I would like to change it, and I don't know better than to advocate, pro and against.
>> Here where I live, about 80% of webdev jobs are PHP.
I'm getting the impression that this is why a lot of people hate PHP - Money. People don't like that the market is full of money wasted on an inferior language. Perhaps there's a bit of envy in that, perhaps not.
The winners in the marketplace aren't always the best, and it's not easy to change minds. People get religious about the things that make their living, whether it be a programming language, certification/designation or some other thing.
But Atheists aren't going to convert many Christians and Christians aren't going to convert many Scientologists.
In the end, you have to work within the parameters of the market or create your own. I guess for some people, like the OP, it's easier to vent. Nothing wrong with that - we should all speak our minds, but it's not necessarily going to be effective in converting anyone.
Look at the resulting discussion here, the OP's either preaching to the choir, or his message is falling on deaf ears. I don't see a lot of 'a-ha, he's right, I'm switching now' posts.
People hate PHP because it's an incredibly stupid and frustrating language to use, and most of the people who use it don't know anything else. The money comes from them fucking things up, and their boss having to call in people who know what they're doing to fix it (aka. hack it back into some semblance of "working"). The amount of waste that goes on in most PHP shops is what irks me - use the right tool, spend at least 50% less time working around stupid quirks.
> the OP's either preaching to the choir, or his message is falling on deaf ears.
That was the point of the post. If he points people to it, and they read it but still disagree that PHP is crap, then there's obviously no hope for them.
>>The amount of waste that goes on in most PHP shops is what irks me - use the right tool, spend at least 50% less time working around stupid quirks.
Yeah, but why would you care unless you're begrudgingly participating in the PHP industry? It's not your problem unless you make it your problem - i.e., if you're so against it, don't work in a PHP shop, don't take PHP contracts. Problem solved - if other people want to use lame/bad languages, who cares?
The impression I'm getting is that a segment people who hate on PHP are participating in the PHP economy because there aren't as many local opportunities in {insert language here}. To me, that's not much different from the guy who's stuck working in a "lowly" coffee shop because he can't find a job in his field of study, which of course, makes him entitled to be rude to customers and his fellow employees.
Even those of us entirely outside the PHP economy (mobile, desktop, big-iron server) occasionally stumble into a monster of a mess that some PHP idiot left behind, and have to clean it up (usually by just replacing it outright, because PHP isn't worth maintaining).
The money is nice, but after watching the ridiculous waste of PHP idiocy for the Nth time, you can't help but want to get people to stop.
And that's not counting all of the messes that are inflicted on you as a user of PHP - security holes and password breaches or having to interface with some crappy API to get stuff done.
At least with PHP it's likely to be some vaguely HTTP/POST-ish interface, not some XML/WSDL monstrosity...
No, it's not the money. It's comfort, and the opportunity for less compromises when picking jobs. I want to be able to choose between three Ruby/Python/whatever shops and pick one with the coolest people and coolest projects, rather than having one Ruby/Python and two PHP shops to choose from.
And, unlike you, I don't think these articles are pointless. I hope they help PHP get more bad reputation among coders, and peer pressure will do the rest.
To paraphrase something Neil DeGrasse Tyson said to Richard Dawkins: If you want to change someone's opinion about something, you need to be sensitive to the state of mind of the person you're trying to convince.
Bashing and negativity is not the way to do it.
You'll get much farther showing a PHP person something more interesting (whether it be Rails, Django, or whatever) and highlighting all the cool things about it. Because that person will not be on the defensive, his/her mind will be way more likely to have that 'Wow, that's so cool I should try it' moment.
> Some like to argue that PHP is a beginner's language. I disagree. I think PHP is a fine language for just throwing something together... if you know what you're doing. Otherwise it's just a recipe for SQL injection and XSS vulnerabilities.
I could not agree with you more. Advising beginner programmers to use PHP is like handing out guns in a playground, someone is going to get hurt, and it will probably be the users.
> There is no threading support whatsoever.
>> That's a good thing. It forces you to use async HTTP programming or something like beanstalk, both of which are better than the complexity of threading.
While there isn't multi-threading in PHP, you can in fact multi-process which provides similar functionality.
While there aren't many cases where you should run PHP as a daemon or cron job, there are _some_. Like, for example, you've got dozens of models and helpers written in PHP and you want to use them in queue workers or aggregation jobs.
I've run into these a few times and acquired a bit of mastery of PHP's PCNTL, POSIX and Semaphore/SHM/IPC extensions.
I don't do much PHP work anymore, but I do maintain an OSS library for other people in that situation: PHP Simple Daemon -- https://github.com/shaneharter/PHP-Daemon
Your main "defense" of PHP's flaws consists of saying "other languages suck similarly". Well congratulations, PHP is apparently a "worst-of" of programming idioms. I like me some caviar with my programmes.
Why would you do that? You're going to have to have a branch to deal with the -1 further down in your code anyway. Why not just deal with it when it happens:
if value not in list:
# value not found
return
index = list.index(value)
# Code to deal with the thing
PHP is the MS Word of web programming. It will be here for a long time, just get over yourselves and concentrate on what you write, not how you write it.
Part of the objection raised here is that the php maintainers are not amenable to fixing these problems with the language. Maintaining a private fork of the language with different semantics is both a recipe for disaster and at best a local solution.
Bug reports have been filed and closed for many of these issues.
A full on fork of php might be interesting, though the thought of what's going on behind the scenes in the php interpreter terrifies me.
Almost like posting something about a beowulf cluster of something on Slashdot a few years ago...
That having been said, I agree PHP does what it was designed to do, but has been leveraged into pretending to be a general purpose language (much like what happened with perl)... which it is NOT really good for.
> If this one thing that annoys me on HN it's the pervasive anti-PHP snobbery.
If there's one thing that annoys me on programmer forums in general, it's that pointing out PHP's giant flaws is conflated with snobbery. Design matters, and that is not the same thing as saying it's impossible to build anything good with PHP.
Obviously, since millions of people are using it it is preferable for them. Of course, this is only because they are too stupid to agree with you and have the exactly the same criteria and preferences that you have. It can't be that intelligent people can disagree with you on what is important and what is not in a language. It's clearly either you didn't explain it to them or they're too stupid to understand. Let's write another "PHP sucks" article, that will do it.
It's just that the people who disagree generally aren't really programmars, they're designers turned quasi-web-developers. The community does them a disservice by pointing them at a giant pile of crap and saying "Go use this. You'll be fine."
People who disagree are "programmars" just fine. They just know how to use proper tools for the job given, instead of ranting because they're too lazy to read the manual, like author of the post.
Did the author give you the impression that he was "too lazy to read the manual?" I got almost the exact opposite impression, that he had read the documentation to the point of exhaustion and found it severely lacking.
There are a lot of snobs out there. It is a sad fact, regardless of that article. PHP snobbery is hugely widespread and 99.9% of people disparaging PHP are completely ignorant in PHP and don't bother to spend a minute even on reading the PHP manual - which answers 99% of things they complain about as being hard to understand (and try using Python without reading any manuals at all - see how far you go). I'm not saying PHP is perfect - it is not. I am saying if you take time to write a long article about PHP deficiencies while refusing to take 10 seconds to look up a thing in the docs - it doesn't look good.
PHP has some wrong design decisions, however many of them don't really matter (like function called strpos instead of str_pos - really, that's your problem?). Some do, and people are welcome to propose solutions for them. People also welcome to write rants about "PHP sucks, nobody should use it, anybody who uses it is an idiot" but they shouldn't expect this will be taken seriously.
> if you take time to write a long article about PHP deficiencies while refusing to take 10 seconds to look up a thing in the docs - it doesn't look good.
When did the original article ever suggest that? I got the impression that he had looked it up in the docs, and found the docs seriously broken. That fits my recollection of PHP's docs - there are a lot of them, but they often don't tell you what you need to know, so you have to go trawl through the comments. Of course, most of the code in the comments is crap, full of errors, has security holes or all three.
> function called strpos instead of str_pos - really, that's your problem?
Yes, that's a problem. Ditto for arguments in random order. It means that it's much harder to remember the function without having the docs open in another window.
"PHP sucks, nobody should use it, anybody who uses it is an idiot"? Sounds about right. I know people who are security consultants, who've worked with PHP for years and years - I even know a guy who works at Wordpress. None of them think that you should be using PHP...
You don't like it? Don't use it. You're the kind of asshole that'll walk up to somebody in McDonalds and tell them that the food they're eating isn't healthy. You know what? Mind your own business.
No, this is more like writing a long, well reasoned, extensively researched article with the thesis "McDonalds food is unhealthy". It is a public good.
No one in this comment section is saying to you "stop using php on this project you're doing because it's badly designed". No one is in your business.
The thing is we need to stop advising people to use it in the first place. That's what we're advocating.
That is, we're not telling people to stop after they've gone into McDonalds, we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you. That's a better analogy.
> The thing is we need to stop advising people to use it in the first place. That's what we're advocating.
Who are you to advocate that? Or to advocate anything?
I despise people who presume to know what's in the best interest of others. You only know what's in your best interest. You have no idea what is good for anyone else.
You want to share your experience? Great. Do it when it's asked for. Nobody asked for a hit piece on PHP.
> we're decrying the fact that so-called health experts are telling people that McDonalds is actually just fine for you.
Exactly which maven and luminary of computer science has advocated the use of PHP?
That is outright nonsense. At no point has that happened. PHP grew organically, without a single endorsement.
"I despise people who presume to know what's in the best interest of others. You only know what's in your best interest. You have no idea what is good for anyone else."
Wow. Are you seriously advocating the equivalent of moral relativism in programming? You have no idea if, say, Brainfuck is good for anyone else?
"Exactly which maven and luminary of computer science has advocated the use of PHP?"
I didn't say that they were luminaries per se. Programmers telling non-programmers that PHP is OK for them is what I'm referring to. That would match the analogy--someone who's studying health science telling someone who hasn't studied health science that McDonalds is perfectly healthy.
Programmers need to stop telling non-programmers that it's perfectly OK to use PHP. Frankly, they need to be blunt that programming is hard. That you either have to willing to put in the investment or don't do it at all. This soft runway into developing applications is exactly the reason why so much poor software exists in the common market.
More than half of the top level comments are from people who use PHP. You can tell by how they rush into PHP's defense and try to argue against the article.
The original post just can't be sensibly called "anti-PHP snobbery". It just points out PHP's shortcomings. But when all these PHP-users can't really attack the truth, they attack how it's presented instead (and of course whip up some strawmen and generally just try to skirt around the issues).
The human ego is a sad thing.
(Disagree? How about commenting instead of downvoting with self-righteous indignation?)
PHP devs certainly know its shortcomings like JS guys know that languages too. It's not the fact that he points out the shortcomings, that's fine. What makes it snobbery is how the author points out flaws and is so passionately anti-PHP with the subtext being "what I use is superior". He points out flaws in his preferences but in a way that makes it seem like flaws in Python are acceptable but flaws in PHP are never acceptable.
A lot of people who "point out PHP's shortcomings" are really just on a mission to make themselves and their preferences superior. It's a big pissing contest and these arguments come and go like how JavaScript was once despised and now loved.
It's easier for PHP developers to write it off as "a pissing contest" than to face the cold hard truth: PHP is, objectively, awful. There is literally no reason to choose it over today's alternatives other than market inertia, which is exactly what articles like this one are trying to stop.
I'm a Facebook engineer who works on the HipHop compiler and HipHop virtual machine. It's in PHP, absolutely full stop.
It's amazing how much the fact that g++ is involved somewhere in the toolchain confuses people in this matter. C++ is just an intermediate representation; the source language really is warts-and-all PHP.