In theory, a programming language only has a syntax and a semantics, and everything else is an implementation detail. In practice, programming languages are designed for specific use cases, and lend themselves to specific implementation strategies. For example:<p>(0) Type-checking C++ templates requires expanding them. However, nothing forces a C++ implementor to translate the individual template instantiations to machine code (or whatever target language is used). A C++ implementor could use a strategy similar to what is used in Java and C#, and re-instantiate every template on demand at runtime. Of course, nobody does this, because it&#x27;s bad for the implementor (more work, because instantiating templates is more complex than instantiating generics, so better not do it at runtime if it&#x27;s already been done at compile time), bad for the user (worse runtime performance), and good for noone (except perhaps C++ detractors).<p>(1) A Python implementor could use whole-program analysis to assign variables and expressions more useful static types than `AnyObject` - similar to what STALIN does for Scheme. But, again, this is bad for the implementor (more work), bad for the user (less interactivity and instant gratification, due to the constant rechecking of the whole program every time a change is made), and good for noone (except perhaps Python detractors).<p>Now, there exist language designs that are less biased towards a fixed implementation strategy. For example, Common Lisp, Standard ML and Haskell. But these languages are also markedly less popular, which perhaps suggests that programmers usually prefer languages that have a concrete story about what use cases their design optimizes for.