<rant>Okay, not directed at you, but... It was posted yesterday. Does this really have to be posted EVERY SINGLE DAY?
Every time anyone suggests improving anything, or make another product in a crowded space, this comic is posted. The author of this article doesn't even suggest a new platform - he suggests improving a platform that exists to enable easier deployment. It was posted yesterday for Chocolat... do we really have to stop making editors?
In a site targetted to hackers and startups it is disturbing that people are so unwilling to learn something new, support a new product, improve the world, do anything new. Yes, redundant standards suck sometimes, but it's not always the case.
I wish that the comic author would consider deleting this from the server, or maybe pg could ban it.</rant>
Nope. In this line he's talking about a web app he's writing and how he considered writing it in PHP to boost adoption. Here's it in context:
"I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible. Despite the serious problems with PHP, I was forced to consider it."
Sorry Jeff. The only thing broken with PHP is you (and other people like you).
How much PHP do you use Jeff? Lets assume none. How is PHP hurting you? I mean seriously, how much contact do you even have with PHP?
PHP is easy to learn, easy to make websites with. There are a tonne of paying jobs which require PHP. PHP runs a lot of websites.
I am a PHP developer. I prefer Python but my PHP job pays me just fine. There are a lot of things about PHP that I don't like but it gets the job done just fine. You can write reasonable code with PHP. You can write secure code with PHP.
The main people who have problems with PHP are either ex-PHP developers who usually have gone on to Ruby and look back and fire a few shots at PHP. Or people like Jeff Atwood. Undeniably smart and talented programmers who for some reason are irked by the mere existence of PHP.
He started with a highly contentious premise that he declared as fact.
Many, like me, disagree with that premise, and so consider that he is at best trying to fix a problem that either doesn't exist or doesn't require a drastic fix like he proposes, or at worst is very cleverly tapping into a vein of contention to hype an up-coming product.
The thing is, with those who do genuinely rant against PHP, at least we can have a useful debate with them over the issues. The "PHP is rubbish" posts that feature here regularly almost always lay out their arguments and basis for coming to that conclusion, from which useful (if sometimes repetitive!) discussion can ensue.
I think that the better alternatives, in the general case, are to participate in (or even fork) PHP and bring about the change together.
So, a couple sentences admonishing the masses to write something better plus one oblique reference to him "trying like hell to make it happen" equals "trying to bring forward a better alternative"?
The "problem" is that PHP's popularity breeds more popularity, uninformed choice, and single-language programmers that only know PHP (a real tragedy!). Bashing PHP is in a serious sense a public service if it can reduce any of these outcomes.
The problem isn't that it's popular - television programs about Bigfoot are popular, too. The problem is that PHP is extremely useful and easy to use in addition to being widely used.
Reading the article, I was struck by its similarity in structure and language to classic Windows bashing rants of the past two decades - i.e. "the problem with PHP is that it has no taste." In fairness, the call to action is radically different; to build rather than to buy something.
Well, I doubt it would ever become popular if it wasn't useful and easy to use.
Actually, I think it is exactly because it's popular. All languages have odd ends, but you rarely hear people rant over Pythons lack of lambdas and weird explicit "self" parameter or Ruby's incomprehensible scoping rules. I'm betting that once they fall out of fashion, we will.
And no, I disagree. The main sentiment of the article is negative. It's a call to figure out how to dethrone PHP, but without telling us why this would be such an important goal.
I hear about them a lot. The difference is that PHP is so much worse. Yes, every language has warts. But PHP is the only popular language I know of which is essentially nothing but warts.
Of course that's subjective, and people disagree, but there really does seem to be a real, qualitative difference between the warts on a mostly nice language like Python, and the ubiquitous bizarro world that makes up just about the entirety of PHP.
> But PHP is the only popular language I know of which is essentially nothing but warts.
This is entirely untrue. PHP isn't even a bad language on the scale of actual bad languages. It has some warts but they don't really impede the development of good software. There are many languages that make developing good software nearly impossible.
I don't know about impeding the development of good software. Warts can always be worked around as long as you know about them and how to handle them. But that doesn't mean they don't matter, and PHP has so many that it's difficult to enumerate them.
What other popular languages silently convert strings to floats and then do math or floating-point comparisons on them? What other popular languages have literally hundreds of failing unit tests in their mainline implementation, allowing ridiculous and insecure regressions that were actually caught by testing but never noticed to ship in an official release?
I doubt there's any one wart that's exclusive to PHP. What's remarkable about PHP is how it manages to gather so many in one place. Each one alone is not that bad, but the sheer number of them is astounding.
> What other popular languages silently convert strings to floats and then do math or floating-point comparisons on them?
JavaScript. Most of the "issues" around comparisons/conversions/etc equally applies to JavaScript as it does to PHP.
But PHP does some very stupid casts but it's really just one problem. In the lists of "failures" tend to show that same problem 15 different ways to show how screwed up things are. If your code is well designed and secure you don't encounter these problems anyway.
> What other popular languages have literally hundreds of failing unit tests in their mainline implementation...
I'll give you that. Since that happened, the PHP developers have worked to ensure it won't happen in the future. No platform is free of particularly big security fails (Rails).
Yes, JavaScript has the same string comparison problems as PHP. And it gets a ton of criticism for it. JS doesn't have all these other problems, though.
For the unit tests, it looks like there are still 100 unexpected failures in the latest release:
Yes, no platform is free of security problems. But the way a security problem happens is as important as what the problem is. That PHP's unit tests are so noisy that important regressions can't even be noticed even when a test exists to catch them speaks extremely poorly of PHP compared to other languages.
I actually clicked on several of those failed tests and there doesn't seem to be anything critical there. Looks like some access problems (test setup) and at least one needed the test to be updated.
I'm not sure when these where run but it would be easy for someone went through all of them and give them a pass. A failed test doesn't necessarily mean that deployment should be held up. 700 failed tests is a different story.
> JS doesn't have all these other problems, though.
JavaScript has plenty of it's own problems. It has legacy things you should never do. PHP has different problems (not necessarily worse ones) and things you should never do. Lists of the horrors of PHP generally include all things you shouldn't ever do mixed together to make it look much worse than it really is.
I've seen similar lists made for JavaScript (you can get some really crazy results) but that doesn't mean shit for day to day use.
The fact that the tests would be easy to fix makes it worse, no better. The problem the tests and the security hole was not that the tests indicated severe problems, but that all these simple failing tests masked the presence of a new, serious failure. If your test output is filled with junk due to failing tests because of minor bugs, it makes it much harder to notice when your tests uncover a major regression.
> The fact that the tests would be easy to fix makes it worse, no better.
Somebody has to fix them; these things don't happen instantly.
Given the fact that they had hundreds of failed test cases and now they only a few is a significant improvement -- and this is while development has continued. They realized the problem just as you describe; there isn't much more to say about it except they're working to fix it.
Yes, because PHP monoglots have their homepage set to codinghorror.com and browse right over to Hackernews afterwards. It is not a public service, it is a waste of screen space.
The startup scene's dirty little secret is that (anecdotal from several local companies I've worked for and/or collaborated with) PHP development is fast and cheap. Once you have proven you can solve a business problem and get funding, then you can decide if you really need to do a re-write.
There are just too many small companies focusing on real problems(instead of what language their webapp is built in) to make me think PHP is evil or that Rasmus Lerdorf is a bad person.
I don't fit in your box. And I still think PHP is a decent language for introducing people to programming.
I've written web apps in: Ruby (both Rails and Sinatra), Javascript (Node.js with Express), PHP (my own framework, CodeIgniter, and eying Laravel), and been maintenance programmer for a C CGI application. I've written desktop and CLI apps in Object Pascal (Lazarus and Delphi), to CLI apps in Go, C++, and probably a few I've forgotten. I've done Object Oriented, Evented, and to some degree Functional programming. I am a polyglot programmer.
The problem is bashing PHP. As Jeff said, PHP's power is its ubiquity and its near omnipresence. It runs on just about any platform with any configuration, with almost perfect consistency. For the most part there's no switching extensions or libraries because of the OS. Develop wherever... deploy wherever... get almost an identical experience without lifting a finger.
In fact, I have great hope for the future of PHP with 5.3 and 5.4 as they (finally!) have added and improved upon the language, and have begun to cull deprecated features. The problem for PHP right now is twofold: web hosts refusing to upgrade in a timely fashion, and legacy codebases that refuse to be rewritten. Both these are demanding backward compatibility, and slowing the advance of PHP.
I'm tired of the bashing of PHP. Bashing, in general, is the absolute least effective way to communicate your point. At least Jeff Atwood is attempting to do something.
It's true that PHP gets the job done, that it's easy to learn and very easy to set up. This makes for a perfect "introduction to the web" language.
Which is why I began developping websites with it. But at some point, I felt like it was preventing me from really understanding what was going on behind the scenes, and I moved away from GRails and now nodejs.
I don't hate PHP but I think Jeff's last point is good: we need framework as easy to learn and setup, but that lets you understand how the web really works.
I'm sorry, you switched from writing your backend in PHP to writing it in Javascript because you believe Javascript let's you more fully understand what's going on behind the scenes?
I'm quite curious as to your understanding of how the web really works.
"I prefer Python". Why did you say that? To me it feels like you said it do people would take you seriously as a "real" developer. Because surely a "real" developer wouldn't actually enjoy using PHP or use it unless they were forced, right?
I agree with your point and I just wanted to add that the fact that we have to add in little details like "I prefer Python" just to be taken seriously says more about hacker elitism than it does about PHP.
"I walk to work because there are no bike paths, but I prefer biking."
Why did you say that? To me it feels like you said it so people would take you seriously as a "real" biker. Because surely a "real" biker wouldn't actually enjoy walking unless they were forced, right?
I get what you are saying, I didn't add this to be taken seriously. I am not bothered if I am taken seriously or not. I had an opinion which I couldn't keep to myself. Upvote / downvote / flag and ban the account. I am not massively bothered.
I do genuinely prefer Python. I picked it up when Django first started making noise and I really enjoyed working with Python (not so much Django). Now I mainly use Python to mess around with PyGame.
Its not a difficult to thing to say. For all of PHP's ease there are little niggles which get you down. Really simple things. Is a function called functionname or function_name. Is it ($needle, $haystack) or ($haystack, $needle).
I don't have to deal with PHP directly but to me it just doesn't feel right when for example you learn about financial websites being built in PHP (as in an HN submission the other day). All these strings being accidentally treated as integers or floats and vice versa, without a decent way of handling errors, it feels like building a skyscraper on a fault line and not worrying about making it earthquake proof. Even if I'll never have to set foot in it, I'll still complain.
As time goes by, I think the time to get started in a new system (which for PHP is almost 0 time) is one of the most important things.
The problem is that the developers of rails / grails / Wt / SproutCore / Flex / Struts / GWT / Django / Flask / Zope / Merb / Zotonic might be sure their framework is the greatest ever, and clearly worth a couple of days (or even a couple of hours) of someone's time to get it all configured and get started. However, I just see this giant list of options, each of which is in it's time the 'best thing ever'. How am I supposed to know which one to choose? Getting people started quickly and easily should be priority 1 if you want more users.
EDIT: Oh, one other strength of PHP. Many people when they start want to turn a static website they already have into a dynamic one. This is how I started on PHP, just including fixed headers and footers in a website. Then slightly customised headers which knew which page I was currently on. Then adding cookies to remember what users had already done. Then finally full user support.
In general, one thing PHP excels at adding the '1% dynamic' to an existing static website. However, I don't think this is as big a market as it once was, I don't think that many people learn a lot of HTML and make big static website anymore, then try to add dynamic elements later (or perhaps, I just associate with different people nowadays)
Another part of what makes something "best" is... size/scope of developer community. PHP quickly gained a foothold, and, for better or worse, continues to be popular in part because it's popular. I don't mean that as an insult at all, but it's a continued factor. If tomorrow everyone stopped releasing open source code for PHP, it would gradually die off in several years while people transitioned to alternatives, and we'd end up with some other 'largest minorty' tech/stack getting a lot of attention.
You're right about the 1%, and it's why classic ASP did as well as it did for a while too, until that was killed off. The fact that big players who once scoffed at PHP now embrace it (MS is a big one) shows how big PHP is and will continue to be for the foreseeable future Will PHP be here in 3-5 years? certainly. 10 years? possibly, but with a difference at least as big as php/fi -> php5 is, so current php5 skills won't really be of much use on their own.
Hey Jeff, let's throw down the gauntlet. You're obviously an experienced developer. I've been in the game for over 11years so should have enough experience to tackle you on this bigoted rant.
You choose a problem that you think PHP can't solve[well]. You solve it using your high level language of choice and I'll solve it using PHP. Let's compare the outcome on reliability, ease of re-factoring, speed, whatever .. then, when it becomes apparent that there is little in the way of difference of the end product let's stop the fucking childishness.
Edit: OK, I'll bite. Um, so you're telling me, I lack self awareness because I said "fucking childishness" .. and that you understand me on some level because of it. You might want to get down of that high horse of yours.
So, you're calling people "childish", yet you're the one tossing out coarse language, then dismissing people with trite memes like "cool story bro"? In a community that prides itself on its etiquette, meme-free nature, and other forms of maturity, no less?
Back up there EvilTerran. Let's take a couple of steps back in this thread. I originally took issue with the OP because his piece was nothing short of a rant. I've spent the last 11+ years of my professional life developing with PHP. So I expect far more than what I read from someone like Jeff .. and was reasonable enough to let him challenge me to prove the errors of my way.
I also took issue because he didn't point out any actual problems or solutions .. rather he just blanketed PHP as a problem in and of itself and his solution was to replace it. This is not the kind of thing I'd expect from someone like Jeff who runs a site that points out in great detail programming flaws not just making hearsay.
Anyway, then you came along taking offence to my use of the f word. I'm sorry you take offence to harsh language but that's not my problem. Your first response to me added NOTHING to the conversation apart from your own very strange opinion of me because of two words I had said. I figured you where a troll so gave you the response I did. Then I thought hang on, let's check this guy out and see what we can glean from his past posts. You have been active for almost 100 days and your posts seem to point to you being a nice enough guy, so I figured you deserved more than my first general reply.
I also note that you just got your CS degree. Well done, and I hope you have a long fruitful career, I really do.
Terms like "bigoted rant" and "fucking childishness" always give me the distinct impression the poster isn't interested in reasonable discussion -- particularly on HN, given the usual monocles-and-earl-grey manner of conversations here. In my experience, that sort of language only irritates whoever may disagree, and so lowers the level of debate, while achieving nothing of value. As such, angry words on the internet always feel immature to me, so the phrase "fucking childish" struck me as amusingly ironic.
Your challenge to Mr Atwood also came across as facetious; I find it very unlikely that a busy man like him has the time for a code-off, but I could see someone claiming his failure to accept a challenge as a victory by default; and even if he did take you up on it, it would prove very little.
As such, your first post read to me as little more than a troll itself, so I felt I was only being flippant in kind.
To be honest, I would have downmodded your first post and left it at that, had that button appeared to me yet. Instead, in hindsight, I guess I thought I was (from my perspective) "feeding the trolls"; itself far from the best way to improve the level of dialog, I freely admit. It wouldn't help that I very likely came to this thread spoiling for a fight with those defending PHP; it's been a conduit for many headaches since I finished my degree & got a job.
It's a shame you are suffering from what I can only assume are poor PHP code bases. This is unfortunately very common with PHP because of it's popularity.
I've dealt with my fair share of poor PHP code bases, and have experienced PHP mature over the years into a very capable language; so know how to wield it to the best of it's abilities. If you ever need any advice feel free to email me.
Congratulations! You just Blub Paradox'd yourself. At this point in your knowledge cycle, you are unable to understand something more complex than what you already know.
Knowledge is power. Defending your own knowledge by refusing to expand and learn something new is cutting yourself off at the knees (or fingers, as it may be).
The subtext of your challenge is that no language could possibly exist that is substantially better than PHP at expressing a solution to any problem, which would mean there's little to be gained by learning anything else. That's not a claim I'd ever make about my favorite languages, even though nobody makes huge lists of indefensible design gaffes in those.
I for one will freely admit that my Haskell still sucks and so I presume I'm not even smart enough yet to start on Agda. Do you recommend it? Do you find it to be (one of) the highest known point on the power continuum?
Oh, I'm still stuck at Haskell, which doesn't suck but could be better. A friend of mine did some playing around with automated proof assistants, and I've been to some talks about seL4, a microkernel prototyped in Haskell, written in C, and proven correct in Isabelle.
From Haskell you can of course go the route to Agda or Isabelle. But Curry is also worth a visit, it combines logical and functional languages.
I, for one, am still learning how to do left-fold based IO in Haskell with enumerators, at the moment.
"make the alternatives so outstanding that the choice of the better hammer becomes obvious."
There's a lot of frameworks that make many types of web site or web app development easier than PHP. There aren't any languages that were created explicitly with the goal of being used to create web pages (and later, by extension, web sites). OK, there might be a few that have gone by the wayside (ihtml, htmlos, etc), but nothing mainstream.
PHP is "content-type: text/html" by default, which can be overridden for other tasks. Everything else needs to make some adaptation (however subtle) to 'play' with HTML. Potentially something like mod_ruby or mod_python could take off, but probably not even then, as you'd be worrying about including base library stuff or extra modules, the majority of which are already baked in to PHP (gd, etc).
You have a web page up and just want to add a dynamic copyright date to the bottom? Copyright <?=date("Y");?> and change extension to .php (or play with some mod_rewrite rules on apache). Want to capture the output of every HTML page and rewrite some links (while logging those changes to a db?)? automatically prepend a php ob_start() call then append an ob_get_clean() function in the footer, then process away.
Doing these sorts of things in any other tech stack requires a lot more configuration and meddling, or possibly rewriting core site code. PHP can scale down to be nice additional decoration in a site, or can power the whole thing soup to nuts (and can scale up much easier than some other platforms can scale down).
Related: I recently had a basic site and needed to rethink it in terms of mobile toolkit. It was much easier to take what I had an add in jquery Mobile stuff than it was to work with Sencha (as one example) because other tools like Sencha assumed I was starting greenfield, which I wasn't, and I didn't have time to learn enough of their stack to try to extract the bits I wanted. jQuery made it easy to add the bits I wanted, and PHP does that for HTML/serverside aspects of things as well.
I'm a php user. I got involved in programming because I wanted to control my websites and build new ones.my first exposure to php was through modifying open source platforms (eg Wordpress and phpbb).
Want to kill PHP? Build alternatives to PHPBB, Wordpress etc that compete on ease of use (incl installing, that means have host gator etc support the language used) and PHP will slowly die out.
agreed. i don't think many other non-php supporters get how ubiquitous PHP (and even has been, for a decade or so) in terms of coming pre-installed everywhere. And apps - yes, have replacement apps that play nicely in shared hosting environments without requiring 30% of the machine's RAM per user/app, and you'll see a replacement.
Oh great. Another PHP article, where we get to watch all of the defenders of Rasmussen's misbegotten spawn come out from under their rocks...
"PHP works great for me! It runs tons of websites! I don't know what you're complaining about..."
To address the article's point somewhat - there are already easy to deploy frameworks and languages for the web, and everybody who cares about development is already using them.
everybody who cares about development is already using them.
Even if we take that statement as given, what about everybody who doesn't care about development? Most modern frameworks take it as given that you are (or at least aspire to be) a fairly serious web developer interested in serious web development and are willing to learn a bunch of fairly abstract concepts up front about structuring and deploying apps. Until a framework comes along that assumes non of those things, php won't be replaced. Imagine your user is a domain expert in an area totally unconnected to computers or programming, but has managed to learn a bit of HTML and now needs to put together a site. What current framework targets this particular use case?
Something that doesn't involve any programming. Because getting all of the bits of web development together is hard work, and you're not likely to end up with anything decent at the end if you don't know what you're doing.
> there are already easy to deploy frameworks and languages for the web, and everybody who cares about development is already using them.
And yet, amongst your rhetoric, you've conveniently managed to name none of them. Is this an appeal to the silent majority?
I'm convinced that there are really good developers out there who just keep building great products in PHP. Good developers write good code largely irrespective of the language. The code is a mere artificial interface between the developer and the machine.
A programming language is a tool to get the machine to do what you want. A good tool will help you get the job done faster, and with fewer problems (like, say, security holes). It's not a "mere artificial interface", and if you think so, feel free to go write a web server in Brainfuck.
It helps to mitigate some common security holes, and sometimes prevents the coder from doing blatantly stupid like using unfiltered user input in queries.
Unfortunately the basic PHP structure is borked, and even within the context of a framework noob coders can do incredibly stupid things.
I would say yes, although to varying degrees depending on the framework. IMO, the safest bet would be to use an 'enterprise' level framework (Zend, Symfony2). But, as jrgnsd mentioned in his reply, even within the context of a framework, an inexperienced developer can still make plenty of mistakes and poor design choices. Learning the framework isn't enough, the developer must also take care to adhere to best practices in software design.
I agree that it's rather surprising that in this day and age, nothing comes close to the out-of-the-box ease and performance that PHP gives for web development. Install a couple of packages, and BANG, you're up and running. It's been a year since I've taken a look at the rest of the webdev landscape, but it seems that you either lose out to an overly-complex setup (by comparison), or suffer with a memory hog that makes bootstrapping on a 1GB VPS a nightmare.
I'm pleasantly surprised at the high rates my PHP consultancy work commands; it's obviously helped by the number of hit-it-till-it-works web devs out there.
Agreed. I can set up a VPS with debian/nginx/mysql/php in about 10 minutes and have a site up and running. Python? Ruby? There just doesn't seem to be an easy way of getting them running on a web server. At least, I haven't figured it out yet if it is easy to do.
`git push heroku` style deployment is pretty easy. And for anything where having a site up and running in 10 minutes is the primary driver, Heroku is probably good enough.
Granted, for larger projects where you run your own ruby/python services, it could surely be easier. But for larger projects you probably want to spend more time on your deployment setup anyway.
PHP is broken in many little aspects but if you use a high quality framework, it's quite enjoyable to work with. The main gripes I have with it are in the details, like:
You can't do:
$something->doStuff()[0]
if(empty($something->doStuff()))
Overload fucking functions. Fuck.
What sucks:
The namespace separator.
The naming conventions of the core functions.
The speed.
But, overall it works and elegant solutions can be written.
Also, being competent in a market full of incompetents makes you valuable and getting a well paying job is easy. What's not to like about that?
"You can't do: $something->doStuff()[0]"
Yes you can.
-------------
AFAIK, yes, in PHP 5.4 only so far, which is only about 4 months old. The first 15+ years of PHP's life, no, that wasn't possible. I'm glad it's there now, but frustrated it took so long.
I just read about the new closures. Too bad, scoping is still somewhat broken: You have to explicitly declare the variables you want to use from the outer scope.
Speed isn't an issue, at least in my experience, compared to similar languages. Raw PHP usually beats Rails handsdown, and most PHP frameworks are usually comparable. PHP performance has increased markedly over the past few years, and particularly in v5.4. And if you really need a speed bump you can use the APC cache or HipHop compiler. Its never going to be as snappy as, say, C, but in the class of languages its in these days it holds it head up high.
I like the namespace separator, but I'll accept I’m in the minority on that one.
The reason I cited Rails is that its usually proposed as the better alternative in these anti-PHP threads. Most "high" performance PHP doesn't use one of the usual-suspects in the framework world and can easily beat Rails (and usually plain ruby too).
Edit: I should add "in my experience" to the end of that, I have no stats to hand.
>Most "high" performance PHP doesn't use one of the usual-suspects in the framework world and can easily beat Rails (and usually plain ruby too).
If you skip a framework on both languages, they end up as the two slowest languages. Hard to say if either is faster overall, but they are both awful. Using jruby provides a huge performance increase, and PHP really has nothing to compare with that.
To be honest I've not used jruby. It would be interesting to see how it compares to implementations PHP on the JVM such as IBM's WebSphere sMash, and Caucho's Quercus. Do you have any views on the performance of jruby vs hiphop'd PHP?
Hiphop doesn't really compete in the same space, as it only converts a subset of PHP into C++, and has very limited support for various PHP modules. I don't think any of the common PHP apps like wordpress, joomla, etc work under hiphop. Stuff like Quercus is the jruby of PHP, being an actual implementation of PHP rather than a source -> source translator. But I haven't seen any benchmarks showing it actually beating regular PHP. It does have a much better security record than the official PHP though, and is probably a worthwhile project on that grounds alone.
I really hated the namespace separator and I ranted against it pretty heavily before PHP 5.3 was released. But I've been using PHP 5.3 pretty heavily for a new project and now I don't mind the backslash at all.
I also understand the technical need for a new character (which doesn't exist for static languages or some other dynamic languages) and once you need a new character then the backslash is a reasonable choice.
I've had to implement a feature in C (it was a batch process analysing some data and spitting out ~250k rows) because it was incredibly slow in PHP. As others have said, Ruby sucks for speed too.
Cue legions of PHP drones blubbing about how it does the job just fine, it's available everywhere and how it's used by Facebook and half the internet. We get it. We used to be PHP developers too. We took the time to learn other languages and now work with them. We enjoy our jobs significantly more than we used to. You might too.
I'm a full time PHP dev. My work is in PHP, my personal projects is in PHP, I even have a PHP framework (like everyone!) that I maintain.
Yet I thought this post was right on target. I'm busy cleaning and finishing up my PHP projects, and then I won't start another project in PHP. It will be ruby or python, or maybe I'll go functional. It depends on what I want to do. Yes, I can say everything that you so sarcastically proposed, but I also see the value in getting new coders to not start off with PHP.
Good for you! In my case I moved to ruby but I would imagine the transition is similar to other languages at a similar level of abstraction. I went through a long phase where I was trying to bring patterns from ruby into PHP.
It got to the point where whenever I sat down to write PHP, I would write it in ruby first as a sort of pseudo-code, then expand the brackets out into PHP after the fact.
Eventually I decided that I would be more efficient just skipping the expanding out step.
That's nice, if you get lucky and/or you are young and able and willing to move anywhere you want. I have a CS degree, am reasonably proficient in Python, want to be better with Java, but ever since an internship in college have worked, at least professionally, exclusively with PHP.
You (General you) get companies to hire experienced PHP Devs , even as entry level for other languages and I'll be there in seconds. However, all the jobs I see require 3+ years with that language.
For me personally, I'm not able to move around much but I do live in London where there is a pretty active tech scene. Here's how I did it:
* Let x be the technology you want to work with professionally.
* Spend roughly a year of occasional unfocused off-time building little side projects with x. You can do it faster if you have more drive than me.
* Put those side projects on your github profile or anywhere people can see them.
* Apply to companies that work with x, whether or not they say they are hiring, or take experienced hires from other technologies. Send your github profile along with the application. Preferably go via a connection, but this is not required.
* In the interview/application process, demonstrate strong, language-agnostic technical skills along with some fundamental knowledge/realisations specific to technology x.
I use PHP because I love it. I wouldn't consider myself a "drone", I'd like to think I form views on the basis of my own investigation and relatively impartial evidence.
And it's not that I haven't spent the time learning other languages and working with them. I did a degree in Computer Science and have worked for 12 years in the industry, over which time I have learned and worked with Pascal, C++, Ruby, Lisp, Javascript and dealt with a number of other languages. I discovered PHP early on, but only relatively recently have I really taken a shine to it, particularly with the releases over the past few years, and now I won't work with anything else.
I enjoy my job significantly more than I used to because of PHP.
In the main I don't find it a horrible language, I'm aware of its weaknesses and its "problems" (usually not problems per-se, but things it does differently from other comparable languages). But in the main it fits the way I think and work, and I'm incredibly productive (and I like to think that I don't write code that's too shabby either!).
The problem is that the barrier to entry with coding PHP for the web is to open up notepad for 30 seconds and then upload a file. It's hardly more complicated than writing a static HTML page.
The barrier to entry with any other popular language such as Python or ROR is that's it's hard to just toss a script up and see results.
Possibly, but its possible that if another language had been chosen, it may still be languishing as some half-finished forgotten project somewhere and those engineers would never have gotten their jobs!
It surprised me, considering the original developers of facebook (Zuckerberg, Moskovitz) were doing Computer Science degrees why they chose PHP to build it in initially. Did they consider other languages, or frameworks.
I'd be surprised if they chose PHP because of future hireability / scaling up. I'd guess they didn't give it much thought and PHP was just there.
This rant boils down to a tweet "If you don't like PHP then use another language or build a better one". What a revolutionary concept! That has worked wonders for languages since. Except not one has come out that is as simple as PHP thus PHP will continue to exist. Everyone that invents a language now focuses on abstract concepts that do not help the everyday developer do anything useful. Is it so shocking it's still around? If these rants are supposed to be rally cries they are really just awful attempts. Who wants to follow a whiner?
> If you don't like PHP then use another language or build a better one ... Everyone that invents a language ...
But he said nothing about "inventing" a language. In fact said very clearly that he wanted to take an existing language and add to it - particularly the things that PHP does do well.
from TFA:
> "to buff up a open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment"
If an existing language already has potential to replace PHP then I don't see why it wouldn't have already. What would/could you tweak that would get you there without fundamentally changing the language capabilities and syntax?
Mr Atwood will have to answer that himself; he's the one who thinks he can do it. However the last line of my reply above is, I think, the best answer that your question will get until he shows us more.
I suspect that he is being deliberately vague here; in other words there is an announcement coming at some later date and this is preliminary PR. That doesn't make it untrue though.
Setup costs - PHP has a low barrier to entry in the sense that Apache's mod_php5 is a simple "a2enmod php5" command away. Even PHP-FPM with Nginx is only a few well-documented configuration options away from working.
Currently, no other language can match that. They either require a VM running (Java, Ruby, etc.) or at least have a compile/build step (Python).
UWSGI has a lot of promise, but until it's as easy to get configured as PHP-FPM, PHP is still way easier than everything else.
> Except now it's 2012, and fellow programmers are still writing long screeds bemoaning the awfulness of PHP!
Yes, and not only did Jeff write one in 2008, but he wrote another one just now. You can't write 10 paragraphs about what a blight PHP is and then pretend like you're being constructive by admonishing us to create better tools.
In fact what everyone is doing with these rants is bike-shedding about an easy-to-hate language. It makes an easy topic that drives a lot of traffic because everyone has an opinion. It's just tabloid garbage for the hacker set.
A more objective view of things is that PHP is a capable-if-ugly language, and it co-exists just fine with thousands of other programming languages and frameworks all with their own visions, communities, and production applications. The existence of PHP is not harming other "better" languages at all. And if you really want to make an argument about languages hurting the state of programming, how about asserting that the dominance of imperative languages is irreparably damaging the ability of most programmers to work in functional languages where solutions are fundamentally more robust. Or what about the damage that proprietary platforms like .NET (which Jeff uses if I'm not mistaken) or iOS do to the programming world by restricting progress to a single company.
I won't belittle Jeff's contributions to the software world, because Stack Overflow is an amazing service, but despite the fact that I hate PHP, Rasmus' contribution to the software world is certainly much more important than Jeff's feel-good blog fluff.
"Or what about the damage that proprietary platforms like .NET (which Jeff uses if I'm not mistaken) or iOS do to the programming world by restricting progress to a single company."
PHP is used for web development. Microsoft's best alternative for web development is ASP.NET MVC which is open source.
Yeah, it's a fine line between just bashing a tool and bashing its users as well. I feel the submission came down on the bashing-the-tool-only side, but that's a judgement call.
I've been coding for nearly 30 years and have seen this rant for every major language I've coded in. The reality is there is no perfect tool even in construction as Jeff tries to draw parallels to you will find that many different tools are required for many different situations. Often a hammer can be used to make a hole in a wall and other times you use a saw to cut a nail head off and just pound it into the wall because your hammer has a broken claw!
Tools evolve over time and saying screw drivers are useless and everyone should use a battery powered screw driver doesn't change the fact that a screw driver drives screws.
If you don't like the tool move on to other tools or make your own and get people to adopt them. Don't bash the brilliant people who worked hard to make the tool in the first place.
My father is 71 years old and codes in PHP! He was never going to learn python, ruby or anything else but PHP was approachable for him. Provide a language with that low barrier to entry and let's talk. Meanwhile I love my dad but we won't be writing the next google and that's ok by him and I both. If he wants that he'll ask me to write it in COBOL! :-)
Why is python or ruby too hard for your dad to learn? If anything I would think something like ruby would be even easier than php since things are a bit more consistent.
I just don't see how PHP is more approachable, especially compared to the supposed ease of ruby on rails.
Err, I love Rails and all, but don't confuse ease of use with ease of learning. The thing about putting convention over configuration is that you have to learn a lot of conventions.
Try getting Django to run on various hosting sites. Dreamhost - been with them for ten years, gave up trying to get Django to work after a month of poring thru the docs, trying to get tab A into slot 3x. Mind you, I really like Python, but it's not worth the effort for a couple more years.
PHP is the A-10 of languages. It's a slow, ugly and easy target. It works pretty much everywhere.
For pretty much every language these days, there is a hosted service that will handle deployment for you, and you can just push code to them and they'll take care of the rest. Better yet, they're perfect for beginners, who usually don't know much about database tuning, firewalls, etc.
Yeah, but the average person doesn't really understand how their PHP is set up either. It was done for them, or they copy and pasted some instructions.
Perhaps it's best if you either completely take deployment into your own hands, or you let someone else do it for you. Given all that, rolling your own could still be made simpler.
> build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.
A bite later:
> We've got a long way to go. [...] The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.
Basically, Jeff just agreed that PHP is simply better than the rest. The problem is that he cannot accept that thanks to PHP anybody can code something pretty fast. I am always amazed when I see my brother, without programming knowledge improving his wife website like gardening. Small changes here and there. End at the end the website is making money. He never complained about the "awfulness of PHP".
The problem is if you have a garage full of power tools and know how to use them that it's unreasonable to let your 6 year old build a birdhouse with them unsupervised.
I'm looking into ASP.NET MVC for a project and if you walk through the "hello world" tutorials with that package they are 10 pages long and filled with lots of magic. As a developer, I understand the significance of that magic and it's long term purpose. But it's probably far from the best tool for the job if your project is simple.
The flaw here is perhaps the assumption that the best tool for the job is the same for everyone and the same for every task.
Debatable. What's your end goal? If your primary goal is making money (through the web) and you are non-technical, easier does in fact equal better. The GP's brother isn't going to stop what he's doing and learn Ruby so he can rewrite his whole website in gloriously succinct and elegant code.
He's going to tweak his site, continue making money and stop caring about whatever the hell his site is written in.
Again, from the brother's perspective, perhaps learning Ruby is the tempting shortcut ("I'll just learn this awesome language first and my website will be super easy to upgrade and modify")
...
and then it takes him too long to get back to his website, which has floundered and is no longer popular or making money. Or ruby was too hard for him so he went back to tweaking his site with PHP. Or <whatever>
My point is that it is all about perspective, something that a lot of HN misses. Not everyone cares about technology. Most people just care about getting the job done and making money, using whatever tool is easiest for them to personally use, at the time they need to use it. So to that guy, it isn't a tempting shortcut: it's the best route to prosperity.
Simple versus easy [1]. Getting started with minimal friction is a great virtue for the beginning of a project's life, particularly when it allows amateurs to produce something of value. Software development professionals with stronger requirements (reliability, maintainability, ease of code reading) are not always going to reach for the easiest tool. There's a reason most of the software on your machine isn't written in Visual Basic.
The people who prefer PHP are right. The people who avoid PHP are also right. They are solving fundamentally different problems.
I get your point, and it's important to get s¤% done. But you have to at least consider that what's easy right now might not be the easiest in the long run.
Maybe a little OT, but I can't shake the feeling that he's going to introduce some nasty security bugs if he's hacking on php code without knowing what he's doing. Might not matter, but then again someone could find it and completely ruin his small business.
(of course you can write "secure" code in php, but you need some knowledge to do so..)
I was expecting an elitist diatribe about PHP (because this is perennially popular amongst particular programmers) but that's not what this post is intended to be.
Interestingly Jeff does take the usual potshots at PHP almost like he thinks he'll lose street cred if he doesn't but the basic message I agree with: if you want someone to stop doing something you consider undesirable give them better alternatives.
That being said, I simply disagree with the premise. PHP has a lot going for it:
1. The CGI type model of creating everything, servicing an HTTP request and tearing everything down is a powerful one (and used in Python, Ruby and elsewhere). Once you go stateful (eg Java servlets) you have to worry about resource leakage;
2. PHP has a stateless core of API functions. IMHO this is basically ideal for Web programming given (1). It makes startup/teardown cheap and reduces resource usage (making it cheaper to provide for hosting);
3. Imperative programming is IMHO a natural fit for Web programming. One thing that's wrong with PHP is all the bloated OO mega-frameworks people create on top of it to try and make it Java, Rails, whatever; and
4. Inline code in HTML is a powerful technique. The learning curve for PHP is quite gentle.
So if you want to make a better PHP (something I'd encourage anyone to do rather than simply jumping on the PHP hating bandwagon) you should tick all the above boxes. Of course if you do this, you will probably want to fix some of the following:
- argument order consistency
- API function naming consistency
- default to HTML escaping on output
- effectively default to SQL parameter binding
- no register globals
- and so on
Side note: all of the above is well known. Pointing it out in yet another PHP hating blog post is both pointless and boring.
Jeff also asserts that PHP's popularity is sheep mentality. What nonsense. (1)-(4) above explain it far more than that, particularly the cheap hosting and inline coding.
I like to point out that 4 of the top 20 sites are built using PHP (Facebook, Yahoo, Flickr, Wikipedia) so--like it or not--it must be doing something right.
Homer (Simpson) once said "sometimes the only way you can feel good about yourself is by making other people look bad and I'm sick of making people feel good about themselves". I see a lot of that with (us) geeks but it's just so unproductive and pointless. You don't need to hate on "not X" to justify your choice of "X" (X = Python, Ruby, Lisp, Clojure, Scala, GPU type, phone type, tablet type, camera type, you get the idea).
EDIT: as far as Facebook goes, they didn't "give up" and use HipHop, they decided to have their cake and eat it too. They get the productivity benefits of programming Web pages in a "fit for purpose" language while getting most of the performance benefits of native code and they only had to give up some small subset of PHP to do it.
If you argue the subset thing is a problem try working in any C++ shop where using only a small subset of the language is de rigeur.
It's not a feature of PHP, it's a feature of the world. Had hosting providers put the same effort to make deployment of Python, Ruby or Haskell web apps, this argument would be void.
Similarly, LPG is a great car fuel here where I live, because of a good price and abundance of gas station, but it's not the case in the US.
??? Is that a joke? Don't do that! That's just as bad as magic quotes.
> no register globals
It hasn't existed for a quite a while now in PHP.
Other than that I quite agree with what you wrote.
Most of the criticism of PHP is simply a desire to be special. If lots of people are using something, you want to make sure not to, so that you feel special. Now that you've decided not to use it, you need to justify it to yourself. And people find all sorts of real criticisms in the process - yet none of them matter!
> ??? Is that a joke? Don't do that! That's just as bad as magic quotes.
No, it's not. Magic quotes are a pain to reverse. HTML escaping can be built into the echo/print/<?= .. ?> commands, so that it is:
- A setting that can be totally turned off at run-time, if you want;
- Easily overridden on a case-by-case basis with a 'rawecho' function that
does *not* escape anything.
Problem with HTML escaping by default - it's not all HTML escaping. Javascript strings need to be JS escaped, sometimes escaped by HTML as a second (or even first) step to complete the correct encoding needed to avoid XSS for the specific context(s) that output actually ends up in for a browser. Same for CSS, URIs, vbscript, parameters, etc.
HTML escaping is not the one and only escaping strategy that magically makes everything safe. So any automated system would need to incorporate overrides on a per variable basis.
> > default to HTML escaping on output
> ??? Is that a joke? Don't do that! That's just as bad as magic quotes.
Microsoft's Razor and Python's Django templates have both shown that HTML-escaping-by-default can be cleanly done in a way that is not magical and that is highly reliable. I'm not honestly sure what you're protesting here.
In a way, "default escaping" isn't even the way to think of it. There is everywhere functions to emit raw characters and to emit them HTML-encoded. "Default" escaping just means that the function that emits HTML-encoded characters is easy to get at and smoother to use than the raw one.
I understand the debates Django had about changing what the unspecified output function did, but nowadays if you're building a new template language of any kind it's an absolute no-brainer: Make it easier to encode than to bypass encoding. The alternative is just awful.
If I make a string: '<P>' . $var . '</P>' - does it know to encode the variable, and not the entire string?
What if I assign that string in a variable, and then output it later?
I'm not convinced this can be done well. Maybe if all you do is make some templates and fill them in you could do it. But I do a lot more than that, I output dynamically built html all the time.
Just give people a very easy and shortly named function for escaping.
Just needs a bit of type system magic. Don't use the same type for escaped and unespaced strings. (And don't use the same type for user generated input before and after it's scrubbed / escaped of any nastiness.)
Ask any Haskell weeny for details.
Also in your example, you'd probably be better of, if your language knew about the HTML structure, e.g. something like P($var), instead of putting the tags in as strings.
> Don't use the same type for escaped and unespaced strings.
And if you can't extend your type system to make this work, do it in your head, mutating the names of variables to help you keep it straight. For example, esStr and unStr are not of the same type, and moving data from one to the other without conversion is always an error.
This reminds me of Charles Simonyi's classic article on Hungarian Notation. I know that style gets criticized a lot, but that's usually when it has been used inappropriately. If you have a language with a weak type system then a sensible variable prefix convention can help a lot.
Even with static typing, you might end up implementing using run-time support. (Of course the holy grail is to compile away all type information. But that's not only attainable. Even Haskell's ghc compiler keeps some information around for runtime. Something to do with typeclasses, if you want to look up the details.)
I like this, although when you concatenate strings, does it actually concatenate them (and loose the type info)? Does it escape them, and then concatenate? Or does concatenation actually make a closure, which is only executed upon output? (And does doing that make things memory heavy.)
Haskell is on my next language to learn list.
> something like P($var)
Ugh. I hate that. I've spent years learning HTML, I want to write HTML, not some other language that looks like it.
$foo = <p>$textvar</p>;
$foo->append(<span class='will-end-up-before-close-of-p'>Hello!</span>); // etc.
Mozilla proposed to add XML literals to JavaScript at one point, which didn't take off for security reasons, but server-side it's a different ballgame... maybe it could be worked out? Hmm.
Wow, that's even uglier. But you did not only propose an alternative syntax for HTML, but also for its manipulation. So that's a good enough excuse.
Have you looked at how Racket (Scheme, Lisp) deals with encoding HTML in S-expressions? I find that rather nice, and even prefer it to plain HTML or XML. Racket is a fine language for manipulating S-expressions, too.
Yes, judging by your questions Haskell is a good language to learn for you. To give you a sneak preview: You can use the type system in such a way, that your source program will safely discriminate between the two types of strings (e.g. tainted and untainted), but there won't be anything left in the compiled assembly (tags or wrapping or whatever).
Also about the HTML: You can of course use different syntax for what I proposed, one that's closer to actual HTML. But I think as long as the syntax tree is preserved, it's still close enough to HTML for me, and all your accumulated knowledge about HTML is still applicable. (Not to be derisive, but if your years of learning are no longer of any use upon such a cosmetic change, you should probably examine your level of comprehension.)
The hopefully obvious answer to your question is to not generate markup in PHP (or any server-side language). These are the kinds of questions that Backbone, Spine, Ember, etc attempts to solve. You should look toward separating view concerns from your business logic and stop procedurally generating html in PHP.
I'd say don't do that, refactor into templates instead. With your preferred approach to generating markup, you're largely on your own in protecting against XSS. Hopefully all the developers using your code are awesome at spotting and pro-actively dealing with XSS issues.
Still, with a HTML escape everything default, either turn it off, or use a raw "I know what I'm doing" method instead.
In Razor at least you'd create HtmlHelpers to output html, which returns a string that the system knows is html and you've already dealt with. It knows not to escape the string as you've explicitly said the string you're creating is markup.
You'd do something like @html.SalesWidget("90% off today") with the SalesWidget being responsible for escaping the string.
Also I don't really get your argument, why not give people a really short and easy way of not escaping a string instead? The opposite of what you're suggesting is just as easy and far safer. You're less liable to accidentally muck up.
Perhaps what we need is a language/platform that has built in strings that track not just the code page type encoding, but some kind of "intent assertion" as well -- is the string intended to be encoded for a particular output? Combining an "unknown" string with an HTML (or SQL, or PostScript, or JSON/JavaScript, ...) string would produce an exception.
Such a mechanism would have to include encoding functions (and assertion override functions), of course.
It seems this would help alleviate many types of fill-in-the-blank injection problems as well.
This problem has already been solved in the Haskell ecosystem [1]. For example, you get typesafe URLs so that if you have a standard query like myapp.com/person/345 you can't mistakenly misuse 345 as an article id. Every input string is tracked by the type system so the possibility for escape issues, injection attacks or cross site scripting exploits to sneak in is minimal. Static types also make sure that internal links can not be broken - if for example you decide to change the above URL to myapp.com/getperson instead, your application won't compile until you've fixed every other part that still references the old link .../person, and so on.
Not to mention the (also type safe) dead easy to use persistence framework.
I'm still in the process of evaluating different solutions for my next web project but so far I'm pretty sure this is gonna be my go-to framework in the future.
"And people find all sorts of real criticisms in the process - yet none of them matter!"
I'd like to mention something similar that I found in human behavior with respect to manufacturing jobs that we used to do for customers at a company that I was at. What we found was that people had 1 or 3 major complaints about something that were pretty valid. But what they did then was feel that they needed to build a strong case so they ended up coming up with as many nits as they could to build their case as if that somehow made the true concerns stronger. Just my experience but I have found that if you have a true concern about something to simply focus on trying to get that fixed. If you throw everything in the other party sometimes feels that they will never be able to please you and then they don't even try to fix anything. YEMV.
Please don't use Facebook as an example, the fact they gave in and built HipHop to get it into C++ spoils it. Are they coding in PHP? Sure! Are they actually using it like it's meant to be used? Not quite!
Hey. I work on Facebook's PHP toolchain, HipHop, which these days includes a debugger, interpreter, JIT compiler, and the ahead-of-time compiler. The fact that the AoT compiler uses C++ as a target doesn't change the input language, which really is PHP. E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;. We have to get all the nooks and crannies right because we use significant open source packages in PHP.
The developer's usual routine is the same as someone using Zend; they write honest-to-goodness PHP and reload the page. There is no compilation involved; you instead are using the JIT (or until recently, an interpreter) that monitors the filesystem for changes and silently integrates them.
Facebook devs use PHP exactly as everybody else does; they just do so with a different toolchain.
I have to ask, because it's really been getting at me for a while honestly. How do your developers react to that? I mean, you guys are known for going after the best and the brightest. People who have worked hard to perfect their craft. These people tend to have strong opinions when it comes to language design. How do you get them from that point to "ok, now write some php code" ?
That's easy: the best recognize languages are just a means to an end. Language snobbery, in my experience, tends to be highly correlated with being a "wannabe" rather than "great" and a useful filter.
You will find any number of C/C++ programmers who think you can't write anything in Java. Many Java programmers think you can't write anything (beyond 100 lines) in Python. Many Python programmers think you can't (or simply shouldn't) write anything in PHP. And so on.
Some people are insecure.
Some people can't separate their language from themselves (and see a criticism of their language as a criticism of them as people).
Some people exemplify the Dunning-Kruger effect [1].
Some, like teenagers, are just asserting their identities.
That's a well-reasoned but rather lazy response imo.
Ppl who have strong opinions when it comes to language design have strong opinions when it comes to language design. Ppl who think languages are just a means to an end think languages are just a means to an end. These are two differenty species and indicative of their particular worldview, attitude and preferences. To use that as any kind of filter is silly.
Lets not look at CS for a second...If you want to know what a Stieltjes integral is, a probabilist will tell you one thing, a functional analyst another, and a measure theorist will give you yet another more pedantic definition. There's no right or wrong definition here...every one is coming at it with the tools they are more well versed in. The probabilist is the end-user, so to speak. He can't do his day to day work without internalizing it, because his bread and butter, the PDFs and CDFs of all the distributions he deals with, comes from Stieltjes. The functional analyst is going to use Stieltjes when he deals with Banach spaces, but otherwise he has other preoccupations. The measure theorist studies Stieltjes in depth because it goes to the very foundantion of measure theory...but he isn't really an end-user.
Now back to CS...a C++ programmer will think of Java as an interesting toy because you don't get union types and pointers & so forth. The Java guy will think of Python as an interesting toy, and the Python guy thinks PHP is an interesting toy. None of this means any of these people are insecure or being a teenager. If the only goal in life is "languages as means to an end" where end = $$$ in the short term, then yeah, lets just cut to the chase and do PHP. But there are other goals, yeah ?
I don't use PHP much, but I was curious, so here's the answer you don't want:
You get $a[1] = 0 the first way, and $a[0] = 0 the second way. PHP seems to evaluate the array index before the right hand side if there is something more than a $variable to evaluate; otherwise PHP evaluates the array index after the right hand side, after $i has been incremented.
I haven't used hiphop, but I'm curious if it preserves that disparity between arrays when translating to C++, or if it breaks PHP compatibility by making those two arrays equivalent.
The entire point of my post was that we preserve the semantics of this (and many other) PHP-isms. We have to, because you never can tell which glitches useful code has come to depend on.
I'm not the best and the brightest, but I'm sure the people they are going after are more excited and concerned with the quality and quantity of problems that facebook is in the unique position to solve. They could probably care less what they use to solve said problems.
The best and the brightest appreciate the technical, product, and engineering challenges of Facebook and certainly don't waste their time whining about a language or feeling entitled.
The aspects of PHP that are bad (and there are more than a few) are easily tooled around. We have a review-time tool that parses your PHP, symbolically executes it, and looks for dubious idioms, flagging them for you and your reviewer.
Meanwhile, PHP gets a number of things very right. For instance:
* State: there is none across requests. Oh sure, there's APC, and the filesystem, and databases, etc., but those are all accessed via libraries. There is no PHP-level state that survives a request, which provides natural fault isolation: a request which goes wrong doesn't take the server down with it, or live on to corrupt other requests.
* Concurrency: PHP's concurrency model is the web request. If you want to run some code in parallel, curl to localhost. If you wrap an appropriate library around this, it looks just like Erlang's actors. This is shared-nothing concurrency, which turns out to be a compelling local maximum.
* Interactivity: The development workflow PHP provides is very productive. You save and load the page. You don't save, optionally recompile, restart the server, wait for it to initialize, forget what's different from the last three times you tried this because this has all taken three minutes and you forgot to write it down, etc.
These three things turn out to be among the most important parts of a server-side language, and PHP gets them very, very right. The rightness was accidental, not by design, but this doesn't make it any less right.
Also, the language itself can be improved. In the HipHop toolchain, -v Eval.EnableHipHopSyntax=true turns on a bunch of (backwards-compatible) features we've added to our PHP dialect, the most notable of which are XHP (syntax for using XML literals as PHP expressions) and generators (inspired by Python's, using similar 'yield' syntax). I put up some sample code for a talk just the other day, if you're curious: https://github.com/kmafb/hiphop-samples
>These three things turn out to be among the most important parts of a server-side language
So the language does two of these three things by not doing them at all ?
State: oh there's no state across requests.
Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.
> PHP gets them very, very right. The rightness was accidental.
Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".
Nobody's asking you to like PHP. I'm explaining why it's effective; if you'd like to build something better, there are affirmative lessons to learn from PHP's undeniable successes. While your point about Erlang is correct for pure PHP, one of the nice things about the "curl as concurrency model" world is that the thing on the other end of the curl doesn't have to be PHP, or stateless.
Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.
Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.
The point is that it's still shared state, so it's possible in practice to take down your server if you manage to corrupt your database or a file on your filesystem.
About the only thing you're protected against is memory leaks, and that seems to be because you have to, otherwise PHP would fall over in a big heap: https://www.google.com/search?q=php+memory+leak
I haven't had any problems with memory leaks running things like Django or Bottle.
I should have expected someone with more knowledge of the system on HackerNews :)
What I mean is that whilst you guys at Facebook are using PHP you're not using it in the sense of 'we write code anywhere and deploy it anywhere'. There's an additional build step in between the developers and the final product, rather than just straight up serving PHP as is which is one of the biggest PHP recommendations. Although HipHop is open source so I guess you could still say it's within reach of all developers.
> ... 'we write code anywhere and deploy it anywhere'. There's an additional build step in between the developers and the final product, rather than just straight up serving PHP as is which is one of the biggest PHP recommendations.
According to him there's no explicit build step the devs have to perform and they're just writing PHP and using open source packages--meaning they are in fact making use of the "write once run anywhere" ideal at least in some places since the open source packages were made to run on Zend and now they don't. The "write once run anywhere" ideal is kind of a myth anyway since there's always configurations to do, and language-wise was even more of a myth when PHP 5.3 was new. (Some hosts still don't support it, and I'm sure a lot of us remember hosting services who dragged their feet just getting off PHP 4.)
It seems like you think the Zend backend is the One True PHP runtime and anything else isn't PHP. This is like saying PyPy isn't Python. It's just a bad argument.
Now, as far as I understand it the Zend backend takes the PHP code, creates opcodes and executes it in a VM, whereas HipHop takes the code, compiles it down to C++, compiles it again with G++ then runs the resulting C++ binary instead. To me at that stage HipHop is no longer a backend, but an entire build system transforming the language away from PHP.
Like I said, I'm not as intimately familiar with the system, but I thought it was along the lines of they have a dynamic system for local development, and when they serve it up it's run through the HipHop compile process.
I'm still curious why the target is C++ and not LLVM or a direct ISA. AoT seems very useful, using PHP as a language and not a runtime at least in deployment.
> One thing that's wrong with PHP is all the bloated OO mega-frameworks people create on top of it to try and make it Java, Rails, whatever...
The thing that really fries my brain is templating systems built over frameworks -- PHP is already a templating system, and building another one in PHP is just silliness of the highest order. I mean, sure, separate out the gnarlies and include or require them as necessary (but, please, don't nest includes so deeply that you can't find anything anymore), but don't throw away what the environment provides just so that you can reinvent that particular wheel.
PHP is a terrible template engine; replacing it with something better is just obvious. I like to think of PHP's output mode as REPL for the web but not as a way of constructing templates in real-world applications.
> 3. Imperative programming is IMHO a natural fit for Web programming.
I disagree with this, especially in a RESTful world. It is very convenient, and obvious, way to look at a web request as a referentially transparent function for the most part. And the non referentially transparent requests really do change the world. We are moving our backend to a bunch fairly clear workflow of, that has layers that look like:
Get DB stuff -> referentially transparent -> Write DB stuff
And these can be arbitrarily nested. It works pretty well, it's easy to reason about, and it's pretty easy to write.
You do have a point, this seems to be a fairly common way to vent yet still appear 'objective'. I do it myself sometimes, and occasionally pick myself up on it... mainly when I get away with it. :)
I sense this is probably done quite a lot in journalism, so you can write 'interesting' articles without coming off like a completely biased douche.
I am damn tired of his takes on PHP. It's damn pissing off to see the kind of points he puts in his posts.
I don't even get the part where he says that we need to come up with better solutions. So, if we want better solutions when are they going to arrive. It's not like that the solutions are getting baked in some oven or something.
We have new solutions that we can use. We may even call them better, but I don't think that I will quit a language just for the fun of using something new.
PHP might be st, it might even break at times, but there are some wonderful frameworks which have come up lately. Laravel is one of them and a number of developers are contributing to the code.
One cannot just ignore the fact that so many people have gone mad and not even a single one of them actually felt the need to quit PHP forever and build a new language that is better than it.
There's a simple adage that a good tool makes simple things easy and difficult things possible. By that measure, PHP is a pretty good tool. Yes, other tools are better in various ways, but ease of deployment is a non-trivial quality.
(I did like the quote suggesting AppleScript is "even worse" than PHP. I'd say it's far worse, since AppleScript makes easy things difficult.)
The funny thing about #4 is that php has been making a lot of progress on that exact front. Register globals has not only been deprecated but removed. Mysqli is now the default means of talking to dbs. Meanwhile, you see very fundamentally similar issues in, say, rails not getting the attention they deserve because everyone assumes rails is well engineered.
I don't mean to defend php overly much. However, it can't be ignored that progress is being made at making php better.
5. The set of functions for a gazillion useful everyday things that don't come standard in other languages. Where else would you find functions like htmlentities(), strip_tags(), mysql_real_escape_string()? I like list comprehensions - Python can be very concise - but PHP isn't exactly verbose:
6. Navigating or searching the online documentation is lightning quick. You don't have to know the names of functions or variables, you'll find them. The examples are like mini tutorials.
7. The write-test turnaround is lightning fast. There's probably not a small group of languages in this group, but you will really notice this if you come from say, JEE.
You need (need!) a language that's fun to use (that's fun for you to use), day in day out, not verbose, nor loaded with layers of frameworks. PHP is simple, direct, and I haven't been bitten by problems that in other languages have taken days to work out... or have never been worked out.
Honestly, I have never been bothered by the humungous list of "issues" in the link at the top of Jeff Atwood's post.
BTW, === exists explicitly to test type equality first, that's the point.
When I wrote in PHP (and it lasted 10 years just to let you know), I would say exactly the same. PHP tasted better than, say, C++ Builder.
As we use to say in my country, "never tried things sweeter than carrot". I mean that was about me: I didn't know better things existed.
All that is done better in Python:
5. You don't need many of functions you use in PHP, for instance, _real_escape_string is not needed when you can do cursor.run("SQL Query param1=? AND param2=?", [param1, param2])
6. You can get help on functions in coding shell:
>>> help(open) # help on file opening function
or even
>>> open? # in IPython
With that I look into online or PDF docs quite rarely.
7. That's even faster in Python: you try things out in the shell, then save the shell session (IPython) and copy the code you need into the working file.
Moreover, while in PHP I was adding var_dump's everywhere, reloading a page 10 times before reaching the source of a bug, in Python I just do $ python -m ipdb same_script.py and have the debugging shell in the place I need, and it takes a minute of two to find the source of a bug.
I just don't understand why this is a problem. If the goal of a web language is to build websites then JUST BUILD WEBSITES. Who honestly still gives a shit what you build it in?
If you are into .NET and build .NET sites, then cool. I work with a bunch of WordPress sites and WordPress uses PHP...so that's what I use. Until they decide to switch languages, I'm sticking with PHP. Until then, shut the fuck up and let me work without making me feel like an asshole for not conforming to your way of doing things.
I'm not saying PHP is so great, not by a long shot; but if it's 2012, and people are still writing "OMG PHP SUX" posts, yet PHP is still everywhere, the only thing I can see that meaning is this: the things that matter to people who write "OMG PHP SUX" posts don't matter to anyone else.
340 comments
[ 4445 ms ] story [ 1070 ms ] threadEvery time anyone suggests improving anything, or make another product in a crowded space, this comic is posted. The author of this article doesn't even suggest a new platform - he suggests improving a platform that exists to enable easier deployment. It was posted yesterday for Chocolat... do we really have to stop making editors?
In a site targetted to hackers and startups it is disturbing that people are so unwilling to learn something new, support a new product, improve the world, do anything new. Yes, redundant standards suck sometimes, but it's not always the case.
I wish that the comic author would consider deleting this from the server, or maybe pg could ban it.</rant>
> I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible.
"I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible. Despite the serious problems with PHP, I was forced to consider it."
How much PHP do you use Jeff? Lets assume none. How is PHP hurting you? I mean seriously, how much contact do you even have with PHP?
PHP is easy to learn, easy to make websites with. There are a tonne of paying jobs which require PHP. PHP runs a lot of websites.
I am a PHP developer. I prefer Python but my PHP job pays me just fine. There are a lot of things about PHP that I don't like but it gets the job done just fine. You can write reasonable code with PHP. You can write secure code with PHP.
The main people who have problems with PHP are either ex-PHP developers who usually have gone on to Ruby and look back and fire a few shots at PHP. Or people like Jeff Atwood. Undeniably smart and talented programmers who for some reason are irked by the mere existence of PHP.
Please get over yourself.
I'm also a PHP dev and I think Python is the safest bet, since it has good support on all platforms already (including Windows).
Many, like me, disagree with that premise, and so consider that he is at best trying to fix a problem that either doesn't exist or doesn't require a drastic fix like he proposes, or at worst is very cleverly tapping into a vein of contention to hype an up-coming product.
The thing is, with those who do genuinely rant against PHP, at least we can have a useful debate with them over the issues. The "PHP is rubbish" posts that feature here regularly almost always lay out their arguments and basis for coming to that conclusion, from which useful (if sometimes repetitive!) discussion can ensue.
I think that the better alternatives, in the general case, are to participate in (or even fork) PHP and bring about the change together.
Show me the fucking code, Jeff.
Makes sense - There's definitely a pattern of bashing the popular languages.
Reading the article, I was struck by its similarity in structure and language to classic Windows bashing rants of the past two decades - i.e. "the problem with PHP is that it has no taste." In fairness, the call to action is radically different; to build rather than to buy something.
Actually, I think it is exactly because it's popular. All languages have odd ends, but you rarely hear people rant over Pythons lack of lambdas and weird explicit "self" parameter or Ruby's incomprehensible scoping rules. I'm betting that once they fall out of fashion, we will.
And no, I disagree. The main sentiment of the article is negative. It's a call to figure out how to dethrone PHP, but without telling us why this would be such an important goal.
Like Windows 3.1?
Of course that's subjective, and people disagree, but there really does seem to be a real, qualitative difference between the warts on a mostly nice language like Python, and the ubiquitous bizarro world that makes up just about the entirety of PHP.
This is entirely untrue. PHP isn't even a bad language on the scale of actual bad languages. It has some warts but they don't really impede the development of good software. There are many languages that make developing good software nearly impossible.
I don't know about impeding the development of good software. Warts can always be worked around as long as you know about them and how to handle them. But that doesn't mean they don't matter, and PHP has so many that it's difficult to enumerate them.
What other popular languages silently convert strings to floats and then do math or floating-point comparisons on them? What other popular languages have literally hundreds of failing unit tests in their mainline implementation, allowing ridiculous and insecure regressions that were actually caught by testing but never noticed to ship in an official release?
I doubt there's any one wart that's exclusive to PHP. What's remarkable about PHP is how it manages to gather so many in one place. Each one alone is not that bad, but the sheer number of them is astounding.
JavaScript. Most of the "issues" around comparisons/conversions/etc equally applies to JavaScript as it does to PHP.
But PHP does some very stupid casts but it's really just one problem. In the lists of "failures" tend to show that same problem 15 different ways to show how screwed up things are. If your code is well designed and secure you don't encounter these problems anyway.
> What other popular languages have literally hundreds of failing unit tests in their mainline implementation...
I'll give you that. Since that happened, the PHP developers have worked to ensure it won't happen in the future. No platform is free of particularly big security fails (Rails).
For the unit tests, it looks like there are still 100 unexpected failures in the latest release:
http://gcov.php.net/viewer.php?version=PHP_5_4&func=test...
Am I misinterpreting that?
Yes, no platform is free of security problems. But the way a security problem happens is as important as what the problem is. That PHP's unit tests are so noisy that important regressions can't even be noticed even when a test exists to catch them speaks extremely poorly of PHP compared to other languages.
I'm not sure when these where run but it would be easy for someone went through all of them and give them a pass. A failed test doesn't necessarily mean that deployment should be held up. 700 failed tests is a different story.
> JS doesn't have all these other problems, though.
JavaScript has plenty of it's own problems. It has legacy things you should never do. PHP has different problems (not necessarily worse ones) and things you should never do. Lists of the horrors of PHP generally include all things you shouldn't ever do mixed together to make it look much worse than it really is.
I've seen similar lists made for JavaScript (you can get some really crazy results) but that doesn't mean shit for day to day use.
Somebody has to fix them; these things don't happen instantly.
Given the fact that they had hundreds of failed test cases and now they only a few is a significant improvement -- and this is while development has continued. They realized the problem just as you describe; there isn't much more to say about it except they're working to fix it.
The startup scene's dirty little secret is that (anecdotal from several local companies I've worked for and/or collaborated with) PHP development is fast and cheap. Once you have proven you can solve a business problem and get funding, then you can decide if you really need to do a re-write.
There are just too many small companies focusing on real problems(instead of what language their webapp is built in) to make me think PHP is evil or that Rasmus Lerdorf is a bad person.
I've written web apps in: Ruby (both Rails and Sinatra), Javascript (Node.js with Express), PHP (my own framework, CodeIgniter, and eying Laravel), and been maintenance programmer for a C CGI application. I've written desktop and CLI apps in Object Pascal (Lazarus and Delphi), to CLI apps in Go, C++, and probably a few I've forgotten. I've done Object Oriented, Evented, and to some degree Functional programming. I am a polyglot programmer.
The problem is bashing PHP. As Jeff said, PHP's power is its ubiquity and its near omnipresence. It runs on just about any platform with any configuration, with almost perfect consistency. For the most part there's no switching extensions or libraries because of the OS. Develop wherever... deploy wherever... get almost an identical experience without lifting a finger.
In fact, I have great hope for the future of PHP with 5.3 and 5.4 as they (finally!) have added and improved upon the language, and have begun to cull deprecated features. The problem for PHP right now is twofold: web hosts refusing to upgrade in a timely fashion, and legacy codebases that refuse to be rewritten. Both these are demanding backward compatibility, and slowing the advance of PHP.
I'm tired of the bashing of PHP. Bashing, in general, is the absolute least effective way to communicate your point. At least Jeff Atwood is attempting to do something.
Which is why I began developping websites with it. But at some point, I felt like it was preventing me from really understanding what was going on behind the scenes, and I moved away from GRails and now nodejs.
I don't hate PHP but I think Jeff's last point is good: we need framework as easy to learn and setup, but that lets you understand how the web really works.
I'm quite curious as to your understanding of how the web really works.
I agree with your point and I just wanted to add that the fact that we have to add in little details like "I prefer Python" just to be taken seriously says more about hacker elitism than it does about PHP.
Why did you say that? To me it feels like you said it so people would take you seriously as a "real" biker. Because surely a "real" biker wouldn't actually enjoy walking unless they were forced, right?
Thought of that, Sherlock? Or should I say Bekas?
I do genuinely prefer Python. I picked it up when Django first started making noise and I really enjoyed working with Python (not so much Django). Now I mainly use Python to mess around with PyGame.
Its not a difficult to thing to say. For all of PHP's ease there are little niggles which get you down. Really simple things. Is a function called functionname or function_name. Is it ($needle, $haystack) or ($haystack, $needle).
Python is neater and I like neat.
The problem is that the developers of rails / grails / Wt / SproutCore / Flex / Struts / GWT / Django / Flask / Zope / Merb / Zotonic might be sure their framework is the greatest ever, and clearly worth a couple of days (or even a couple of hours) of someone's time to get it all configured and get started. However, I just see this giant list of options, each of which is in it's time the 'best thing ever'. How am I supposed to know which one to choose? Getting people started quickly and easily should be priority 1 if you want more users.
EDIT: Oh, one other strength of PHP. Many people when they start want to turn a static website they already have into a dynamic one. This is how I started on PHP, just including fixed headers and footers in a website. Then slightly customised headers which knew which page I was currently on. Then adding cookies to remember what users had already done. Then finally full user support.
In general, one thing PHP excels at adding the '1% dynamic' to an existing static website. However, I don't think this is as big a market as it once was, I don't think that many people learn a lot of HTML and make big static website anymore, then try to add dynamic elements later (or perhaps, I just associate with different people nowadays)
You're right about the 1%, and it's why classic ASP did as well as it did for a while too, until that was killed off. The fact that big players who once scoffed at PHP now embrace it (MS is a big one) shows how big PHP is and will continue to be for the foreseeable future Will PHP be here in 3-5 years? certainly. 10 years? possibly, but with a difference at least as big as php/fi -> php5 is, so current php5 skills won't really be of much use on their own.
You choose a problem that you think PHP can't solve[well]. You solve it using your high level language of choice and I'll solve it using PHP. Let's compare the outcome on reliability, ease of re-factoring, speed, whatever .. then, when it becomes apparent that there is little in the way of difference of the end product let's stop the fucking childishness.
I love that sort of phrase, I really do. It's so ... lacking in self-awareness. Really tells you a lot about the attitude of whoever utters it.
Edit: OK, I'll bite. Um, so you're telling me, I lack self awareness because I said "fucking childishness" .. and that you understand me on some level because of it. You might want to get down of that high horse of yours.
Yep, you lack self-awareness.
I also took issue because he didn't point out any actual problems or solutions .. rather he just blanketed PHP as a problem in and of itself and his solution was to replace it. This is not the kind of thing I'd expect from someone like Jeff who runs a site that points out in great detail programming flaws not just making hearsay.
Anyway, then you came along taking offence to my use of the f word. I'm sorry you take offence to harsh language but that's not my problem. Your first response to me added NOTHING to the conversation apart from your own very strange opinion of me because of two words I had said. I figured you where a troll so gave you the response I did. Then I thought hang on, let's check this guy out and see what we can glean from his past posts. You have been active for almost 100 days and your posts seem to point to you being a nice enough guy, so I figured you deserved more than my first general reply.
I also note that you just got your CS degree. Well done, and I hope you have a long fruitful career, I really do.
Terms like "bigoted rant" and "fucking childishness" always give me the distinct impression the poster isn't interested in reasonable discussion -- particularly on HN, given the usual monocles-and-earl-grey manner of conversations here. In my experience, that sort of language only irritates whoever may disagree, and so lowers the level of debate, while achieving nothing of value. As such, angry words on the internet always feel immature to me, so the phrase "fucking childish" struck me as amusingly ironic.
Your challenge to Mr Atwood also came across as facetious; I find it very unlikely that a busy man like him has the time for a code-off, but I could see someone claiming his failure to accept a challenge as a victory by default; and even if he did take you up on it, it would prove very little.
As such, your first post read to me as little more than a troll itself, so I felt I was only being flippant in kind.
To be honest, I would have downmodded your first post and left it at that, had that button appeared to me yet. Instead, in hindsight, I guess I thought I was (from my perspective) "feeding the trolls"; itself far from the best way to improve the level of dialog, I freely admit. It wouldn't help that I very likely came to this thread spoiling for a fight with those defending PHP; it's been a conduit for many headaches since I finished my degree & got a job.
Peace.
I've dealt with my fair share of poor PHP code bases, and have experienced PHP mature over the years into a very capable language; so know how to wield it to the best of it's abilities. If you ever need any advice feel free to email me.
Knowledge is power. Defending your own knowledge by refusing to expand and learn something new is cutting yourself off at the knees (or fingers, as it may be).
From Haskell you can of course go the route to Agda or Isabelle. But Curry is also worth a visit, it combines logical and functional languages.
I, for one, am still learning how to do left-fold based IO in Haskell with enumerators, at the moment.
There's a lot of frameworks that make many types of web site or web app development easier than PHP. There aren't any languages that were created explicitly with the goal of being used to create web pages (and later, by extension, web sites). OK, there might be a few that have gone by the wayside (ihtml, htmlos, etc), but nothing mainstream.
PHP is "content-type: text/html" by default, which can be overridden for other tasks. Everything else needs to make some adaptation (however subtle) to 'play' with HTML. Potentially something like mod_ruby or mod_python could take off, but probably not even then, as you'd be worrying about including base library stuff or extra modules, the majority of which are already baked in to PHP (gd, etc).
You have a web page up and just want to add a dynamic copyright date to the bottom? Copyright <?=date("Y");?> and change extension to .php (or play with some mod_rewrite rules on apache). Want to capture the output of every HTML page and rewrite some links (while logging those changes to a db?)? automatically prepend a php ob_start() call then append an ob_get_clean() function in the footer, then process away.
Doing these sorts of things in any other tech stack requires a lot more configuration and meddling, or possibly rewriting core site code. PHP can scale down to be nice additional decoration in a site, or can power the whole thing soup to nuts (and can scale up much easier than some other platforms can scale down).
Related: I recently had a basic site and needed to rethink it in terms of mobile toolkit. It was much easier to take what I had an add in jquery Mobile stuff than it was to work with Sencha (as one example) because other tools like Sencha assumed I was starting greenfield, which I wasn't, and I didn't have time to learn enough of their stack to try to extract the bits I wanted. jQuery made it easy to add the bits I wanted, and PHP does that for HTML/serverside aspects of things as well.
Want to kill PHP? Build alternatives to PHPBB, Wordpress etc that compete on ease of use (incl installing, that means have host gator etc support the language used) and PHP will slowly die out.
Even if we take that statement as given, what about everybody who doesn't care about development? Most modern frameworks take it as given that you are (or at least aspire to be) a fairly serious web developer interested in serious web development and are willing to learn a bunch of fairly abstract concepts up front about structuring and deploying apps. Until a framework comes along that assumes non of those things, php won't be replaced. Imagine your user is a domain expert in an area totally unconnected to computers or programming, but has managed to learn a bit of HTML and now needs to put together a site. What current framework targets this particular use case?
Something that doesn't involve any programming. Because getting all of the bits of web development together is hard work, and you're not likely to end up with anything decent at the end if you don't know what you're doing.
> there are already easy to deploy frameworks and languages for the web, and everybody who cares about development is already using them.
And yet, amongst your rhetoric, you've conveniently managed to name none of them. Is this an appeal to the silent majority?
I'm convinced that there are really good developers out there who just keep building great products in PHP. Good developers write good code largely irrespective of the language. The code is a mere artificial interface between the developer and the machine.
Brainfart. I meant Rasmus.
A programming language is a tool to get the machine to do what you want. A good tool will help you get the job done faster, and with fewer problems (like, say, security holes). It's not a "mere artificial interface", and if you think so, feel free to go write a web server in Brainfuck.
It helps to mitigate some common security holes, and sometimes prevents the coder from doing blatantly stupid like using unfiltered user input in queries.
Unfortunately the basic PHP structure is borked, and even within the context of a framework noob coders can do incredibly stupid things.
I'm pleasantly surprised at the high rates my PHP consultancy work commands; it's obviously helped by the number of hit-it-till-it-works web devs out there.
Granted, for larger projects where you run your own ruby/python services, it could surely be easier. But for larger projects you probably want to spend more time on your deployment setup anyway.
You can't do:
$something->doStuff()[0]
if(empty($something->doStuff()))
Overload fucking functions. Fuck.
What sucks:
The namespace separator.
The naming conventions of the core functions.
The speed.
But, overall it works and elegant solutions can be written.
Also, being competent in a market full of incompetents makes you valuable and getting a well paying job is easy. What's not to like about that?
Yes you can.
"Speed"
Care to expand on this one?
AFAIK, yes, in PHP 5.4 only so far, which is only about 4 months old. The first 15+ years of PHP's life, no, that wasn't possible. I'm glad it's there now, but frustrated it took so long.
I just read about the new closures. Too bad, scoping is still somewhat broken: You have to explicitly declare the variables you want to use from the outer scope.
I like the namespace separator, but I'll accept I’m in the minority on that one.
Being able to keep up with the slowest competitor in existence isn't very good.
Edit: I should add "in my experience" to the end of that, I have no stats to hand.
If you skip a framework on both languages, they end up as the two slowest languages. Hard to say if either is faster overall, but they are both awful. Using jruby provides a huge performance increase, and PHP really has nothing to compare with that.
I also understand the technical need for a new character (which doesn't exist for static languages or some other dynamic languages) and once you need a new character then the backslash is a reasonable choice.
Bjarne Stroustrup
Yet I thought this post was right on target. I'm busy cleaning and finishing up my PHP projects, and then I won't start another project in PHP. It will be ruby or python, or maybe I'll go functional. It depends on what I want to do. Yes, I can say everything that you so sarcastically proposed, but I also see the value in getting new coders to not start off with PHP.
It got to the point where whenever I sat down to write PHP, I would write it in ruby first as a sort of pseudo-code, then expand the brackets out into PHP after the fact.
Eventually I decided that I would be more efficient just skipping the expanding out step.
You (General you) get companies to hire experienced PHP Devs , even as entry level for other languages and I'll be there in seconds. However, all the jobs I see require 3+ years with that language.
* Let x be the technology you want to work with professionally.
* Spend roughly a year of occasional unfocused off-time building little side projects with x. You can do it faster if you have more drive than me.
* Put those side projects on your github profile or anywhere people can see them.
* Apply to companies that work with x, whether or not they say they are hiring, or take experienced hires from other technologies. Send your github profile along with the application. Preferably go via a connection, but this is not required.
* In the interview/application process, demonstrate strong, language-agnostic technical skills along with some fundamental knowledge/realisations specific to technology x.
YMMV.
And it's not that I haven't spent the time learning other languages and working with them. I did a degree in Computer Science and have worked for 12 years in the industry, over which time I have learned and worked with Pascal, C++, Ruby, Lisp, Javascript and dealt with a number of other languages. I discovered PHP early on, but only relatively recently have I really taken a shine to it, particularly with the releases over the past few years, and now I won't work with anything else.
I enjoy my job significantly more than I used to because of PHP.
In the main I don't find it a horrible language, I'm aware of its weaknesses and its "problems" (usually not problems per-se, but things it does differently from other comparable languages). But in the main it fits the way I think and work, and I'm incredibly productive (and I like to think that I don't write code that's too shabby either!).
The barrier to entry with any other popular language such as Python or ROR is that's it's hard to just toss a script up and see results.
As a result, Facebook engineers developed things like this: http://en.wikipedia.org/wiki/HipHop_for_PHP
Which is an impressive piece of technology, but makes you wonder if Facebook engineers wish their website wasn't written in PHP.
Who knows...
http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...
Facebook is stuck with PHP for their legacy codebase, but you'll note they avoid it for new code that isn't tied to the existing codebase.
I'd be surprised if they chose PHP because of future hireability / scaling up. I'd guess they didn't give it much thought and PHP was just there.
The second place choice was probably perl (via cgi or mod_perl).
I guess Tomcat was around too.
Both Django and Rails were released after facebook.
But he said nothing about "inventing" a language. In fact said very clearly that he wanted to take an existing language and add to it - particularly the things that PHP does do well.
from TFA:
> "to buff up a open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment"
I suspect that he is being deliberately vague here; in other words there is an announcement coming at some later date and this is preliminary PR. That doesn't make it untrue though.
Currently, no other language can match that. They either require a VM running (Java, Ruby, etc.) or at least have a compile/build step (Python).
UWSGI has a lot of promise, but until it's as easy to get configured as PHP-FPM, PHP is still way easier than everything else.
> Except now it's 2012, and fellow programmers are still writing long screeds bemoaning the awfulness of PHP!
Yes, and not only did Jeff write one in 2008, but he wrote another one just now. You can't write 10 paragraphs about what a blight PHP is and then pretend like you're being constructive by admonishing us to create better tools.
In fact what everyone is doing with these rants is bike-shedding about an easy-to-hate language. It makes an easy topic that drives a lot of traffic because everyone has an opinion. It's just tabloid garbage for the hacker set.
A more objective view of things is that PHP is a capable-if-ugly language, and it co-exists just fine with thousands of other programming languages and frameworks all with their own visions, communities, and production applications. The existence of PHP is not harming other "better" languages at all. And if you really want to make an argument about languages hurting the state of programming, how about asserting that the dominance of imperative languages is irreparably damaging the ability of most programmers to work in functional languages where solutions are fundamentally more robust. Or what about the damage that proprietary platforms like .NET (which Jeff uses if I'm not mistaken) or iOS do to the programming world by restricting progress to a single company.
I won't belittle Jeff's contributions to the software world, because Stack Overflow is an amazing service, but despite the fact that I hate PHP, Rasmus' contribution to the software world is certainly much more important than Jeff's feel-good blog fluff.
PHP is used for web development. Microsoft's best alternative for web development is ASP.NET MVC which is open source.
Sad and kinda small of them.
I'm willing to win the lottery, mind you, but I'd never waste my time or lower myself down to bashing poor kids.
"Ex-PHP developers that bash PHP programmers are like the poor kids that win the lottery and then start bashing poor people publicly."
or
"Ex-PHP developers that bash PHP are like the poor kids that win the lottery and then start bashing being poor publicly."
? Very different, IMO.
Tools evolve over time and saying screw drivers are useless and everyone should use a battery powered screw driver doesn't change the fact that a screw driver drives screws.
If you don't like the tool move on to other tools or make your own and get people to adopt them. Don't bash the brilliant people who worked hard to make the tool in the first place.
My father is 71 years old and codes in PHP! He was never going to learn python, ruby or anything else but PHP was approachable for him. Provide a language with that low barrier to entry and let's talk. Meanwhile I love my dad but we won't be writing the next google and that's ok by him and I both. If he wants that he'll ask me to write it in COBOL! :-)
I just don't see how PHP is more approachable, especially compared to the supposed ease of ruby on rails.
PHP is the A-10 of languages. It's a slow, ugly and easy target. It works pretty much everywhere.
There isn't any one perfect solution, just workable ones.
Perhaps it's best if you either completely take deployment into your own hands, or you let someone else do it for you. Given all that, rolling your own could still be made simpler.
Try these guys (they also do rails and other stuff as well): webfaction.com
Compare Ruby to PHP and something like Symfony to Rails.
Learning Ruby: approachable. Learning PHP: approachable. Learning Rails/Symfony: run for the hills (for newbie programmers).
Languages !- Frameworks (at least for the purposes of this comparison)
Him figuring out <? print date('Y'); ?> is fairly easy when he already understands html.
> build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.
A bite later:
> We've got a long way to go. [...] The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.
Basically, Jeff just agreed that PHP is simply better than the rest. The problem is that he cannot accept that thanks to PHP anybody can code something pretty fast. I am always amazed when I see my brother, without programming knowledge improving his wife website like gardening. Small changes here and there. End at the end the website is making money. He never complained about the "awfulness of PHP".
As the article states, if all you know to use is a double clawed hammer, it looks like the best tool for the job.
I'm looking into ASP.NET MVC for a project and if you walk through the "hello world" tutorials with that package they are 10 pages long and filled with lots of magic. As a developer, I understand the significance of that magic and it's long term purpose. But it's probably far from the best tool for the job if your project is simple.
The flaw here is perhaps the assumption that the best tool for the job is the same for everyone and the same for every task.
Easier != better. Nice try.
He's going to tweak his site, continue making money and stop caring about whatever the hell his site is written in.
Again, from the brother's perspective, perhaps learning Ruby is the tempting shortcut ("I'll just learn this awesome language first and my website will be super easy to upgrade and modify")
...
and then it takes him too long to get back to his website, which has floundered and is no longer popular or making money. Or ruby was too hard for him so he went back to tweaking his site with PHP. Or <whatever>
My point is that it is all about perspective, something that a lot of HN misses. Not everyone cares about technology. Most people just care about getting the job done and making money, using whatever tool is easiest for them to personally use, at the time they need to use it. So to that guy, it isn't a tempting shortcut: it's the best route to prosperity.
The people who prefer PHP are right. The people who avoid PHP are also right. They are solving fundamentally different problems.
[1] http://www.infoq.com/presentations/Simple-Made-Easy
Maybe a little OT, but I can't shake the feeling that he's going to introduce some nasty security bugs if he's hacking on php code without knowing what he's doing. Might not matter, but then again someone could find it and completely ruin his small business.
(of course you can write "secure" code in php, but you need some knowledge to do so..)
I was expecting an elitist diatribe about PHP (because this is perennially popular amongst particular programmers) but that's not what this post is intended to be.
Interestingly Jeff does take the usual potshots at PHP almost like he thinks he'll lose street cred if he doesn't but the basic message I agree with: if you want someone to stop doing something you consider undesirable give them better alternatives.
That being said, I simply disagree with the premise. PHP has a lot going for it:
1. The CGI type model of creating everything, servicing an HTTP request and tearing everything down is a powerful one (and used in Python, Ruby and elsewhere). Once you go stateful (eg Java servlets) you have to worry about resource leakage;
2. PHP has a stateless core of API functions. IMHO this is basically ideal for Web programming given (1). It makes startup/teardown cheap and reduces resource usage (making it cheaper to provide for hosting);
3. Imperative programming is IMHO a natural fit for Web programming. One thing that's wrong with PHP is all the bloated OO mega-frameworks people create on top of it to try and make it Java, Rails, whatever; and
4. Inline code in HTML is a powerful technique. The learning curve for PHP is quite gentle.
So if you want to make a better PHP (something I'd encourage anyone to do rather than simply jumping on the PHP hating bandwagon) you should tick all the above boxes. Of course if you do this, you will probably want to fix some of the following:
- argument order consistency
- API function naming consistency
- default to HTML escaping on output
- effectively default to SQL parameter binding
- no register globals
- and so on
Side note: all of the above is well known. Pointing it out in yet another PHP hating blog post is both pointless and boring.
Jeff also asserts that PHP's popularity is sheep mentality. What nonsense. (1)-(4) above explain it far more than that, particularly the cheap hosting and inline coding.
I like to point out that 4 of the top 20 sites are built using PHP (Facebook, Yahoo, Flickr, Wikipedia) so--like it or not--it must be doing something right.
Homer (Simpson) once said "sometimes the only way you can feel good about yourself is by making other people look bad and I'm sick of making people feel good about themselves". I see a lot of that with (us) geeks but it's just so unproductive and pointless. You don't need to hate on "not X" to justify your choice of "X" (X = Python, Ruby, Lisp, Clojure, Scala, GPU type, phone type, tablet type, camera type, you get the idea).
EDIT: as far as Facebook goes, they didn't "give up" and use HipHop, they decided to have their cake and eat it too. They get the productivity benefits of programming Web pages in a "fit for purpose" language while getting most of the performance benefits of native code and they only had to give up some small subset of PHP to do it.
If you argue the subset thing is a problem try working in any C++ shop where using only a small subset of the language is de rigeur.
I can pretty much create and "deploy" a PHP web app within minutes of getting a run-of-the-mill hosting service.
Similarly, LPG is a great car fuel here where I live, because of a good price and abundance of gas station, but it's not the case in the US.
??? Is that a joke? Don't do that! That's just as bad as magic quotes.
> no register globals
It hasn't existed for a quite a while now in PHP.
Other than that I quite agree with what you wrote.
Most of the criticism of PHP is simply a desire to be special. If lots of people are using something, you want to make sure not to, so that you feel special. Now that you've decided not to use it, you need to justify it to yourself. And people find all sorts of real criticisms in the process - yet none of them matter!
> ??? Is that a joke? Don't do that! That's just as bad as magic quotes.
No, it's not. Magic quotes are a pain to reverse. HTML escaping can be built into the echo/print/<?= .. ?> commands, so that it is:
Plus too many cases of extra backslashes from back in the magic quotes days.
Negligence should result in mangled output, not a security problem.
HTML escaping is not the one and only escaping strategy that magically makes everything safe. So any automated system would need to incorporate overrides on a per variable basis.
http://blog.astrumfutura.com/2012/06/automatic-output-escapi...
I understand the debates Django had about changing what the unspecified output function did, but nowadays if you're building a new template language of any kind it's an absolute no-brainer: Make it easier to encode than to bypass encoding. The alternative is just awful.
What if I assign that string in a variable, and then output it later?
I'm not convinced this can be done well. Maybe if all you do is make some templates and fill them in you could do it. But I do a lot more than that, I output dynamically built html all the time.
Just give people a very easy and shortly named function for escaping.
Ask any Haskell weeny for details.
Also in your example, you'd probably be better of, if your language knew about the HTML structure, e.g. something like P($var), instead of putting the tags in as strings.
And if you can't extend your type system to make this work, do it in your head, mutating the names of variables to help you keep it straight. For example, esStr and unStr are not of the same type, and moving data from one to the other without conversion is always an error.
http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).as...
http://roboprogs.com/devel/2009.07.html#2009_07_30 (point number 4 in the numbered list)
Of course, I was thinking of a runtime attribute, rather than static typing, but the idea is similar.
I like this, although when you concatenate strings, does it actually concatenate them (and loose the type info)? Does it escape them, and then concatenate? Or does concatenation actually make a closure, which is only executed upon output? (And does doing that make things memory heavy.)
Haskell is on my next language to learn list.
> something like P($var)
Ugh. I hate that. I've spent years learning HTML, I want to write HTML, not some other language that looks like it.
$foo = <p>$textvar</p>; $foo->append(<span class='will-end-up-before-close-of-p'>Hello!</span>); // etc.
Mozilla proposed to add XML literals to JavaScript at one point, which didn't take off for security reasons, but server-side it's a different ballgame... maybe it could be worked out? Hmm.
Have you looked at how Racket (Scheme, Lisp) deals with encoding HTML in S-expressions? I find that rather nice, and even prefer it to plain HTML or XML. Racket is a fine language for manipulating S-expressions, too.
Also about the HTML: You can of course use different syntax for what I proposed, one that's closer to actual HTML. But I think as long as the syntax tree is preserved, it's still close enough to HTML for me, and all your accumulated knowledge about HTML is still applicable. (Not to be derisive, but if your years of learning are no longer of any use upon such a cosmetic change, you should probably examine your level of comprehension.)
PHP IS a templating language. Writing another one on top of it is just adding complexity for no gain.
I'd say don't do that, refactor into templates instead. With your preferred approach to generating markup, you're largely on your own in protecting against XSS. Hopefully all the developers using your code are awesome at spotting and pro-actively dealing with XSS issues.
Still, with a HTML escape everything default, either turn it off, or use a raw "I know what I'm doing" method instead.
You'd do something like @html.SalesWidget("90% off today") with the SalesWidget being responsible for escaping the string.
Also I don't really get your argument, why not give people a really short and easy way of not escaping a string instead? The opposite of what you're suggesting is just as easy and far safer. You're less liable to accidentally muck up.
Such a mechanism would have to include encoding functions (and assertion override functions), of course.
It seems this would help alleviate many types of fill-in-the-blank injection problems as well.
Not to mention the (also type safe) dead easy to use persistence framework.
I'm still in the process of evaluating different solutions for my next web project but so far I'm pretty sure this is gonna be my go-to framework in the future.
[1] http://www.yesodweb.com
I'd like to mention something similar that I found in human behavior with respect to manufacturing jobs that we used to do for customers at a company that I was at. What we found was that people had 1 or 3 major complaints about something that were pretty valid. But what they did then was feel that they needed to build a strong case so they ended up coming up with as many nits as they could to build their case as if that somehow made the true concerns stronger. Just my experience but I have found that if you have a true concern about something to simply focus on trying to get that fixed. If you throw everything in the other party sometimes feels that they will never be able to please you and then they don't even try to fix anything. YEMV.
The developer's usual routine is the same as someone using Zend; they write honest-to-goodness PHP and reload the page. There is no compilation involved; you instead are using the JIT (or until recently, an interpreter) that monitors the filesystem for changes and silently integrates them.
Facebook devs use PHP exactly as everybody else does; they just do so with a different toolchain.
You will find any number of C/C++ programmers who think you can't write anything in Java. Many Java programmers think you can't write anything (beyond 100 lines) in Python. Many Python programmers think you can't (or simply shouldn't) write anything in PHP. And so on.
Some people are insecure.
Some people can't separate their language from themselves (and see a criticism of their language as a criticism of them as people).
Some people exemplify the Dunning-Kruger effect [1].
Some, like teenagers, are just asserting their identities.
Some simply have biases that are mental blocks.
[1]: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Ppl who have strong opinions when it comes to language design have strong opinions when it comes to language design. Ppl who think languages are just a means to an end think languages are just a means to an end. These are two differenty species and indicative of their particular worldview, attitude and preferences. To use that as any kind of filter is silly.
Lets not look at CS for a second...If you want to know what a Stieltjes integral is, a probabilist will tell you one thing, a functional analyst another, and a measure theorist will give you yet another more pedantic definition. There's no right or wrong definition here...every one is coming at it with the tools they are more well versed in. The probabilist is the end-user, so to speak. He can't do his day to day work without internalizing it, because his bread and butter, the PDFs and CDFs of all the distributions he deals with, comes from Stieltjes. The functional analyst is going to use Stieltjes when he deals with Banach spaces, but otherwise he has other preoccupations. The measure theorist studies Stieltjes in depth because it goes to the very foundantion of measure theory...but he isn't really an end-user.
Now back to CS...a C++ programmer will think of Java as an interesting toy because you don't get union types and pointers & so forth. The Java guy will think of Python as an interesting toy, and the Python guy thinks PHP is an interesting toy. None of this means any of these people are insecure or being a teenager. If the only goal in life is "languages as means to an end" where end = $$$ in the short term, then yeah, lets just cut to the chase and do PHP. But there are other goals, yeah ?
When you have crap like this in your language:
> E.g., $i = 0; $a[$i] = $i++; makes a different array than $i = 0; $a[$i + 0] = $i++;
you have no hope of making a truly large program work. There are just too many sources of itsy bitsy bugs; you'll never find them all.
(I'm not a PHP user; I have no idea why those are different arrays. Don't bother explaining; I don't want to know.)
You get $a[1] = 0 the first way, and $a[0] = 0 the second way. PHP seems to evaluate the array index before the right hand side if there is something more than a $variable to evaluate; otherwise PHP evaluates the array index after the right hand side, after $i has been incremented.
I haven't used hiphop, but I'm curious if it preserves that disparity between arrays when translating to C++, or if it breaks PHP compatibility by making those two arrays equivalent.
Maybe you should be the one to stop being so arrogant as to tell other people what they should feel.
Meanwhile, PHP gets a number of things very right. For instance:
* State: there is none across requests. Oh sure, there's APC, and the filesystem, and databases, etc., but those are all accessed via libraries. There is no PHP-level state that survives a request, which provides natural fault isolation: a request which goes wrong doesn't take the server down with it, or live on to corrupt other requests.
* Concurrency: PHP's concurrency model is the web request. If you want to run some code in parallel, curl to localhost. If you wrap an appropriate library around this, it looks just like Erlang's actors. This is shared-nothing concurrency, which turns out to be a compelling local maximum.
* Interactivity: The development workflow PHP provides is very productive. You save and load the page. You don't save, optionally recompile, restart the server, wait for it to initialize, forget what's different from the last three times you tried this because this has all taken three minutes and you forgot to write it down, etc.
These three things turn out to be among the most important parts of a server-side language, and PHP gets them very, very right. The rightness was accidental, not by design, but this doesn't make it any less right.
Also, the language itself can be improved. In the HipHop toolchain, -v Eval.EnableHipHopSyntax=true turns on a bunch of (backwards-compatible) features we've added to our PHP dialect, the most notable of which are XHP (syntax for using XML literals as PHP expressions) and generators (inspired by Python's, using similar 'yield' syntax). I put up some sample code for a talk just the other day, if you're curious: https://github.com/kmafb/hiphop-samples
So the language does two of these three things by not doing them at all ? State: oh there's no state across requests. Concurrency: No shared resources, no threads, but we'll call it shared-nothing concurrency and then say it looks like Erlang!! Amazing. An Erlang actor holds mutable state and sends immutable messages. A web request in PHP does neither.
> If you want to run some code in parallel, Why do you even bring up parallelism in a post about concurrency ? ( http://news.ycombinator.com/item?id=3837147 )
> PHP gets them very, very right. The rightness was accidental.
Completely agree. Here you have a language that decides to tackle hard problems in CS by not tackling them. Then it becomes uber-pervasive because you can do "hello world" over the web by just doing <?print("hello world");?> Once the traction is a given, we argue about why not tackling hard problems is actually "very, very right".
Getting "hard problems" right by realizing they're intractable and refusing to solve them is a perfectly valid system design choice, even though it drives people up a wall when they first encounter it. For an example that has stood the test of time, check out UNIX's handling of the "PC-losering" problem: http://dreamsongs.com/WIB.html. When modern systems people read about this controversy, it seems kind of insane; of course system calls can be interrupted, and of course you don't want the OS to be magically trying to make them look transactional by backing up and restarting your system call when the world is really in an unknown and unknowable state. Ctl-C on a read() shouldn't restart the read(), unless the application thinks it should, and only the app really knows. EINTR was the non-solution that acknowledged the intractability of solution.
Historically, UNIX is a "worse-is-better" system not unlike PHP. I claim anyone designing a new system from scratch to replace it should learn from it, though, both mistakes and successes. PHP is not free of successes.
About the only thing you're protected against is memory leaks, and that seems to be because you have to, otherwise PHP would fall over in a big heap: https://www.google.com/search?q=php+memory+leak
I haven't had any problems with memory leaks running things like Django or Bottle.
What I mean is that whilst you guys at Facebook are using PHP you're not using it in the sense of 'we write code anywhere and deploy it anywhere'. There's an additional build step in between the developers and the final product, rather than just straight up serving PHP as is which is one of the biggest PHP recommendations. Although HipHop is open source so I guess you could still say it's within reach of all developers.
According to him there's no explicit build step the devs have to perform and they're just writing PHP and using open source packages--meaning they are in fact making use of the "write once run anywhere" ideal at least in some places since the open source packages were made to run on Zend and now they don't. The "write once run anywhere" ideal is kind of a myth anyway since there's always configurations to do, and language-wise was even more of a myth when PHP 5.3 was new. (Some hosts still don't support it, and I'm sure a lot of us remember hosting services who dragged their feet just getting off PHP 4.)
It seems like you think the Zend backend is the One True PHP runtime and anything else isn't PHP. This is like saying PyPy isn't Python. It's just a bad argument.
Now, as far as I understand it the Zend backend takes the PHP code, creates opcodes and executes it in a VM, whereas HipHop takes the code, compiles it down to C++, compiles it again with G++ then runs the resulting C++ binary instead. To me at that stage HipHop is no longer a backend, but an entire build system transforming the language away from PHP.
Like I said, I'm not as intimately familiar with the system, but I thought it was along the lines of they have a dynamic system for local development, and when they serve it up it's run through the HipHop compile process.
The thing that really fries my brain is templating systems built over frameworks -- PHP is already a templating system, and building another one in PHP is just silliness of the highest order. I mean, sure, separate out the gnarlies and include or require them as necessary (but, please, don't nest includes so deeply that you can't find anything anymore), but don't throw away what the environment provides just so that you can reinvent that particular wheel.
Did we read the same article? Jeff admits that PHP has a lot going for it and we should stop complaining about it.
The biggest thing PHP has going for it is that it is supported everywhere.
I disagree with this, especially in a RESTful world. It is very convenient, and obvious, way to look at a web request as a referentially transparent function for the most part. And the non referentially transparent requests really do change the world. We are moving our backend to a bunch fairly clear workflow of, that has layers that look like:
Get DB stuff -> referentially transparent -> Write DB stuff
And these can be arbitrarily nested. It works pretty well, it's easy to reason about, and it's pretty easy to write.
Hey guys, Jeff said his piece about PHP, everyone else shut up about it now.
I sense this is probably done quite a lot in journalism, so you can write 'interesting' articles without coming off like a completely biased douche.
I don't even get the part where he says that we need to come up with better solutions. So, if we want better solutions when are they going to arrive. It's not like that the solutions are getting baked in some oven or something.
We have new solutions that we can use. We may even call them better, but I don't think that I will quit a language just for the fun of using something new.
PHP might be st, it might even break at times, but there are some wonderful frameworks which have come up lately. Laravel is one of them and a number of developers are contributing to the code. One cannot just ignore the fact that so many people have gone mad and not even a single one of them actually felt the need to quit PHP forever and build a new language that is better than it.
(I did like the quote suggesting AppleScript is "even worse" than PHP. I'd say it's far worse, since AppleScript makes easy things difficult.)
I don't mean to defend php overly much. However, it can't be ignored that progress is being made at making php better.
5. The set of functions for a gazillion useful everyday things that don't come standard in other languages. Where else would you find functions like htmlentities(), strip_tags(), mysql_real_escape_string()? I like list comprehensions - Python can be very concise - but PHP isn't exactly verbose:
Compare, reading a web page:
http://rosettacode.org/wiki/HTTP#PHP
http://rosettacode.org/wiki/HTTP#Python
http://rosettacode.org/wiki/HTTP#Java
Sending an email:
http://rosettacode.org/wiki/Send_email#PHP
http://rosettacode.org/wiki/Send_email#Python
http://rosettacode.org/wiki/Send_email#Java
6. Navigating or searching the online documentation is lightning quick. You don't have to know the names of functions or variables, you'll find them. The examples are like mini tutorials.
7. The write-test turnaround is lightning fast. There's probably not a small group of languages in this group, but you will really notice this if you come from say, JEE.
You need (need!) a language that's fun to use (that's fun for you to use), day in day out, not verbose, nor loaded with layers of frameworks. PHP is simple, direct, and I haven't been bitten by problems that in other languages have taken days to work out... or have never been worked out.
Honestly, I have never been bothered by the humungous list of "issues" in the link at the top of Jeff Atwood's post.
BTW, === exists explicitly to test type equality first, that's the point.
As we use to say in my country, "never tried things sweeter than carrot". I mean that was about me: I didn't know better things existed.
All that is done better in Python:
5. You don't need many of functions you use in PHP, for instance, _real_escape_string is not needed when you can do cursor.run("SQL Query param1=? AND param2=?", [param1, param2])
6. You can get help on functions in coding shell:
>>> help(open) # help on file opening function or even >>> open? # in IPython
With that I look into online or PDF docs quite rarely.
7. That's even faster in Python: you try things out in the shell, then save the shell session (IPython) and copy the code you need into the working file.
Moreover, while in PHP I was adding var_dump's everywhere, reloading a page 10 times before reaching the source of a bug, in Python I just do $ python -m ipdb same_script.py and have the debugging shell in the place I need, and it takes a minute of two to find the source of a bug.
If you are into .NET and build .NET sites, then cool. I work with a bunch of WordPress sites and WordPress uses PHP...so that's what I use. Until they decide to switch languages, I'm sticking with PHP. Until then, shut the fuck up and let me work without making me feel like an asshole for not conforming to your way of doing things.