Hacker News new | past | comments | ask | show | jobs | submit login
Coding Horror: The PHP Singularity (codinghorror.com)
274 points by prajjwal on June 29, 2012 | hide | past | web | favorite | 327 comments



The irony of this post is boundless.

> 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.


No, PHP is a language with some framework-like aspects. Your nitpicking is quite poor.


I'm just saying that Microsoft offers tools(languages or frameworks) for web developmet that are open source. And yes you have Mono project also.


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.


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.

Please get over yourself.


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.


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.


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.


So, the problem with PHP is that it is popular? I guess it was the same crime that Java committed 10 years ago. And C++ before that.

Makes sense - There's definitely a pattern of bashing the popular languages.


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.


What other popular language is as bad? COBOL?

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:

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 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.


>"Well, I doubt it would ever become popular if it wasn't useful and easy to use."

Like Windows 3.1?


Hey, at least he's not just ranting like everyone else; he's trying to bring forward a better alternative.

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).


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"?

Show me the fucking code, Jeff.


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.


Very well put.


It read like a pretty vanilla rant to me.


Probably because you did not read the last part of the article where he says that he's trying to build a better alternative.


Except I did. I read every word.


You see, once they learn Ruby, they're "rockstar ninjas" and can't wait to tell everyone.


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.


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).

Python is neater and I like neat.


damn, that was spot on.


Or he said it because he does prefer Python.

Thought of that, Sherlock? Or should I say Bekas?


From the post:

> 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".


Basically, Jeff just agreed that PHP is simply better than the rest.

Easier != better. Nice try.


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.


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..)


Life is full of tempting shortcuts. Take them at your peril.


Well that's basically saying nothing at all.

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.

[1] http://www.infoq.com/presentations/Simple-Made-Easy


I'll still get there before you.


Update: "bite" is a typo, but it fits well :)


>..my brother, without programming knowledge.. > 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.


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.


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.


"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.


Cool story, bro.

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?

Yep, you lack self-awareness.


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.


Okay, I think I see how this worked out.

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.


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.


Write a multi-threaded program in PHP, I will write one in ... well pretty much anything else.


That's not a problem though, is it.


Actually I see PHPs lack of multithreading as one of it's few good features


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).


I'm sorry, but at what point did I say I was refusing to "expand and learn something new"?


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.


Have you done any Agda, recently?


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.


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 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!).


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.

YMMV.


"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.


Who's Rasmussen?

> 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.


> Who's Rasmussen?

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.


I use PHP and I care about development. Your statement appears to be hyperbolic.


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?


HTML. Or some sort of managed CMS.

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.


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?


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.


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.


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'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.


Interestingly, this is the problem with non-alphabetic natural languages, too.


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.


Which kind of leaves me not understanding how it's deployed, etc., which I kind of feel like I need to know.

There isn't any one perfect solution, just workable ones.


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.


Django + dreamhost sucks, I concur.

Try these guys (they also do rails and other stuff as well): webfaction.com


Stop comparing PHP to Rails.

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)


He's been an HTML coder for about 10 years doing sites with front page and other html authoring tools.

Him figuring out <? print date('Y'); ?> is fairly easy when he already understands html.


That makes sense then. There is more of a shift in thinking going from html to python vs php.


Everyone's jumping on the PHP bashing. I don't think that's what this blog post was really about. Did you read to the end?

  One of the explicit goals of my next project is to do whatever we can to 
  buff up a ... particular ... open source language ecosystem such that it can
  truly compete with PHP in ease of installation and deployment.
Kind of a cliffhanger ending... What are you building, Jeff?


Whatever it is, it better be fucking perfect after all that. This post is PHP bashing with a cherry on top. But mostly PHP bashing.


I seriously groaned when I saw this post (title).

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.


> default to HTML escaping on output

??? 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!


    > > 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.


GWT too. Not having escaping by default by now, in 2012, is just plain backward.


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.


> Just needs a bit of type system magic.

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.


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.)


How about just:

$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.


I agree, the language runtime should support this somehow.

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.


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.)


> 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.

http://msdn.microsoft.com/en-us/library/aa260976(v=vs.60).as...


Which was one of the original and useful points of (apps) hungarian notation.


