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