5 ms·

I really don't want to sound negative, I'm sure a lot of thought and work went into this, but one has to wonder - would it not be easier to just use static lang

by pka 11y ago

I really don't want to sound negative, I'm sure a lot of thought and work went into this, but one has to wonder - would it not be easier to just use static languages instead of writing static analyzers from scratch for every dynamic language out there?

Bulk70 11y ago
Often the problem being solved by this sort of thing isn't directly about making it easier to work with a language, but making it easier to hire developers. The hiring pool for developers who are very good with PHP is much much larger than a lot of other languages simply by virtue of it being an easy language to get started with. This is also why Facebook has spent so much time and effort on things like HHVM and Hack.
- pka 11y ago
  2 counterpoints: * Would you hire somebody who wasn't able to learn a new language in a reasonable amount of time? * Would you let somebody who just started with PHP (by virtue of it being an easy language to start with) work on your backend?
  - FranOntanaya 11y ago
    Not counterpoints. The comment above states that the pool of very good PHP developers is larger. This implies easier hiring (capacity to learn a new language is not relevant, because it works both ways), which, among other reasons, would be because they'll be applying first to PHP positions; and secondly, a very good PHP developer is far from somebody who just started.
    - pka 11y ago
      Let me rephrase. I am proposing that (barring very specific requirements which webdev doesn't justify) there's no such thing as a "good PHP developer". A good developer is a good developer, period. A good developer will learn a new language in a reasonable amount of time and will be able to be productive and write good code in it. A PHP-only (or X-only for that matter) developer is, by the definition above, not a good developer. So why restrict oneself to some random pool of X-only people?
      - brokentone 11y ago
        In general, I agree. But getting to mastery level takes time even for really good developers. Certain jobs require master-level application of that language's constructs for efficiency, security, or other reasons.
      - jschwartzi 11y ago
        What would you call a good developer who knew PHP?
        pka 11y ago
        A good developer :)
  - giaour 11y ago
    IIRC, one of Facebook's motivations for sticking with PHP was that it was the easiest language for everybody new to learn, meaning that they don't have to consider language expertise when hiring. FWIW, they have released cool open source projects on Haskell and ocaml, so it's not like they've never considered any alternatives.
    - jonesb6 11y ago
      My understanding is that Facebook also had a MASSIVE amount of PHP code written. They then ported the performance bits to C++ and then realized they still had a huge amount invested in PHP, such that it wasn't worth it to switch off it entirely. I also have a small suspicion that they wanted to stick to their roots a bit. But thats just me.
- andreasklinger 11y ago
  Imo: the only hard thing in webdev are handling the complexity of scaling and legacy. In many cases the latter forces you to compromises in what you pick and the first one in compromises when you pick it. I fully understand when people try to make work what they have. Eg PHP by itself is a very fast powerful language. The tooling and several aspects (dynamic type etc) are exhausting for larger code bases but this is something which people inhouse can solve without requesting the full company to switch.
gsnedders 11y ago
If you already have a codebase in a dynamic language, it can be incredibly hard to justify the cost of rewriting (which will likely pause feature development until the rewrite reaches feature parity, etc.) v. the cost of employing a small number of people to improve tooling of your current language. Or even forking your current language (as FB have done with HHVM and the introduction of Hack).
untog 11y ago
I don't know, how easy would it be to rewrite the entire Etsy stack in a new, static language? My instinct says it would be "not trivial".
nikic 11y ago
You make it sound like people don't implement static analyzers from scratch for every static language out there. Static analysis is not obsoleted by using a "static" language. You can't even say that static analysis is easier in a static language (the problems you deal with are just different). Every language with a non-trivial number of users tends to have a couple (or maybe couple dozen) different static analyzers of varying quality. This is one of the PHP static analyzers.
- munin 11y ago
  > You make it sound like people don't implement static analyzers from scratch for every static language out there. Yes, except those static analyzers are the compilers for those languages and the rules that define crappy programs are in the type system, not in ad-hoc specifications of patterns to identify for static analyzers...
  - nikic 11y ago
    Static analyzers for different languages detect different types of errors. A static analyzer for PHP may try to find type mismatches. For statically typed languages that's obviously not relevant, as the compiler already handles it. On the other hand, a static analyzer for C may try to find use-after-free bugs. For PHP that in return is not relevant, as the compiler/runtime handles it already. While some compilers do ship with static analysis components (e.g. Clang), static analyzers are usually distinct from compilers. Doesn't matter it for static or dynamic languages.
    - munin 11y ago
      Type checking is static analysis. Languages like C have crappy type systems, so the type checking static analysis is also crappy. This is a property of the type system, not the universe...
  - csixty4 11y ago
    > Yes, except those static analyzers are the compilers for those languages The first linting tool was made in 1979 for C programs and I remember ads for PC-Lint in the back of programming magazines all the time growing up. Static analysis tools catch more than just datatype errors. They look for patterns that identity common logic errors as well. PC-Lint used to cost a couple hundred dollars, and people were plenty willing to pay that much for extra peace of mind.
debacle 11y ago
...no? Static analysis has nothing to do with typing. Static analysis is about interpreted code, where you lack the luxury of compiler warnings.
- lost_name 11y ago
  Static analysis doesn't have to involve typing, but it is only about a program reviewing your code for potential issues. Whether or not it is interpreted isn't important.
