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