> These things are a little advanced for the likes of me. Any chance you'd be so kind as to give me an example of something I can't easily do because of not having this?
Well, you can do whatever you want in a dynamically typed language. I was discussing the shortcomings if you choose to use PHP's type system.
If I'm using my static types and see `function foo(): Bar` I take comfort that I will receive a `Bar`. If I see `function foo(): array` I have absolutely no idea what that array is. Is it a list of `Bar`? Is it a dictionary of some kind? Is it a heterogeneous list of bools, ints, and Maseratis?
Also, real containers are useful. A true array is a contiguous slab of memory. PHP's array is not. The performance characteristics will be very different. If you had a `Set<T>` type, you could guarantee that there are no duplicates in the set. That is sometimes very useful. No such thing in PHP. PHP arrays can't even be used as a real `Map<String, T>` because if you do `$arr["1"] = new T()`, it wont actually have "1" as a key! It'll transform the "1" into 1 and store it in the 1th slot, like an array!!! Totally flipping useless.
> But those languages require compilation and deploy cycles that are way longer than just getting files on disk, so the total cycle time of development may end up being longer in many cases.
Are you suggesting that you write PHP code and then plop in on a production server without running tests? Because running your tests is comparable to the compile cycle of Java et al. Except in those cases I don't have to write entire classes of tests, whereas you should be writing type-checking-style tests on your PHP code. You just have to be the compiler to make sure your inputs are validated correctly.
> PHP probably shouldn't be used for performance-critical things, sure, but then neither should any other dynamic language.
Then what was the point in comparing PHP's speed to Python? They're both slow and shouldn't be used for performance-critical things. That's fine, but then find me a selling point.
