[bradleyland]

> 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

[cageface]

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.

[Terretta]

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.

[bradleyland]

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

[cageface]

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?