My general point is that evaluating languages based on personal or technical preferences might just be a flawed metric. Unless what you are doing is a hobby you have to deal with additional criteria. I pointed out just one such data points.
I, for example, really love APL. I would also never think of using APL as the basis of a commercial project unless there was an overwhelming reason to do so.
A friend of mine built a nice company around a product built entirely around Forth. He loved the language. And, he lived to regret making that decision. He eventually paid gobs of money to have the entire code base re-written in C. A couple of years later he sold the business for several million. Potential buyers did not want to touch him with the Forth code base. Just a reality of business.
To clarify, the potential buyers were not interested in the Forth code base because they did not use Forth themselves. Acquiring a company whose products were based around Forth would mean adding a new layer of developers to their team and, effectively, byfurcating their efforts and skill sets. A code base written in C was a no-brainier for most interested parties. With C on the table the language was just a check-box item that did not require further discussion. With Forth the discussions stopped right there.
Again, nothing to do with the merits of the language and everything to do with business realities.
I'm not sure why "business realities" are being brought into this discussion.
If the poll were "what is the most common back-end web development language" or "what language should a startup use in order to have the easiest time finding developers", you would have a legitimate gripe with those who chose, for instance, Prolog. However, that's not the case here.
While you certainly make good points from a business perspective, it's becoming increasingly more likely that programmers you can hire that both:
+ know PHP
+ are experienced enough to deliver a working, maintainable application
are also fluent in at least one of ruby or python, both of which are much nicer languages in general and have strong web-dev presences.
The issue with hiring "people who know PHP" just because a whole lot of people know PHP is that issues with maintainability of whatever gets written tend to be much more of a pain than with similar projects in other high-level languages.
It's not, of course, that you can't write a ball of unmaintainable mud in any language -- you certainly can. PHP is lacking in areas that make fixing that less of a nightmare, and lacking in areas -- both in the language, and in the community for lack of a better term -- that make writing maintainable stuff in the first place easier. The devs who know how to create maintainable PHP codebases, or fix unmaintainable ones tend to have experience with other languages.
This should be, in my opinion, a pretty major concern for business. While it may not be apparent at first, there tends to be diminishing returns from maintenance and development of a product if it's a giant mess. Doing PHP on new projects for ease-of-hire is inviting that mess, due to a whole bunch of little things that tend to snowball. Skilled people won't want to work for you, people that will be skilled but lack experience will leave your employ, and eventually the project will grind to an iceberg pace and stress levels will get high for everyone.
A good dev will probably not have a problem picking up whatever language, as long as you're using "general-use" languages. In the web-dev world, this is currently mostly ruby and python. Choose haskell, and you'll probably have some (read great) difficulty finding people to hire. Choose ruby or python and you'll be more likely to attract the type of devs you want, and at the worst you'll get someone inexperienced who makes a mess that is easier to fix than it would be in a PHP codebase of similar messiness.
If it was just the merits of the language, I don't think I'd have much of a leg to stand on talking from a business end. It's not though, it's a whole lot of little negative things that can make a long-term project more likely to be a failure. The language, and the tools, and the community are getting better, but that's mostly due to the efforts of people who are skilled and experienced with a variety of things improving it because it's paying their bills. It's still far, far away from any other "popular" language in terms of tools, community, available libraries, and just about any other measurement you can make other than "number of people that can say they know it on a resume"
> issues with maintainability of whatever gets written tend to be much more of a pain than with similar projects in other high-level languages.
I'm not sure I follow this. If you take one of these good developers you are referring to, and write your codebase in PHP, what about PHP makes it difficult to maintain as compared to Python or Ruby?
If you take one of these good developers, nothing much, other than that they might need to write some things that they wouldn't have to think about in other languages.
If you take a developer who isn't as good, or isn't as experienced, and they create a ball of mud, it's easier to get it to a maintainable point by a good dev if it's written in a language other than PHP.
Some things about PHP that make it difficult to maintain over time are things like lack of consistency in abstraction, lack of first-class objects, extreme behavioral dependency on php.ini, incomplete reflection capabilities, and so on. These types of things are much bigger of a deal when trying to refactor a messy codebase as opposed to developing on a pretty clean one. They're getting better as time goes on, but the other popular web-dev languages are miles ahead, and it's extremely likely that a good dev capable of writing PHP code is familiar with one of them.
I, for example, really love APL. I would also never think of using APL as the basis of a commercial project unless there was an overwhelming reason to do so.
A friend of mine built a nice company around a product built entirely around Forth. He loved the language. And, he lived to regret making that decision. He eventually paid gobs of money to have the entire code base re-written in C. A couple of years later he sold the business for several million. Potential buyers did not want to touch him with the Forth code base. Just a reality of business.
To clarify, the potential buyers were not interested in the Forth code base because they did not use Forth themselves. Acquiring a company whose products were based around Forth would mean adding a new layer of developers to their team and, effectively, byfurcating their efforts and skill sets. A code base written in C was a no-brainier for most interested parties. With C on the table the language was just a check-box item that did not require further discussion. With Forth the discussions stopped right there.
Again, nothing to do with the merits of the language and everything to do with business realities.