[munk-a]

Interestingly "statically typed" and "dynamically typed" are becoming less exclusive, there are code sniffers that can run static analysis of code to detect potential type incompatibilities during inspection and PHP even now has a group of parse errors that will be raised if incompatible classes definitions are detected i.e.

    class Foo { function do(): int { return 1; } }
    class Bar extends Foo { function do(): string { return 'a'; } }

while PHP will also do dynamic type checking during execution. I don't think this is surprising since static type enforcement has never been a requirement of a compiler/interpreter of a executable code page without run-time type checking - it's just a sort of bonus utility that is packaged into the process to make things easier. Whether your static code analyzer is in gcc or is just some separate utility it all works out in the end, so any sort of code linters are essentially doing a static type analysis (among other things, and usually language constraints prevent this analysis from being as much of a solid proof as languages designed to specifically be statically typed).

So I pretty strongly disagree that typing systems can either be static or dynamic, because I think the separation of manifest vs. implicit is a false one, lots of languages (again) support partially explicit type declarations while allowing some sort of support for a generic declaration.

[sifoobar]

Snigl [0] has statically typed function signatures, struct fields, bindings etc; but values still carry their type.

It also traces code before running it to eliminate as many type checks as possible.

The categories aren't very helpful from my perspective, same goes for compiler vs. interpreter. All it leads to is endless arguing about definitions and discouraging of novel approaches.

[0] https://gitlab.com/sifoo/snigl#types

[munk-a]

I agree, and I don't think this is a bad trend, once upon a time I think static vs. dynamic was a clear distinction, that distinction is being worn down as we learn more about the value and costs of those approaches - and as that happens we're compromising the approaches to gain more of the value.

In PHP the (mostly) JIT interpretation exposed a weakness where infrequently executed pieces of code were harder to have confidence in. Unit tests and such have raised our confidence but explicit typing can also raise our confidence in an easier manner, both are good to have but having access to more tools just makes our lives easier.

In fact PHP can be pre-cached in bytecode now (which is basically just a traditional compiled approach) and in the default run mode PHP code files are interpreted and then cached to minimize the number of times code needs to be interpreted. The lines between compiled vs. interpreted are getting really fuzzy now and were pretty fuzzy as far back as Java bytecode (which is as far as my memory goes, others may have a better handle on earlier experiments in partial compilation)

[naasking]

> I agree, and I don't think this is a bad trend, once upon a time I think static vs. dynamic was a clear distinction

I think there's still a very clear distinction, but there's often value in having access to both in one language. The dynamic typing features can often make up for limitations of your type system, for instance.