it certainly seems to be a constraint of the sort that sklogic was talking about above
Well, this is the thing. sklogic and others seem to think there's some sort of clear bright line dividing, say, Python from Java, where in Python they'll claim you can only deduce a constraint like "is of type object" ahead of time but in Java you can deduce something more specific.
And setting aside the falsity of that (even on Python 2, which doesn't have the annotation syntax or library support to do type hinting, you can still deduce a lot of specific information AOT), I'd argue with the concept of a clear dividing line and say instead that there's a spectrum. And I say this precisely because in languages like Java you can end up only able to deduce something will be of, say, type "Entity", which while better than "Object" still feels less like a qualitatively different thing to me and less useful for expressing the kind of rich constraints hardcore static-type folks talk about. Yet people seem to accept it as a statically typed language.
How is the same thing untrue of C? or Haskell? If I write code that interacts with data generated by a dynamically linked module, that data might include newly defined types.
It can happen in other languages, but Java specifically does a lot of heavy lifting to work around this kind of issue, and some of that is specific to the features and quirks of Java. There's a reason, after all, why people non-jokingly refer to the JVM as the best dynamically-typed language runtime ever developed.
But again what we end up talking about is less a clear binary of "this language is dynamic, that language is static" and more of a spectrum of different combinations of features and design choices which sort of gradually blend into each other as you look at them side-by-side. Which is why I like to argue with the idea that we can meaningfully define "static" or "dynamic" typing.
Well, this is the thing. sklogic and others seem to think there's some sort of clear bright line dividing, say, Python from Java, where in Python they'll claim you can only deduce a constraint like "is of type object" ahead of time but in Java you can deduce something more specific.
And setting aside the falsity of that (even on Python 2, which doesn't have the annotation syntax or library support to do type hinting, you can still deduce a lot of specific information AOT), I'd argue with the concept of a clear dividing line and say instead that there's a spectrum. And I say this precisely because in languages like Java you can end up only able to deduce something will be of, say, type "Entity", which while better than "Object" still feels less like a qualitatively different thing to me and less useful for expressing the kind of rich constraints hardcore static-type folks talk about. Yet people seem to accept it as a statically typed language.
How is the same thing untrue of C? or Haskell? If I write code that interacts with data generated by a dynamically linked module, that data might include newly defined types.
It can happen in other languages, but Java specifically does a lot of heavy lifting to work around this kind of issue, and some of that is specific to the features and quirks of Java. There's a reason, after all, why people non-jokingly refer to the JVM as the best dynamically-typed language runtime ever developed.
But again what we end up talking about is less a clear binary of "this language is dynamic, that language is static" and more of a spectrum of different combinations of features and design choices which sort of gradually blend into each other as you look at them side-by-side. Which is why I like to argue with the idea that we can meaningfully define "static" or "dynamic" typing.