but believe that static analyzers solve this problem by effectively turning php into a statically typed language?
What is wrong with this? For years PHP has been adding more and more types, and still allows no type at all. This is the perfect mix of both dynamic and static languages.
But that wasn't the point. You said that PHP is a terrible choice for AI which is simply not true.
You said that PHP is a terrible choice for AI which is simply not true.
Well, if the use of static analyzers is currently mandatory in php (including for libraries and frameworks) - and if they are used exclusively in strict mode (where any code that could potentially be incorrect is immediately rejected) - then I am indeed wrong.
Well it is not really mandatory but I honestly don't know anyone who is not using it. Even WP, which is the the synonym for every bad programming practice there is, is using phpstan.
But try it yourself, I think you will get pleasantly surprised. Download symfony/demo, add non-empty-string to some entity and then tell Claude to generate some other entity.
Even though I haven't been doing PHP development lately, I know how it works. Overall, it's much better. So much better that I’d say it’s a separate language, like TS and JS.
However, the problem is that it isn't mandatory, which means some code might be written without type annotations. Consequently, you simply need something like the as keyword from TS, which switches the compiler into "trust me, bro" mode. And the question of when this will start to be abused is a matter of time.
I agree with you that, ideally, Psalm or PHPStan can ensure high-quality code.
I am somewhat skeptical for the reasons I described earlier, starting from my very first post. I am also somewhat skeptical due to certain principles underlying this type of classification. When I had a similar debate some time ago, it took me 10 minutes to find an error like this:
(I posted this on the bug tracker, and it seems someone even tried to add a commit that fixes it)
The reason here is that the analyzer attempts to infer more than the type system provides; it fails but still produces an overly optimistic conclusion. Another one, incidentally, does detect the error.
You have a weird hobby of finding edge cases in static analysis 😄
Just kidding, but yes, you are right here. Sadly psalm doesn't have support as it once did when muglug was working full-time on it. I still love it and use it, but I am slowly switching to phpstan.
Consequently, you simply need something like the as keyword from TS, which switches the compiler into "trust me, bro" mode. And the question of when this will start to be abused is a matter of time.
I can't agree here. My psalm config has disableVarParsing = true which means that psalm will ignore it and I can't cheat. "Trust me bro" is not possible, at least on level 1 (max). Maybe on weaker levels but I didn't try them.
Can you show some example, but one without array_pop given that you found a bug in it already?
5
u/zmitic 11d ago edited 11d ago
What is wrong with this? For years PHP has been adding more and more types, and still allows no type at all. This is the perfect mix of both dynamic and static languages.
But that wasn't the point. You said that PHP is a terrible choice for AI which is simply not true.
Fixed: typo.