Hacker News Reader

Comment by polemic | Hacker News Reader

Note that this is a response to:

EDIT: refer https://twitter.com/#!/codinghorror/status/18957165652253491... - Jeff's 4 year old response is still valid.

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Jeff gets it right - the language is poorly designed, but it hasn't stopped PHP powering many of the biggest most important sites on the internet today. Banging on about the language's flaws [again] is not very interesting. What would be fascinating would be an attempt to understand why PHP remains so dominant despite the well-known flaws.

Seriously - http://stackoverflow.com/questions/tagged/php throws up so many pearls of WTF that you wonder how PHP could possibly be so important. And yet!

Time to stop the PHP bashing. It's like comp.lang.js complaining about the flaws of jQuery (and, indeed, any JS library) and expounding the many and various reasons you should never use a third party library. The reality is: when the keyboard meets the road, stuff has to get done, and these are the tools that seem to work.

View on HN

This is the wrong way to think about it. Just because people can hop on one leg across the finish line doesn't mean that's a smart way to run a race.

Ask yourself this: would the Instagram team have been as successful had they chosen PHP? I think not.

Javascript is different because we're stuck with it for historical reasons but there are so many better choices on the back end that there is absolutely no excuse to start new work in PHP. Similar negligence would be considered unprofessional in any other engineering discipline.

  > Instagram team have been as successful had they chosen
  > PHP? I think not.

Can you elaborate, why you think so? PHP worked OK for Facebook and Wikipedia.

The time you don't waste fighting with the language and coding around its deficiencies is time you can spend improving existing features and adding new ones. If you're trying to run a lean startup with only three backend people like Instagram these effects are very important. Those three engineers could have coded something similar in PHP but I'll guarantee you it wouldn't have been as good.

Facebook can afford to throw money at the problem and nobody's really trying to compete with Wikipedia so they can get away with it.

I've developed large applications in PHP for years. Currently we're using other languages at my current company for a couple of reasons. They could have coded the exact same thing in PHP and I doubt it would have taken them any longer. The language isn't great but I never found myself truly fighting it just displeased with some of the syntax.

Facebook started with PHP they weren't always the massive company they are today and managed to displace other entrenched social networks.

Time savings? How's downloading the entire feature set for content creation, categorization,user management & authentication, and menuing in 45 seconds stack up to arsing around in a text editor setting up your file structure for a new development project?

  > fighting with the language and coding around its
  > deficiencies

That's still too vague. Sure PHP has it warts, but I don't recall anything I could call "fighting with the language". Yep, stack/needle mess and inconsistency in naming is annoying, but not exactly a huge time waster.

> Facebook can afford to throw money at the problem

Aaah the good old circular reasoning of dismissing the big guy - they did get big enough to be able to afford money by using PHP too you know.

This sounds very much like the new version of "I can tell it's a rails app by how it looks".

The idea that the server tier language has a direct effect on the user at the level of code quality we are discussing is naive at best and trollish at worst.

Are you seriously arguing that all backend languages are essentially interchangeable?

Give competent team A six months to build something in PHP and competent team B six months to build something in any of the better options and team B will build a better product every time.

Do you have any evidence to back up this assertion?

Because I would imagine it depended a lot on the skill of the teams in question - and if evenly matched they would produce similar quality.

What in the world does language in which the site was made in has to do with success? They were never acquired for technology - in fact, go read about their setup on HA, it's very standard stuff.

If you build a product that gets traction and solid user base with some viral aspect in step 2, you will sell - even if your app/site were made in QBasic.

This kind of careless, selfish attitude really pisses me off. If I walked into a doctor's office for an operation, saw a tray full of old rusty instruments, was told by the doctor that they were "good enough" and that I should just worry about the result then I would not only walk out of that office but also file a complaint with the hospital.

If you're selling your services as a professional to clients you owe them the best work you can do. There are legitimate reasons to prefer Python or Ruby or Scala or whatever but if you're just too damn lazy to stop using PHP then you're essentially guilty of professional malpractice.

Are you serious? PHP is not "tray full of old rusty instruments". Please give me one concrete example what is wrong with a blog running on PHP. Or a small store? How is the END result differ between say Magento or something running on Django? Could you tell the difference? No, you could not. And while the PHP version would have been up and ready, you would still try to figure out how to properly run WSGI server in shared hosting.

