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.

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

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.

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

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

What if your type system was rich enough that a "datatype error" was a logic error?

That can't prevent every logic error. Here's[0] something I remember reading that really impressed me with static analysis tools. Running PVS-Studio against the Unreal 4 Engine (which is entirely C++).

It was able to detect a surprising number of logic errors, probably just caused by as tired programmer, or copy-pasting too quickly. For example in the function below, it was able to spot that the last 2 clauses of that comparison are identical. The programmer meant to use a '+' instead of '-' in the last one. I don't think you could have a type system that would disallow this logic error. (If it is possible, please prove me wrong, because that sounds awesome).

  static bool PositionIsInside(....)
  {
    return
      Position.X >= Control.Center.X - BoxSize.X * 0.5f &&
      Position.X <= Control.Center.X + BoxSize.X * 0.5f &&
      Position.Y >= Control.Center.Y - BoxSize.Y * 0.5f &&
      Position.Y >= Control.Center.Y - BoxSize.Y * 0.5f;
  }

[0] http://www.viva64.com/en/b/0249/

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.

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?

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.

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?

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.

What would you call a good developer who knew PHP?

A good developer :)

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.

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.

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.

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

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

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

...no?

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

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.