> On Jan 24, 2020, at 3:47 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > I imagine the reason static analysers are generally run as a separate step > rather than just before execution is because then you _really_ don't care > about performance, and it's more convenient to get the results on demand, > rather than them appearing in your server logs.
Let me try to make this rhetorical point in a different way. One of the main strengths of PHP — and IMO one of the reasons for its incredibly marketshare — is the ease with which PHP code can be written, tested, and deployed. And that ease translated to ubiquity. Adding a recommended build step to that in order to gain correctness weakens that value proposition and threatens future ubiquity as other language improve. Said another way, if someone is evaluating which language to use — if they have to have a build step anyway — they might just avoid PHP and choose a truly compiled language that by nature is significantly more performant. Or they might look for a language that is designed to provide static analysis without requiring a build step. Not sure if such as language exists, but if not there is certainly a compelling opportunity to create one. Or this is an opportunity that PHP could seize for itself. So saying "use a static analyzer" is IMO just pointing out an overall weakness that PHP can't automatically do static analysis on its own. -Mike P.S. I am not calling for any new feature in this message, just wanting to call attention to the fact that PHP does not operate in a vacuum and that those who care about PHP's future should remember to consider that when discussing improvements other languages might have or might be adding.