Good luck with your endeavors.

> PHP is not "tray full of old rusty instruments".

Clearly that's a matter of opinion.

> Please give me one concrete example what is wrong with a blog running on PHP. Or a small store? How is the END result differ between say Magento or something running on Django? Could you tell the difference? No, you could not.

I think I could, pretty often at least:

http://duckduckgo.com/?q=wordpress+%22hacked+by%22

Right, because no other language is hackable.

https://github.com/rails/rails/commit/b83965785db1eec019edf1...

Should languages be required to ensure the security of the code produced for them?

IMHO this is more of a complaint about the security of Wordpress, not the PHP core. People love to bring up phpBB or Wordpress in these discussions, but there are many, many more systems using large-scale PHP about whose security you just don't hear, because they are coded by professionals who know how to produce secure code in PHP.

Or your clients find it easier to find suitable PHP developers in which case you are doing them a disservice using anything else.

PHP isn't a good language but it's not so bad to be unusable. I think you're really overstating the problems with it.

Someone's being a little too serious for his own good. Every language has its quirks, pick your poison. In the end, the idea that is realized is what matters.

Also... how did you draw a relationship of PHP's quirks to rusty old instruments? Is C++ pretty much dust then?

You're missing the point.

PHP works. A priori arguments from faults in the language don't explain its success. Replaying that old record doesn't add anything to What We Already Know.

Also: I didn't say that Javascript is different - I'm talking about the curmudgeons in comp.lang.js who argue that the practical benefits of using a JS library are outweighed by their flaws. This is clearly dis-proven by their popularity and demonstrable economic benefit. As for PHP, this remains true.

I know why it's successful.

I remember when PHP was becoming popular. It allowed for inroads to code from front end designers who hated coding in Flash at a time when academia-based Java people were running all the big websites. If you wanted to hack up and put up a website, you can do so in a few minutes with a LAMP stack where a Java stack needed some lessons in Java.

Same is pretty much true today, but it's 10 languages instead of Java.

You know, Java was the same way. It was originally made in the 90s as a language made for embedded devices (toasters, refrigerators, etc). No one expected it to be a web language.

But Java offered something that was attractive to C++ coders: garbage collection. that made learning the language a lot easier. C++ people joked about Java never becoming popular. It crashed a lot! (core dumps - a common issue in PHP)

PHP reminds me a lot of what Java was 10 years ago. It's not as well put together as Java was. And it too took about 8-10 years to introduce templating.

My point:

1) PHP is popular because it has a more welcoming barrier of entry into coding.

2) PHP's problems appear the same to me as Java's problems 10 years ago.

That's all. Not saying one is better than another. Use whatever the fuck you want. I use both so as long as my employer pays me. Tell me to code mindfuck and I will. As I get older, I think I hate them all.

> Tell me to code mindfuck and I will.

I believe you referred to brainfuck, just for the record.

> As I get older, I think I hate them all.

There is some deep pessimism in the software world that I feel constructive.

When engineers talk about how much they hate the tools even they don't have to use, I think it shows the care they have toward the profession.

It's the same reason people in any field put down things - they like to feel superior by putting down the tools that others use, thereby increasing their own relative stature.

There's also a "familiarity breeds contempt" angle.

I hate people who put down people. They're assholes and stupid.

Just kidding dude. I was just joking when I said that. I love coding. I'd fuck a node.js program and even let XML lick my balls at the same time.

On the other hand, you can generally complain the longest about the things you know the best.

Bahh.. Don't be so patronizing. I'm a nerd dude. I was joking when I said I hate them all. I'll fuck Java and PHP in a 3some if given the chance.

I'm saying as long as I get paid I'll do the job because I'm an hourly coder (pays more, have mouths to feed). I do plenty of "fun" work and open source work.

I remember that PHP became popular because of mod_php. If you wanted to script a web application on Linux or UNIX your choices were either Perl with CGI or a much faster PHP with mod_php.

It was incredibly easy to setup both in production and for development - hence the LAMP stack and the thousands of cheap shared hosts that had PHP enabled, which lead to a lot of pre-install applications being written in PHP.

Other web applications only recently became easy to install, and they didn't beat 'ftp into the site and drag files over' until cloud platforms and virtualization.

They still haven't beaten PHP in ease-of-deployment. I've been writing for the web in Python for 2 years. Deploying your own server is a full-time job.