And you might even write a `lint' like source auditer to warn you about those conversions, even if your compiler doesn't.


> If I make a string: '<P>' . $var . '</P>'

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.


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 separate my concerns just fine using PHP. Different files, not different languages.

PHP IS a templating language. Writing another one on top of it is just adding complexity for no gain.


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.

[1] http://www.yesodweb.com


The Haskell frameworks do this, more or less: www.snapframework.com, for instance.


> > default to HTML escaping on output

> ??? 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.


I've seen too many multiply encoded things to be so sure this is a good idea.

Plus too many cases of extra backslashes from back in the magic quotes days.


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.

http://blog.astrumfutura.com/2012/06/automatic-output-escapi...


"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.


> 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.


I think you forgot an important feature of PHP: it just works.

I can pretty much create and "deploy" a PHP web app within minutes of getting a run-of-the-mill hosting service.


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.


I simply disagree with the premise. PHP has a lot going for it

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.


> 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.


I can add to this list:

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.


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.


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.


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.)


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.

Some simply have biases that are mental blocks.

[1]: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect


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 ?


You have obviously never worked on a million-line codebase.

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.)


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 like how people who exemplify the Dunning-Kruger effect are entirely willing to cite it in order to look smart.


Not all languages are equal. (if they are, why not just write everything in assembly?)


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.


Some of us like to write good code in a good language too.

Maybe you should be the one to stop being so arrogant as to tell other people what they should feel.


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 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.

> 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".


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.


Well, except that PHP has access to the database, sessions, cookies and the filesystem. There's a whole bunch of state right there.


It also has a variables and instruction pointer. The point is that this state is not preserved between different requests.


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.


Is that tooling you mentioned related to/uses 'pfff' ? (https://github.com/facebook/pfff)


Yes, exactly. Thanks for mentioning it.


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.


Hm, I possibly need to clarify it up a bit.

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.


Almost every web stack at the scale of a Facebook at some points starts writing some part of it in C. Its a pretty consistent pattern.


His post irritated the hell out of me. For 90% of it, he rips on PHP, then at the end he says, "how about bloggers stop ripping on PHP?"

Hey guys, Jeff said his piece about PHP, everyone else shut up about it now.


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.


When you don’t create things, you become defined by your tastes rather than ability. Your tastes only narrow and exclude people. So create.

- why the lucky stiff


I will always upvote/retweet/point and jump at this quote when I see it. One of the most important lessons anyone can learn.


I'm a PHP guy (started in the PHP3 days) and a few weeks ago I decided to finally have a go at building a non-trivial site using uWSGI, Flask, sqlalchemy and mongrel2. I knew a bit of python (from having written a few trivial sysadmin related scripts) but apart from that I was starting cold. I'm now a few weeks in and while I'm not ready yet to jump ship back to my PHP comfort zone, I can say I've been surprised to find that Python (one of the "better, grown up" languages that's always cited in these PHP bashing threads) has quite a few warts of its own:

- Packaging in python seems to have been a nightmare up until quite recently. It appears things are a little more sane now that pip is emerging as the new standard but there's still documentation all over the web referencing easy_install. Of course, then there's distutils2 to muddy the waters...

- The Python 2 to Python 3 transition was and continues to be an almighty upheaval. At the moment huge swathes of the python ecosystem have yet to introduce python3 support (e.g. Flask).

- Virtualenv is a fairly ugly hack in itself but even worse than that, trying to move a virtualenv directory somewhere else on the file system turns out to be impossible unless you use another third party tool.

- The python language has no switch statement. I refused to believe it when I first discovered this but it is actually true.

So, two weeks or so in and those are my main gripes thus far. Apart from that, I'm enjoying python. My favourite "python thing" discovered so far is all the cool list iteration syntax.


PHP is basically the latest example of "Worse is better"(http://en.wikipedia.org/wiki/Worse_is_better).

----

Simplicity: The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

Correctness: The design must be correct in all observable aspects. It is slightly better to be simple than correct.

Consistency: The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation.

Completeness: The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

----

I don't know about you, but IMHO, this is PHP in a nutshell.

Edit: One other little thing I forgot to mention. PHP is like Java in that it is really hard for a metaprogramming or type system nerd to do something tricky and clever that another novice programmer brought in to replace him would not have a chance of unravelling.


Consistency: The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation.

. . .

I don't know about you, but IMHO, this is PHP in a nutshell.

If you had read some of the criticisms of PHP that had been posted to HN (like http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de..., which was even linked to in the current article), you'd realize that PHP is nowhere near consistent. I'm not sure simplicity, correctness or completeness apply either. I think the only thing PHP has going for it is momentum (in having a large userbase and being installed almost everywhere).


PHP's inconsistencies are minor. The problem with quoting the fractal article is at least a third of it is totally wrong and another third is misunderstandings by the author.


The API is what it is, but the real biggest problem with PHP is also it's biggest feature: it's got the lowest barrier to entry of any server-side language.

The result is that a lot of PHP is awful, cargo-cult stuff glued together by people who have no idea what they are doing.

It's possible for talented developers to create really good programs in PHP, but I don't see how a new language is going to solve the essential problem. People who don't really know how to program and just want to accomplish some simple goal are going to use whatever language is the quickest means to their ends.

Copy/paste spaghetti is a nightmare to maintain in any language. And the people creating it are the same people who are /not/ going to read Atwoods post, don't understand very much about how programming works in general, and will continue to create cruddy programs no matter what language it is written in.


I hope Jeff succeeds in promoting an alternative to the level of ubiquity of PHP. I think PHP is a generally awful language, eclipsed in sheer programming linguistic badness only by such systems as MUMPS (which, fortunately, I have never had the opportunity to work with). Fractal of bad? Check.

And it isn't just a bad programmer thing. PHP's bad habits encourage novice (or uncaring) programmers to pick up bad habits, especially if they are not particularly inclined to study how to use their tools well. Given a language where the obvious thing to do is right vs. one where it's wrong (see PHP < 5 database queries - no prepared statements, mysql_escape_string) vs. an environment where the obvious thing, encouraged by the introductory tutorials, is right, I think that the more correct/safer language will encourage programmers to write better code.

But reading the comments here and on Jeff's post, it is humbling to remember that people are using it, every day, to build more and better software than I ever have. I may have a visceral dislike for the language, but good programmers are able to do good work even with a double-clawed hammer.


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.


For Ruby there's Passenger/Ruby Enterprise Edition, which is simple to setup IMO, but it's stuck on 1.8.x, AFAIK...


Since lately folks have been attacking the people instead of their arguments I also have to preface my comment.

I am a full time Rails Developer. So here we go...

If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option.

That is the crux of this whole debate summed up in one beautiful sentence. I almost cried.

Until someone builds a better solution, where better includes as easy or easier to setup on than php. Php is going to be the defacto standard.

And for the love of God please don't say well all you have to do install Blub then configure foo server and...

You've already failed to be easier to get started on than with php. And if you want php to go away you have to do just that.

Where do I install Blub? What happens when there are 30 different servers that can run it which one do I pick? Why? What are the trade offs? Version Y is on the website but everyone really uses version X because the the dependencies haven't been up dated to Y yet. And the major framework just had a huge fork/merge/catfight and now its future is uncertain ...

Fuck it I can pay Shithost $5 a month for php and I can toss a few variables in this html <insert wysiwyg editor> crapped out.

Your average person who needs something to show up on a website

and lets be very clear if you want to see php go away these are the people you need to go after

does not care about: - lambdas

- good language design

- namespacing etc,

they don't read Jeff Attwood, Hacker News or any of that.

One thing the php community as a whole has always focused on is ease of getting started. Take Wordpress. The 5 minute install? That gets up an running an allowing me to do what I care about (getting my client's content on the internet) I still use it long after converting to other languages for most development.

If you can't compete with that it does not matter how many templating languages or css precompilers or what the hell ever you got. You don't stand a chance.

TL, DR: Long Story Short. php and its children make it easy to drop in and play. Thats what you are up against. Not language design beauty/ purity or features. Ease of getting started.

Because honestly the only people who care enough to switch are people who care enough to overcome that in other languages.


We get it, you don't like PHP. Don't use it. Nobody forces you to use it... If someone does, it's most likely a client, and that's nobodies fault but your own for seeking clients that want PHP work done. And if that's the case, you shouldn't be scolding PHP for keeping food in your mouth and a roof over your head.

But yes, we get it, you don't like it. Move the fuck on. These "This is what's wrong with PHP" articles are starting to get redundant... Everyone shouting in to a empty cave that nobody cares about.


I agree with Killswitch. Stop talking crap about other languages and create something awesome with what you know!


He's really one to talk.... ASP.NET is so amazing, right?


> ASP.NET is so amazing, right?

ASP.Net MVC version 4. Yeah, actually I'd say that it is. But YMMV. All I'd say is avoid commenting on frameworks that you don't know much about.


All languages have their purpose, use the one you want and prefer. I'm getting sick of people bashing other languages because they don't like it. Especially people who have never really used the language...


Ok, so here it goes. I haven't commented on this site for over a year.

Full disclosure: I am an average programmer compared to many here. I come to this site to improve my self and read about what brilliant and amazing things you all do. Now you have a reference.

I use PHP on a daily basis, have been for years. I am a freelance developer who has been able to carve out a living with a lot of hard work and a lot of luck. I just met the right people at the right time. Over the last 7 years since I started developing professionally, I have seen nothing but people shitting on PHP constantly. I am in no way suggesting PHP is a perfect language, but I still never get the hate. It just seems so ivory tower to me sometimes. Let's look at reality.

I'm starting a small project for a client. They are keeping track of all their scheduling and doing all their reporting in excel. They want to move this to the web with basic security so the right people can see the right information with ability to access it from anywhere. That's it. You know what works for that? PHP does. It works fine and it works on almost any server in the entire world with no issues. I don't need a .vimrc file with a million special configurations, I don't need a hot new framework where my time is spent figuring out how to do basic CRUD operations, it won't matter if PHP is statically typed or not, it won't matter if... you get the idea. I just need to start developing and getting this project done so this business can start saving time and money. That's what matters most to me.

PHP works, and it works damn well for millions of situations every day. No one is suggesting you use PHP to build a super computer. If your project requires something different than use something different. PHP is not the "Nickleback" of programming. PHP is useful. PHP is practical. PHP is easy, and that's not a bad thing. Facebook, the biggest site in the world, uses PHP. Think about that.

Finally, let's use his tool analogy. PHP is a double-clawed hammer. What if your job was to remove nails from wood all day? What a wonderful tool a double-clawed hammer would be! You wouldn't have to worry about which way the hammer is facing! That would save you real time and real effort. It's the right tool for that job. Tools are about how you use them. If someone uses a tool incorrectly it's not the fault of the tool.

PHP can use improvement. Every language can. I imagine a meeting of otherwise incredibly smart people sitting around in smoking jackets and sipping fine brandy standing around with smug smiles on their face. "PHP is horrible!" One will say. "Hmmmm... Yes... Quite..." A small laughter emerges. They all pat themselves on the back and enjoy their intellectual circle-jerk. All the while countless developers are using it every day for the right reasons making real applications that help real businesses save real time and real money. Laugh at me all you want, I get Christmas cards from my clients. They like me just fine.


It's not ivory tower for all of us. In my case it all boils down to simple discomfort. Writing PHP code is painful. Reading PHP code is painful. Fixing bugs in PHP code is painful.

I don't write rants about it but that's just because I left the language behind years ago and never looked back. But if I had to write for my job? Yeah I'd write a rant every other month probably. I would need some kind of outlet for all that pain.

It looks like in Jeffs article his rant was sparked by having to take a close look at php again and all that pain just bubbled back up.


I in no way meant to suggest that any criticism of PHP should be considered 'ivory tower'. I thought I was clear in my opinion that PHP is not perfect. I disagree that writing PHP code is 'painful'. It's perfectly fine for countless developers. Also, again, don't blame the tool for people who use it properly. If you think that it is literally impossible to write good code in PHP than you are being ivory tower.


I never said it's impossible to write good code in PHP. I said it's painful. Don't conflate that with impossible. You may not feel pain when you write it but that doesn't mean other people don't.


What other languages besides PHP have you used? I think a lot of us dislike PHP because we're putting it in the context of better designed languages.


Sorry to respond twice to your post, but I realized this was a great opportunity to learn something. Given my basic example in my post, what language would you recommend I try to accomplish this task? I like to stay away from frameworks so basically I'm asking you to not suggest Rails, however don't be afraid to suggest ruby. If you feel like typing something out, let me know why you suggest it and what advantages it has over PHP.


Ruby. It's the cleanest language with the most sensible standard library I've come across to date. Ruby doesn't necessarily mean Rails, and in fact I'm not a fan of Rails' overly prescriptive paradigm. (As an aside, any time you hear Rails is an MVC framework, discount it because it's really an MVA framework.) One of the things you'll find coming from the world of PHP is Ruby has consistent method signatures. For this and a lot of other reasons you'll almost certainly be happier with Ruby.

Aside from happiness, there are things that make Ruby more powerful. For example, you can cleanly implement the reactor pattern (think: NodeJS) with EventMachine and with EM-Synchrony you can avoid the callback hell that comes with NodeJS.

If you want, you can look at Sinatra to provide the common functionality that the PHP framework provides. With Sinatra you're not all-but-forced to use an ORM like you are with Rails, as Sinatra doesn't include one. If you really want, you can go closer to the metal and look directly at Rack, which is middleware between web servers (Apache, Nginx, etc) and the actual application.

There's really no right way to do it, but the best thing is to learn and explore. Some people will recommend Python, and while it's a decent language, it's got some things I consider to be rough edges -- lack of useful language features, such as switch/case statements, and badly implemented parts of its standard library that handle network requests.

The next language on my learning list is Go. I've heard nothing but good things about it, but I'll reserve my judgment until I have some experience with it.


I'll second Ruby because of Sinatra and add some of my own thoughts. Sinatra is a very gentle introduction to separation of concerns. You can get a Sinatra app running on a shared Dreamhost with the same effort as a PHP site.

PHP was ok for me I spent a ton of time looking up functions in the docs but I could get stuff done. Once I had to edit/work with 3rd party code it was a nightmare.

I've developed in PHP, Ruby, C#, Java, ActionScript, and Python and Ruby's gem system is by far the easiest package management system I've used. Making your own gem is really easy.

Great ideas seem to pop up in Ruby first and then are ported to PHP, so why not use the original (see Rails, Cucumber, Bundler).


Thank you for taking the time to write this. You have sufficiently peaked my interest. My next personal project will be done in Ruby.


>My next personal project will be done in Ruby.

Here's a better idea. Take a very simple problem - say user fubar enters his name, you say "Welcome, fubar!", populate a backend database with his name because he's a new user. Otherwise you tell him "Welcome back, fubar!" and don't mess with your database.

This involves what ? Handling a GET, making a database insert, doing a select on name in a database, that's it.

Now go do this in atleast 5 frameworks, and time yourself. PHP obviously, but do try RoR, Django, Play2, JSP and ASP.NET

I actually did the above exercise and came away with a lot of valuable insight. In my case Play2 was a breeze because on Heroku its trivial to set up, and each GET xxx request mapped directly to a xxx scala method in the Controller, so no magic. The others were a little more painful, but not a whole lot. I enjoyed the exercise.


The only trouble with this is that trivial applications tend to only give a superficial feel for the framework and aren't representative of a "real" development experience. For example, I wrote a trivial application in Flask. Python's Flask, while it looks great on the surface and has fantastic documentation, rapidly becomes unwieldy in the face of more complex problems. The same is true for Ruby on Rails.

Most frameworks almost feel like they're tuned to solve these basic problems and give a fantastic first impression that doesn't sustain.

Developing a complete project in each is a better way to move forward IMHO.


Good luck! One of the best books I found for Ruby was The Well Grounded Rubyist by Manning Publications.

Also, s/peaked/piqued ;-)


Just try something. I don't doubt that PHP has its good points, but how can you appreciate them without having something to measure them against?

Ruby or Python would probably be the best choices if you don't have anything else in mind.


I've played around with Python and Ruby (more specifically rails), nothing serious though. I enjoy trying new things, but never found them worth delving into for my purposes. I 100% admit this a reflection on me and not those languages. I have nothing bad to say about them. I just didn't find anything in them that was worth switching.


Unfortunately what many would define as 'better designed' doesn't always translate to useful software.


Can you give an example?


Any major websites done on Lisp, Smalltalk or Haskell?

Besides Viaweb?

Now count > 1m visits per day websites done in PHP.


You're measuring the success of a website in terms of traffic.

The number of hits a website receives isn't the product of the language it's written in, but primarily a function of its marketing (and other factors that appeal to its users).

There are also more websites with their foundations in PHP, so it's reasonable to expect a higher number of successes. You can't therefore logically conclude that the language influences success. It's like comparing the number of millionaires in the US with the number of millionaires in Canada; the US has a bigger population compared to Canada, and all things being more or less equal, it's reasonable to expect that the US would have more millionaires simply because of its shear size.


>You're measuring the success of a website in terms of traffic.

Yes, me and all Analytics and SEO guys. You either sell ads or stuff. In both cases you want as many eyeballs and wallets as possible.

>The number of hits a website receives isn't the product of the language it's written in, but primarily a function of its marketing (and other factors that appeal to its users). There are also more websites with their foundations in PHP, so it's reasonable to expect a higher number of successes.

Yes, but your logic is circular. The question is WHY are there "more websites with foundations in PHP", and not just trivial amateur personal stuff but highly successful ones too.

You seem to assume PHPs expanse as just a fact of life, totally arbitrary, and thats why you say we must not draw conclusions based on it.

>You can't therefore logically conclude that the language influences success.

Sure I can. Here are some ways:

- Php is easy for newstarters, so got more adoption. - Php is trivial to deploy, so got more adoption. - Php was there, targetting the web specifically (with libs and features), in 199x, while Haskell, CL, what have you were not yet. - Php, because of the above, had amassed a huge ecosystem of projects and engines (Nuke, Wordpress, Drupal, EE, etc). - Php, because of that, has alo got huge adoption. - Because of th adoption it built a huge ecosystem of programmers, projects, tools, books, etc.

And, putting it all together, what makes PHP more likely to power most high ranking sites, is that you can easily find components and engines to base your site on, AND you can easily find tons of programmers to employ, AND you can easily find support for it, etc. All those make it a no brainer for a lot of uses.

And all of those are interdependent, based on some initial language attributes, not arbitrary like the US vs Canada population argument (which is not that arbitrary and size based itself, but thats another story)


> You're measuring the success of a website in terms of traffic.

I wasn't disagreeing, and in fact I didn't even express an opinion regarding this. Success means a lot of different things to people; I was stating your definition of success for clarity.

The user doesn't care whether I write a website's back end in PHP, Ruby, Python, Haskell, C++, Ada, Clojure, or even Erlang. The success depends on how useful the site is and how well it's marketed. This isn't circular reasoning.

There are more websites written in PHP because PHP is an easy language for beginners and therefore more common compared to Ruby or Python, for example.

It's an absolutely untenable position to assert that the programming language itself affects how much traffic an site receives, which is what you originally defined as "success".


>I wasn't disagreeing, and in fact I didn't even express an opinion regarding this. Success means a lot of different things to people; I was stating your definition of success for clarity.

Oh, alright. Thought you meant it was not a good metric.

>The user doesn't care whether I write a website's back end in PHP, Ruby, Python, Haskell, C++, Ada, Clojure, or even Erlang. The success depends on how useful the site is and how well it's marketed. This isn't circular reasoning. There are more websites written in PHP because PHP is an easy language for beginners and therefore more common compared to Ruby or Python, for example.

Yes, that second argument is not circular reasoning because it searches for the causes.

But the argument in your previous post, I read it as: "PHP is used by more of the popular sites because PHP is used by more sites in general" Which is kinda circular, mostly repeating "PHP is popular".

>It's an absolutely untenable position to assert that the programming language itself affects how much traffic an site receives, which is what you originally defined as "success".

I did the opposite: the success of the site affects the programming language.

That is, I am a pragmatist: I see every successful site built with a programming language as one more verification that said language is good for building sites with (whatever the reasons).

If we have 200,000 high volume sites in PHP and 0 in X, as a pragmatist, I will avoid using X in my next high volume site project.

Working from that, one can also see why it is so. For example:

1) it's because X is obscure, so I wouldn't be able to get a team easily. Perhaps even no one in my city, at least without adding the overhead of teaching them X first.

2) it's because X is more expensive to host. I'll need to get a VPS whereas I can just put PHP on a $10/year server.

3) it's because PHP has more libs and stuff. This DB/service API/etc I want to use does not have X drivers (or has a semi-abandoned project).

4) it's because PHP has Drupal/Wordpress and I can have a high traffic portal/news style site in minutes, whereas X has only ho-hum solutions for that, or I would have to build one from scratch.

and so on.

Surprisingly, many so called "scientists" and "engineers" choose to argue from first principles. "X is a bona fide academic language, and has all those meta programming features, higher-order types and such, so you are crazy to use PHP over X for your project".

So, instead of reading the situation pragmatically, and finding the real pain points PHP eases and why it's used, they resort to idealistic rants about how masses are ignorant, "beating the averages", etc etc.

Well, this Zuckerberg guy, with his average PHP, beat Viaweb's Lisp by about 100x better valuation. If, according to "beating the averages", ViaWeb's success was a pro-Lisp point, why isn't that a pro-PHP point? Or does it only work when Lisp wins (as in, "ViaWeb won because of Lisp but Facebook won despite of PHP"). Talk about having it both ways!


> But the argument in your previous post, I read it as: "PHP is used by more of the popular sites because PHP is used by more sites in general" Which is kinda circular, mostly repeating "PHP is popular".

You misread what I wrote in that case. I said "There are also more websites with their foundations in PHP, so it's reasonable to expect a higher number of successes." This isn't circular reasoning, and let me show you why:

Lets pretend I'm superhuman and create 10,100 unique, high quality websites in one day. Let's assume also that my skill and experience remains constant throughout building these 10,100 websites; I'll get no better at marketing, design, etc and all my decisions are of equal quality. The only difference is the programming language I use to develop some of the sites.

For the sake of this example, let's assume that 1% of websites created, on average, end up with one million page views per month after six months.

In this fictitious example, let's say that for grins I build 100 sites in Lisp and 10,000 sites in Perl. 1% of my Lisp sites will be successful (a grand total of one successful site) and 1% of my Perl sites will be successful (100). From this data you're erroneously concluding that Perl is more likely to result in a successful site. This is wrong, because the number of sites created in each language varies wildly, but the odds of hitting "traffic gold" are still 1% with everything else being equal. The language, therefore, doesn't impact success rate.

Seeing something built in PHP doesn't make it a good choice, just a common one, just like smoking in the 1970s was a common choice, just not a good one.

Facebook, while it's mostly written in PHP, is actually transcompiled to C++ (HipHop compiler) because PHP was insufficient. They're not actually running any PHP code in production. Also I keep hearing that their codebase is an unholy mess and that the only reason it hasn't been re-written in another language is that the codebase is just now too big to rewrite. Zuckerberg wrote Facebook in PHP because it was the language he knew, not because it was the best tool for the job. Marketing and user experience made the site successful, not the language.

Don't just look at PHP and say "huh, it's common!" and conclude it's good. It just doesn't make sense and it's a logical error to do so.


Amazon.com was famously put together by mostly Lisp engineers. They more recently switched to C++ and apparently experienced a lot of growing pains as they had to learn how to scale up C++ to match what they had been doing in Lisp for years.


> Any major websites done on Lisp

Does Hacker News count?


Note the use of the word "major"


Note the use of "true" in "no true Scotsman".


Note that I specifically wrote >1m visits per day.

Note also that the mention of one site is too literal and meaningless interpretation of my question, which is more rhetorical, and should be read like: "There are TONS of high volume PHP sites and very very very few high volume Lisp sites".

That said: the "no true Scotsman" logical fallacy is only a fallacy half of the time, like most of those so-called logical fallacies.

They assume a perfectly logical world, where you have infinite information at your disposal and infinite time to check it. E.g I'd rather listen to my doctor on my medical condition over a random guy on the subway, even if that's "appeal to authority".

Similar cracks in the "no true Scotsman" fallacy. There ARE cases where a category/taxonomy is used badly, and no true member of said taxonomy would so something. That is, membership in a taxonomy is not always 100% solid, and you can have true and less true (fuzzy) membership.

E.g

- No KKK member would attend a NWA concert. - But I just saw a KKK member rocking it at a NWA concert. - Well, no _TRUE KKK member_ would ever attend one.

It's obvious that the first guy is correct: no TRUE KKK would ever attend a NWA concert.

Now, a random KKK member could possibly attend one (say, out of curiosity). The "no TRUE" argument in this case, says not so much the impossibility of an event happening, but that it is against the very concept of the taxonomy under discussion for it to happen.

Hackers shouldn't touch the "logical fallacy" stuff with a ten foot pole. They presuppose that conversations and argumentation can just go "by numbers", without examining each individual case.


Haskell


Way to talk down to people.

I use PHP as my main language for web development, but also am a frequent C user. I have done projects in C# and Python.

While I like C# and Python - actually for scripting I tend to go for Python rather than PHP, prefer the CLI modules of Python- , I found that in context of web dev PHP still get the job done faster and in a maintainable manner. As for C, I use it for writing PHP extension -or generally fucking around with PHP source code- and writing non web stuff, so not as relevant.

The difference between people like me and people like you, is I don't go around constantly mocking other language. It is pointless, I'd rather spend my time and energy delivering products, or actually doing something productive.


I'm not talking down to anybody.

Based on experience I asserted that many programmers feel that PHP is an inferior language because they've experienced "cleaner" languages such as Ruby. It's not wholly unreasonable that chez17 had only programmed using PHP, as PHP is commonly a programmer's first language. I therefore wanted to find out if chez17 had used other languages and to see what their thoughts are on PHP vs those other languages.

I also don't go around "constantly mocking" other languages. Why did you make that assumption?


Good, just the way it read.

As for constantly mocking other languages, that was not directly pointed at you, but at the constant swarm of people always going about php sucks, php this, php that... We got it, you people don't like PHP, try to see if I care.


Why shouldn't engineers "mock" the things that they think are badly designed? But by "mock" I mean criticize. In fact, as an engineer, it's one's professional duty to criticize bad design, as good design is essential to the endeavor of engineering progress.

Good engineering design vs bad engineering design is what prevents bridges from collapsing or Mars landers from crashing.

But I hear you: sure it's quite possible to do arithmetic using Roman numerals, and if that's what you're used to, you probably don't want to hear that you've been doing it suboptimally. And all these people clamoring for a change to decimal are just an unbearable nuisance.


"Finally, let's use his tool analogy. PHP is a double-clawed hammer. What if your job was to remove nails from wood all day?"

Brilliant.


>Brilliant.

Except that, if you're removing nails, there are much better tools than the claw on a hammer. [1][2] I've done demolition, and I've had to pull a lot of nails, and the claw on a hammer is about the last tool I'd use for the job. I basically only use the claw to straighten or remove a partly-hammered nail that's gone wrong.

So yes, the analogy is brilliant.

[1] For really big nails, more leverage is good, and the hole in the flat part can be used to pull longer nails out than you can pull with a hammer claw: http://refer.ly/abwW

[2] To get a nail started, something sharper with points, and that (here's the important bit) can be HAMMERED under the nail head: http://refer.ly/abw2


Not brilliant. You can use a regular hammer just fine to pull nails out of wood all day AND to nail the occasional one in should the need arise.


Pulling nails all day long with one side will quickly wear off that side - it won't be as sharp and you'll have to throw away the tool. Double claws will allow you to use the SAME tool twice as long (that's 99% of what you do, remember?), will avoid rotating the hammer 180 degrees in certain situations (constrained space, two nails - one on the left, one on the right) and you get to hammer an occasional (1%) nail with the side without changing tools.

I think the original analogy was indeed brilliant, given the context.


As someone who has been hammering nails and pulling out nails for the past 8 weeks, I can assure you that hitting them with the side of the hammer is a very, very bad idea.

Also, you never find yourself in a situation where you're just pulling out nails. A large number are too difficult to pull out, or will damage the structure you're pulling them from, so you hammer them down.


But it would take you longer because you would have to turn the hammer on occasion. You would also have to consider an additional failure scenario where turning the hammer caused you to drop it.


IOW, the double-claw "hammer" is just what you may need if your job is to pull nails out of houses that are unsafe because they were built by carpenters who used double-claw "hammer"s to hammer in the nails. Got it.

The analogy is almost perfect! Except that PHP doesn't pull out nails very well.


> It just seems so ivory tower to me sometimes.

More like a game between different sports teams. Are you going to go to the fans of the opposing team for an honest opinion about yours? Are you shocked they have nasty things to say about your team? Or that you have nasty thoughts about theirs?

What gets to me is this air of objectivity ... that part is most certainly ivory tower and is arrogant to boot.

What I want to read is a critical article on PHP by somebody who uses PHP and loves it. That would be useful.

A hit piece by somebody on a Microsoft stack is just boring!


The setup time issue is an advantage of PHP over many languages. But, I will let you in on a little secret, once you know how to do it 'setup' time is a drop in the bucket on all platforms. And in the rare case where it might otherwise be hard, people setup a shell environment they can use as the template on any project and it just works.

That said, there are popular languages worse than PHP for most web development tasks, Java for example.


PHP will always have an edge. If you want to do something stupidly simple, no other language can match.

    <?php
    $hackernews=file_get_contents("http://news.ycombinator.com);
    $hackernews =str_replace('Hacker','Interwebz',$hackernews);
    echo $hackernews; 
    ?>
Now that's horrible code, it has a dozen bugs aside from the security issues, but I would go so far as to say when I need to do something stupid like that quickly, nothing matches the simplicity of PHP. It's downright elegant.

Not to say you should write a webapp in it, but I think you're wrong; there's intrinsic overhead in using a Real Language. It has nothing to do with "knowing how to do it," doing things properly takes time, a half-assed but mostly functional solution can be whipped up in minutes.


> Now that's horrible code, it has a dozen bugs aside from the security issues, but I would go so far as to say when I need to do something stupid like that quickly, nothing matches the simplicity of PHP. It's downright elegant.

So:

* It's horrible code

* It has bugs

* It's not secure

...

* It's downright elegant

See the discord there? It's not elegant at all. It's easy, but easy != elegant. It's just easy.


It depends on the problem domain. I've seen PHP pretty similar to what I just wrote that worked without complaint. In some circumstances, great, bug-free, secure code is over-engineered and inelegant.


  require 'net/http'
  puts Net::HTTP.get(URI.parse('http://news.ycombinator.com')).gsub('Hacker', 'Interwebz')
I'm confused. Where's the edge?

Or, even simpler,

  require 'open-uri'
  puts open('http://news.ycombinator.com').read.gsub('Hacker', 'Interwebz')


I knew I was going to get some code golf responses.

Simple and short are two different things. I value PHP over Ruby here because it's much clearer to the layman what's going on. To explain the PHP, all I have to explain is functions, variables, and the echo statement.

To explain the Ruby, I have to explain functions, variables, Objects (everything is an object), Libraries, I/O, and method invocations.

Also, in classic code golf form, your code eliminates a couple things that will make it do exactly the same thing as the PHP - you're missing your #! line, and you're not actually writing a CGI script, which is a second library you need to include and explain to your hapless newbie. And honestly, it's not just a newbie thing. I've written Ruby similar to that (with good error handling, etc.) Ruby only makes sense if you're going to do the job properly and put in error handling, etc.


And to Jeff Atwood's original point, you cannot copy-paste the file onto basically any http webhost on earth and have it run out of the box. I don't think that's appreciated in the threads thus far, is that web hosting companies have really done a lot of work for you for PHP and Perl that you have to do yourself with other web programming platforms. They might be better, but they aren't as universally available and supported. (For some value of "supported" which is usually "enough")


That was one point in favor of PHP, and it was a small one. I'm competent enough to set up any environment if the project required it. However, some hosting companies won't even let you do that. A client might have purchased a small package that won't even let you ssh in to do anything. That's a real life scenario that you have to consider. PHP works there.


Bash is another example! I've always wanted to create a web app using Bash on Balls [1]

[1] https://github.com/jayferd/balls/


"I don't need a hot new framework where my time is spent figuring out how to do basic CRUD operations"

Definitely see what you're saying but the flip side is that in my experience once you figure out the basic CRUD operations in a good framework, the amount of time it takes to implement them decreases hugely compared to repeatedly writing boilerplate in PHP.

Being able to get something functional up and running extremely rapidly was exactly what caused me to move most of my projects away from PHP although it would be fair to say I didn't give the corresponding PHP frameworks much of a chance as I had other reasons for wanting to consolidate codebases into either python or ruby and I hear Zend, Symfony and various others have come on a long way.


"Finally, let's use his tool analogy. PHP is a double-clawed hammer. What if your job was to remove nails from wood all day?"

I agree with your metaphor relating working with PHP as "pulling nails from wood all day."


Zing!


I am willing to bet that the reason facebook uses PHP is to remain backwards compatible.


There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Bjarne Stroustrup


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.


Mr Atwood says "One of the explicit goals of my next project is to do whatever we can to buff up a ... particular ... open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment. "

But which open source language ecosystem? Is he talking about mono? ruby? python? erlang? something else?

Either he thinks it's obvious what he's talking about (hint: it isn't to me) in which case it's probably mono; or he's being deliberately coy and holding back for a big reveal later.


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?


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.


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.


>Raw PHP usually beats Rails handsdown, and most PHP frameworks are usually comparable

Being able to keep up with the slowest competitor in existence isn't very good.


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.


"You can't do: $something->doStuff()[0]"

Yes you can.

"Speed"

Care to expand on this one?


"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.


Did not know this!


PHP has array dereferencing, closures, and array short syntax since 5.4.

  $func = function() { return ['a', 'b', 'c']; };
  echo $func()[0];


Nice to hear that they fixed those.

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.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: