No, it doesn't imply that, because static and dynamic are not mutually exclusive. A static language with polymorphism[1] has both static and dynamic aspects. A purely static language does not need (and thus won't have) runtime type tags of any kind, so any kind of dynamic dispatch (including multimethods) would be impossible at the level of the language (i.e. you'd have to implement it all explicitly as a library).

[1] It shouldn't need to be said, but this is HN so it does need to be said, but I mean OO-style runtime polymorphism here (or, with a stretch, sum types), not parametric polymorphism.

Why haven't you told us what you mean by the notoriously vague terms "static" and "dynamic"?

Because defining every word one uses in a forum post is incredibly tedious, and even when you try to do so preemptively, someone still comes in and asks you for definitions of more words.

I'm using them in a colloquial rather than rigorous sense, because that's the lowest friction way of communicating in a casual setting.

But at core, when I say 'static', I mean something determined before execution, by means of static scopes and compile-time types; when I say dynamic, I mean something determined at the point of execution, by means of dynamic scopes and run-time values. When I say 'static scopes', I mean scopes determined through lexical nesting and static types. When I say 'static type', I mean types determined without need for any execution of the target program. When I say 'dynamic scopes', I mean scopes determined through dictionary lookup at runtime (vtables are dictionaries too), possibly even including dynamic scopes (cf Lisp, Javascript eval, etc.).

Most languages have both dynamic and static aspects, but the mixes vary greatly. Languages designed to be compiled typically use far more statically resolved features, because if you can afford the time to put into analysis, and you have all the source immediately available, you can find a lot of common bugs and generate faster code. Languages designed to be interpreted typically use far more dynamically resolved features, because that gives less latency to execution, more expressiveness, more flexibility with modularity and program composition, and is also easier to implement.

The difficulty is not with understanding that "when I say 'static', I mean something determined before execution" but that you only say 'static' - you don't tell use what is being determined before execution, and that turns your comments into meaningless mush ;-)