3 ms·

Just wondering ... what is "large enough developer base"? If you are hiring, you are not hiring 10000 people, you are hiring one or two people. If you can cho

by soc88 15y ago

Just wondering ... what is "large enough developer base"? If you are hiring, you are not hiring 10000 people, you are hiring one or two people. If you can choose between a pool of 10000 developers in PHP and 100 in Haskell (whatever...) you will probably find more candidates you want to hire in the second pool. And it is certainly more likely that you find the appropriate candidate if you don't have to wade though hundreds of applications.

robomartin 15y ago
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.
- doktrin 15y ago
  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.
- kaens 15y ago
  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"

by soc88 15y ago

robomartin 15y ago

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.

doktrin 15y ago
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.
kaens 15y ago
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"