When a php file is loaded at runtime, it runs through a very basic JIT compiler that does statically check a few things before continuing with execution. Syntax, for example, is checked for the entire file during this step.
Most type checking happens at runtime (this might not be true for interfaces at some level, but I can’t say for 100% certain - I just know I tend to see interface related errors earlier during code execution…). It’s perfectly valid syntax to declare a private method as returning an integer and then for the body of the method to return a string (explicitly cast as a string even). As long as you never call that method at runtime, no exceptions will be thrown.
With a half decent IDE or LSP, these sorts of runtime exceptions can be easily avoided but technically they still exist and if you don’t know about that, it can be argued to be confusing. PHP has made a lot of trade-offs to largely maintain backwards compatibility and many of them live in decisions that happen at runtime.
Modern PHP tooling can provide type safety in a very similar way to Typescript if you’re willing to put in the effort while also still technically offering you an escape hatch to do whatever the heck you want and duck type to your hearts content.
NIT linter warning: That’s not really a JIT compiler.
PHP parses the whole file and compiles it to Zend opcodes before executing it, so syntax errors are caught up front. But "JIT" means compiling an intermediate representation/opcodes into native machine code at runtime, when the functions are called, not at load time when the source file is parsed. If you just load a file and never call any of its code, the JIT compiler should never compile it.
PHP 8's OPcache JIT can do that optionally, but the normal load/parse/compile-to-opcodes step isn't JIT.
One form of type checking does happen at compile time (which is really load time in PHP, but close enough), namely when a class extends another class or implements an interface: the types of every method and property are checked to ensure that they are substitutable per the standard variance rules (return types are covariant, parameters are contravariant, props are invariant). Everything else is checked at runtime though, and statically analyzing any of those is left to external tools like phpstan, psalm, or mago.
PHPStan is one of the more popular tools to evaluate that stuff. It works by examining each file and resolving all of the imports to verify that all of the types are compatible.
Jetbrains PHPStorm has this sort of type resolution built in (one of their value adds) but you can also run PHPStan instead of their proprietary version.
It's not processor op-codes, but sure it's part of the software. You wouldn't say that a set of precomputed weights in a numerical integrator aren't part of the software, would you? Or say that the graphics in a game aren't part of the software?
How does that change anything? It doesn't matter if you categorize it as software or not, unwanted is unwanted. And frankly I just flatly disagree, you could certainly make the case that model weights are a form of software.
If they downloaded a 4GiB media file of some Irish band that nobody asked for, people would be upset as well. It doesn't matter what the 4GiB contains. If it is not going to be used by the user and the user didn't ask for it, that's just idiotic to think people would not be upset about it.
There will be loads of papers and publications with fake citation. AI will be trained on these. In the end, we'll have more and more hallucinated information that true content on the internet.
I think all animals are born knowing how to walk, including monkeys and humans. However, that trait only surfaces at a later stage of their development.
> But they open up the gate for a single Big Tech Winner that truly knows everything about you, and can even control everything on your behalf.
We have had that for over a decade, and the Big Tech is called Google. By owning Android, Google pretty much owns and knows everything about its users. The same applies to Apple.
I believe it's a natural evolution that occurs in all systems, including software. Every line of code you write is a liability that increases the risk of failure. The risk compounds and so does the frequency of errors.
reply