The only thing that's getting better is that things like Heroku now exist. Heroku makes it insanely easy to deploy Python, compared to deploying on your own server. It's still harder to do than FTP + copy files, which most people know how to do.

"(core dumps - a common issue in PHP)"

Ummm.... I've been working with PHP for 16 years, and I could count the number of coredumps I've had in production on one hand (maybe 2). Early on, when compiling extensions by hand, I'd get some when I compiled something wrong, but that was always in test areas on dev machines.

If 'core dumps' were 'a common issue', I doubt it would be as widely used as it is now.

Bahh.. it was at where I worked. It was because we relied on C libraries that PHP connected to. When PHP is slow, they make links to C libs to get speed. Java did the same with JNI. PHP simply isn't fast enough in some situations where C libs are necessary to hook up with. (private message me if you disagree.. I'll be glad to go into details)

We were typically getting up to 200 req/second on our stack. So it was pretty heavy traffic to begin with. We solved the core dumps though. And the java core dumps were for the same reason (necessary to connect to JNI).

Sure... when dealing with custom C code and hand-rolled non-vanilla PHP, I can see that happening. Understand that your experience was in the realm of the .01% of PHP usage. 200/req second isn't all that outrageous for run of the mill PHP (depending on hardware) but when you're throwing in custom connector stuff on top of that, yeah, you'll get core dumps. :/

That's all I said though, is that it reminded me of my Java years.

And yeah, connecting to C libs is commonplace in large PHP places. In fact, that's how PHP gets a lot of it's work done to be quick. Your ".01%" is a number you're throwing out of your ass and you know it.

I'm not surveying PHP usage, merely telling my experience. If you work on a website and need to connect to an external system that only has a C lib, guess what? You're going to connect using C libs.

"there are so many better choices"

This is absolutely true, assuming you're working on a blue-sky project or some niche purpose-built app. For the rest of the web, other available languages are (currently) missing one or more of the following:

- A wide selection of CMS's to choose from

- A wide selection of CRM's to choose from

- A wide selection of development frameworks to choose from

- commodity hosting environments ready to roll with little or no server configuration required

Declaring the choice of PHP over some other back-end language negligent in all cases is misguided.

I would have thought Instagram would have been popular no matter what they used. People liked the product and functionality. They don't give two hoots about what is powering it.

Ask yourself this: would the Instagram team have been as successful had they chosen PHP? I think not.

Why not? You do realize the "team", facebook, that acquired them (worth many multiples of them at the time of acquisition) is a PHP-based company right?

The interesting thing to ask should be if Facebook or Wikipedia's engineers would use PHP if they had to start from scratch. I used PHP for a big project before for legacy reasons but I wouldn't choose it for anything new even with a machine gun pointed to my manly parts. Neither would I use Java or VB for that matter.

Facebook and Wikipedia (and Wordpress) were born outside the software engineering establishment using lowest common denominator tools [1]. There's a reason for that: LAMP/WAMP has an extremely lower barrier to entry. A billion monkeys banging away on typewriters can make world-beating products, even if they don't compare to the works of Shakespeare in terms of literary quality.

Once these products prove themselves in the market then "professionals" are brought in to handle them, and these people probably know and like more refined tools such as Python or Java or something. It doesn't matter what language these new caretakers would choose for a rewrite though; PHP gave their system its first breath and that's how it stays long past the point in the lifecycle where PHP is a competitive advantage.

[1] http://en.wikipedia.org/wiki/MediaWiki#History

Pretty sure they would agree. The Quora and Asana founders seized on the opportunity to leave it behind, and what I've heard from Facebook staff is that they've managed to live with PHP. I can't remember anyone saying they like it.

http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choo...

Our main takeaway from that experience is that programming language choice is very important and is extremely costly to change.

Taken directly from the horse's mouth, handwavy arguments about languages making no difference to the contrary.

Ask yourself this: would the Instagram team have been as successful had they chosen PHP?

They absolutely would.

Building an actual application is a hard problem; a lot harder than the kinks of individual programming languages. Whichever tools you choose it is never going to be an easy ride.

Anyone who has written, deployed or maintained a large scale application of the sort listed there knows this.

It's the step after ranting about how bad X language is.

Building an actual application is a hard problem.

