4 ms·

I hate PHP too, but this: > Let's look at people who know how to program, you know, the guys who participate and win awards at ACM ICPC and TopCoder. Is goal

I hate PHP too, but this: > Let's look at people who know how to program, you know, the guys who participate and win awards at ACM ICPC and TopCoder. Is goalpost moving. He's not suggesting that PHP is a great language to start with if you aim to become a great algorithmic programmer, rather that it's a great language to start with if you aim to become a competent web developer. > Saying "but Facebook and Wikipedia use PHP!" doesn't count :-) But why not? Surely "X and Y outrageously successful projects use Z" is a valid argument for Z's power as a programming language?

lusr 14y ago
It's an invalid argument because not all projects are alike. Facebook and Wikipedia are indeed very successful projects but they have a massive advantage over the types of projects I deal with in enterprise environments. For instance: - technical environment: the Facebook/Wikipedia/generally-any-web-startup architects get to choose their technical environment 100%; in most corporates you need to integrate with legacy applications and databases in a specific environment, often enforced by IT policy, and this imposes significant constraints on which languages will be feasible options - interoperability: for large, modular systems developed by disparate teams over decades with little or no standards or co-ordination, a statically typed language can be absolutely invaluable for ensuring interoperability and discovering usage (documentation is typically non-existent in these environments, as are tests, and the latter is seldom - often impossible - to retrofit); even for new systems, static typing can save a lot of time when developing and integrating new work across large teams, in my opinion - resistance: business and technical knowledge lives in developers who are part of an ancient stack, e.g. Microsoft or Oracle or Borland; switching to PHP or Python or Ruby etc. means convincing these people to learn very different new technologies (good luck - won't happen), figuring out how to interface with legacy stuff using a language outside of the stack, introducing new tool chains, etc.j - time & budget: even if the existing developers are keen to learn, it's tough convincing the project manager you need an extra month to go through the upskilling process and that you need to spend time researching interoperability options, and that inevitably you will run into future issues, etc.; the problem is most projects are run and budgeted for on a local cost benefit analysis and very rarely would the benefit of switching languages for one project be worth it (even though, in the big picture across multiple projects, it may very well be) An observation: whenever this debate comes up on the HN, the proponents of modern, dynamic languages are invariably people working in closed environments where they have the freedom to set standards, do things right from the beginning (coding standards & reviews, tests, documentation) and the ability to make technology selections across the board. Often this freedom is not a characteristic of other environments, and consequently the language used in a one environment may be unsuitable in another.
10098 14y ago
he didn't specify what kind of programming, so I'm free to interpret it in the most general way

lusr 14y ago

It's an invalid argument because not all projects are alike. Facebook and Wikipedia are indeed very successful projects but they have a massive advantage over the types of projects I deal with in enterprise environments. For instance: - technical environment: the Facebook/Wikipedia/generally-any-web-startup architects get to choose their technical environment 100%; in most corporates you need to integrate with legacy applications and databases in a specific environment, often enforced by IT policy, and this imposes significant constraints on which languages will be feasible options - interoperability: for large, modular systems developed by disparate teams over decades with little or no standards or co-ordination, a statically typed language can be absolutely invaluable for ensuring interoperability and discovering usage (documentation is typically non-existent in these environments, as are tests, and the latter is seldom - often impossible - to retrofit); even for new systems, static typing can save a lot of time when developing and integrating new work across large teams, in my opinion - resistance: business and technical knowledge lives in developers who are part of an ancient stack, e.g. Microsoft or Oracle or Borland; switching to PHP or Python or Ruby etc. means convincing these people to learn very different new technologies (good luck - won't happen), figuring out how to interface with legacy stuff using a language outside of the stack, introducing new tool chains, etc.j - time & budget: even if the existing developers are keen to learn, it's tough convincing the project manager you need an extra month to go through the upskilling process and that you need to spend time researching interoperability options, and that inevitably you will run into future issues, etc.; the problem is most projects are run and budgeted for on a local cost benefit analysis and very rarely would the benefit of switching languages for one project be worth it (even though, in the big picture across multiple projects, it may very well be) An observation: whenever this debate comes up on the HN, the proponents of modern, dynamic languages are invariably people working in closed environments where they have the freedom to set standards, do things right from the beginning (coding standards & reviews, tests, documentation) and the ability to make technology selections across the board. Often this freedom is not a characteristic of other environments, and consequently the language used in a one environment may be unsuitable in another.

10098 14y ago

he didn't specify what kind of programming, so I'm free to interpret it in the most general way