bpicolo 11y ago
PHP has some degree of static/gradual typing actually, so there's that.

by pka 11y ago

Bulk70 11y ago

Often the problem being solved by this sort of thing isn't directly about making it easier to work with a language, but making it easier to hire developers. The hiring pool for developers who are very good with PHP is much much larger than a lot of other languages simply by virtue of it being an easy language to get started with. This is also why Facebook has spent so much time and effort on things like HHVM and Hack.

pka 11y ago
2 counterpoints: * Would you hire somebody who wasn't able to learn a new language in a reasonable amount of time? * Would you let somebody who just started with PHP (by virtue of it being an easy language to start with) work on your backend?
- FranOntanaya 11y ago
  Not counterpoints. The comment above states that the pool of very good PHP developers is larger. This implies easier hiring (capacity to learn a new language is not relevant, because it works both ways), which, among other reasons, would be because they'll be applying first to PHP positions; and secondly, a very good PHP developer is far from somebody who just started.
  - pka 11y ago
    Let me rephrase. I am proposing that (barring very specific requirements which webdev doesn't justify) there's no such thing as a "good PHP developer". A good developer is a good developer, period. A good developer will learn a new language in a reasonable amount of time and will be able to be productive and write good code in it. A PHP-only (or X-only for that matter) developer is, by the definition above, not a good developer. So why restrict oneself to some random pool of X-only people?
    - brokentone 11y ago
      In general, I agree. But getting to mastery level takes time even for really good developers. Certain jobs require master-level application of that language's constructs for efficiency, security, or other reasons.
    - jschwartzi 11y ago
      What would you call a good developer who knew PHP?
      - pka 11y ago
        A good developer :)
- giaour 11y ago
  IIRC, one of Facebook's motivations for sticking with PHP was that it was the easiest language for everybody new to learn, meaning that they don't have to consider language expertise when hiring. FWIW, they have released cool open source projects on Haskell and ocaml, so it's not like they've never considered any alternatives.
  - jonesb6 11y ago
    My understanding is that Facebook also had a MASSIVE amount of PHP code written. They then ported the performance bits to C++ and then realized they still had a huge amount invested in PHP, such that it wasn't worth it to switch off it entirely. I also have a small suspicion that they wanted to stick to their roots a bit. But thats just me.
andreasklinger 11y ago
Imo: the only hard thing in webdev are handling the complexity of scaling and legacy. In many cases the latter forces you to compromises in what you pick and the first one in compromises when you pick it. I fully understand when people try to make work what they have. Eg PHP by itself is a very fast powerful language. The tooling and several aspects (dynamic type etc) are exhausting for larger code bases but this is something which people inhouse can solve without requesting the full company to switch.

gsnedders 11y ago

If you already have a codebase in a dynamic language, it can be incredibly hard to justify the cost of rewriting (which will likely pause feature development until the rewrite reaches feature parity, etc.) v. the cost of employing a small number of people to improve tooling of your current language. Or even forking your current language (as FB have done with HHVM and the introduction of Hack).

untog 11y ago

I don't know, how easy would it be to rewrite the entire Etsy stack in a new, static language? My instinct says it would be "not trivial".

nikic 11y ago

You make it sound like people don't implement static analyzers from scratch for every static language out there. Static analysis is not obsoleted by using a "static" language. You can't even say that static analysis is easier in a static language (the problems you deal with are just different). Every language with a non-trivial number of users tends to have a couple (or maybe couple dozen) different static analyzers of varying quality. This is one of the PHP static analyzers.

munin 11y ago
> You make it sound like people don't implement static analyzers from scratch for every static language out there. Yes, except those static analyzers are the compilers for those languages and the rules that define crappy programs are in the type system, not in ad-hoc specifications of patterns to identify for static analyzers...
- nikic 11y ago
  Static analyzers for different languages detect different types of errors. A static analyzer for PHP may try to find type mismatches. For statically typed languages that's obviously not relevant, as the compiler already handles it. On the other hand, a static analyzer for C may try to find use-after-free bugs. For PHP that in return is not relevant, as the compiler/runtime handles it already. While some compilers do ship with static analysis components (e.g. Clang), static analyzers are usually distinct from compilers. Doesn't matter it for static or dynamic languages.
  - munin 11y ago
    Type checking is static analysis. Languages like C have crappy type systems, so the type checking static analysis is also crappy. This is a property of the type system, not the universe...
- csixty4 11y ago
  > Yes, except those static analyzers are the compilers for those languages The first linting tool was made in 1979 for C programs and I remember ads for PC-Lint in the back of programming magazines all the time growing up. Static analysis tools catch more than just datatype errors. They look for patterns that identity common logic errors as well. PC-Lint used to cost a couple hundred dollars, and people were plenty willing to pay that much for extra peace of mind.

debacle 11y ago

...no? Static analysis has nothing to do with typing. Static analysis is about interpreted code, where you lack the luxury of compiler warnings.

lost_name 11y ago
Static analysis doesn't have to involve typing, but it is only about a program reviewing your code for potential issues. Whether or not it is interpreted isn't important.

bpicolo 11y ago

PHP has some degree of static/gradual typing actually, so there's that.