It is. Which is why you can't afford to have the challenges of building something non-trivial compounded by the frustration of working in a broken language. If you're just slapping together another spaghetti CRUD app maybe you don't suffer enough to care.

I wonder if people in other engineering disciplines defend broken practices so irrationally. I suspect they don't have the luxury.

PHP has its frustrations. It's not outright broken.

But my point was that all other programming languages suffer their own "broken" problems. I managed a team working in Ruby not long ago; they had no end of gripes and frustrations.

The key point is that compared to the challenge of building a complex application, those "difficulties" are trivial. And once you are at that stage, anyway, you're so used to the way your chosen language works it doesn't matter.

These are not constraints on what the language can achieve or do and simply require knowing about them so that you don't paint yourself into a corner.

Because application design is a hard problem it doesn't matter, given a relatively skilled team, what language is chosen.

This is identical in other engineering disciplines; a friend of mine works in motor design (electrical motor) and is constantly griping about nuances in the tools and equipment. Same issues.

Recognizing that all languages have their problems is one thing. Arguing that all languages are essentially equivalent in the larger sense is another.

Sorry I just don't buy it. Tools aren't the only factor but they do matter.

I think we're a bit spoiled these days. Five or ten years ago, we didn't have Ruby (or at least a mature RoR), Django, Clojure, or Scala (to name a few), so PHP was a pretty decent option for someone trying to get something out there efficiently. These days, there are lots of interesting platform choices (all with different barriers for entry), so many "serious" developers have moved in different directions.

Ask yourself this: would the Instagram team have been as successful had they chosen PHP? I think not.

Instagram was only succesful (i.e. bought) because they had something (lotsa users' photo habits) that someone with lotsa money (facebook) wanted.

> Ask yourself this: would the Instagram team have been as successful had they chosen PHP? I think not.

I chuckled a little bit when I read this.

I like video games, so I'll make a video game analogy. I'm playing a lot of BF3 right now, so let's run with that. A website called Symthic publishes a list of damage and ballistics information [1] for all the weapons in BF3. They also publishes TTK (time-to-kill) information [2] for all the weapons. With these two pieces of information, it is possible to empirically determine the "best" weapons in the game for a given scenario; that is close-quarters, mid-range, or long-range engagements. Yet I can equip the perfect weapon for a given scenario and still go 2/12 [kills/deaths] -- or worse -- in a round.

No one is scratching their head after reading the above. The answer is obvious. Even given the best weapon, my skills (or lack thereof) relative to the other players in the game result in a net negative kill/death ratio.

Programming languages are no different. PHP may not scratch your itch, but if you collect a group of talented, motivated PHP programmers, you're likely to end up with a working product. The end-user doesn't really care if the application was written with PHP, Python, Ruby, Haskell, Lua, Scala, Java... They don't care. They care that it solves their problem. They care that it makes them feel good to use the product.

In today's development landscape, these goals can be achieved with a staggering number of languages. Some won't look as pretty on the back end, and some may not be as hip as another, but to focus on that aspect is to miss a large part of the point. If you want to build successful software, the tools you use should be mid-pack on your list of priorities.

1 - http://symthic.com/?s=bf3 2 - http://symthic.com/?s=bf3&sb=timetokill

In every field of human endeavor where competition is extremely intense you'll find professionals optimizing their gear down to the last trivial detail. I very much doubt at professional gaming tournaments you'll find serious contestants using anything but the optimal weapons.

Nobody's saying you can't build app X in PHP, but it's likely that your competitor using a better language will get there first.

If you disagree with this, take it up with Paul Graham. The idea that a good tool can give you a competitive advantage underlies many of his essays on startups and software development.

Nobody disputes "that a good tool can give you a competitive advantage". What's at dispute is whether other things, such as skill or tacit knowledge in a field, give you greater advantages than this possibly over-optimized tool selection.

Also, why should anyone take your unproven assertion up with Paul Graham? His essays don't support your insistence that the "better" tool wins. On the contrary, I'd argue PG believes a whole host of factors contribute to success before optimizing tool selection down to the last detail.

> Nobody's saying you can't build app X in PHP, but it's likely that your competitor using a better language will get there first.

This is far more subtle than you think it is. The "speed" at which a team develops has very little to do with the actual language. The amount of time spent writing with the language pales in comparison to the time spent considering how your application will function, how you will structure it, and what you will call everything.

You may find, however, that it is easier to find teams that think in the "right way" in some language communities versus others. IMO, the community of developers that fit this "right way" of thinking (for startups) is migratory, so the answer today might not be the answer tomorrow. You need a team that balances conceptual purity with the pragmatism of results-based decisions.

The speed at which one language can be written versus another only applies in an "all other things being equal" scenario, and these scenarios almost never exist. The big differences in "time to successful solution" will almost always be decisions that aren't related to the language you choose.

The "speed" at which a team develops has very little to do with the actual language.

This is strongly contrary to my experience and extensive reports online. You wouldn't hesitate to argue that PHP is probably at least an order of magnitude more efficient for building web apps than C, right?

So why is it so hard to imagine that a cleaner and more expressive language than PHP might be as much as 2x better than PHP?

> there is absolutely no excuse to start new work in PHP.

I hate PHP myself, but as far as my personal projects go, PHP is perfect for cheap shared web hosting. Some fairly basic and crappy functionality to prevent users from stomping on each other's files is included. Something that can reasonably replace PHP in that role would be what it took to phase it out of my personal use, and what people choose for their own work affects their choices on all work.

90 % of end users wont be even knowing if they used Python/ Django or anything.

> What would be fascinating would be an attempt to understand why PHP remains so dominant despite the well-known flaws.

I've actually put a fair amount of thought into this. I've arrived at the conclusion that it's because it ships with the Big Three parts of any web app in a single package: Request/response handler, scripting engine, and template engine. To the novice, there is no distance between the query string in the URL and the parameters available in $_GET and the ability to write those parameters back to the page via <?php echo ?>. They're all wrapped up in a handy mod_php binary that runs in Apache, and you probably don't even have to do any extra work to get it to run. It Just Works. This has nothing to do with PHP as a language, but it has everything to do with PHP as a web-oriented product. PHP isn't for systems administration, or generalized scripting, or embedding in your game to serve as its scripting engine. It assumes it's web-facing, and that removes a lot of the friction that otherwise trips people up.

What this means is that it's trivial to deploy full-blown applications like Wordpress, phpBB, Joomla, Drupal, and a host of others. They are literally as simple as "unzip this file and go to http://yoursite.com/package. That's huge! As a Ruby web developer, I'm envious of that. I wish I could give people a zip, say "drop this here and unpack it and you're up and running".

PHP is the lowest-user-overhead "make things happen on webpages" language in use right now. This comes with all kinds of downsides which many of us are familiar with here, but PHP's success has nothing to do with the language itself, and everything to do with how easy it is to deploy a full PHP stack itself, and then any PHP application on top of that.

That's a really good analysis. I'm currently mostly using Python, but I've had a lot of PHP experience. Once everything is configured python is a dream, but if I just want to prototype a simple website, it just isn't worth it. Same for the average blog or small scale business site.

To me this signifies a significant hole in the market that competing products could fill. We've already seen that, to some degree, with platforms like AppEngine, but not so much with self-hosted solutions. Or do such things exist? If so, why are they not more prominent?

Another huge bonus for PHP is that a AMP stack is easy to run on Windows, Mac or Nix. The same cannot be said for Rails or Python.

Exactly. To get Python running, you need your webserver, some kind of fcgi/wsgi module or interface running in your webserver, specialized configuration for your app in your webserver, Python installed, some enumeration of your app's packages installed, and finally, your application running.

We laugh at PHP as a giant glob of senseless stdlib crap, but for its purpose as a web-facing product, it works. Users almost never have to worry about installing extra libraries or modules. mod_php means that you never worry about whether or not you have mod_proxy and some fcgi wrapper installed. You don't have to worry about process management.

This doesn't make PHP less of a disaster from a purist's standpoint, but I think it's exactly the things that make it a disaster (gigantic stdlib, no real package manager to speak of, single-threaded, designed to run in short-lived processes and then die off, etc) that make it widely accessible as it is.

I still think there are huge issues with PHP as a language, and I'm long past the point where I'd consider it an ideal candidate for web applications development (because I can deploy python and ruby apps with ease now!), but it has wildly succeeded at hiding all the underlying machinery from the user so that Joe Average can just start scripting his webpages.

Note that Jeff's blogpost is almost 4 years old. Posting this to HN might have been a response to the veekun.com article, but that's not what it was written for…

Thanks, noted.

Reply on news.ycombinator.com