alt Hacker NewsStrong/weak is a meaningless dichotomy that could be replaced by nice/icky while conveying the same meaning. It just distinguishes whether I, personally, believe a given language has sufficient protections against dumb programmer errors. What counts as strong or weak depends entirely on who's talking. Some will say that everything from C on is strong, others draw the line at Java, still others aren't comfortable until you get to Haskell, and then there are some who want to go even further before it's truly "strong".
Typed versus untyped is, on the other hand, a rigorously defined academic distinction, and one that very clearly places pre-type-hints Python in the untyped category. That's not a bad thing—untyped isn't inherently a derogatory term—but because untyped languages have fallen out of vogue there's a huge effort to rebrand them.
Replies
Strong/weak typing is very specific thing. It refers to the ability to create invalid types within a language. In strongly typed languages it is hard to defeat the type system. In weakly typed languages it is easy to defeat the type system.
Python is strongly typed (hard to escape the bounds of the type system) but (traditionally) dynamically typed (types are checked at runtime).
C is weakly typed (easy to escape the type system), but statically typed (types are checked at compile time).
> Strong/weak is a meaningless dichotomy
Strong/weak is not a dichotomy. It's a spectrum. That's why folks argue over where a language lands in the spectrum. OTOH, static (compile-time) vs dynamic (run-time) is a dichotomy. There's not really any in between. It's clear when and where typing occurs. So there's nothing to argue over.
> Typed versus untyped is, on the other hand, a rigorously defined academic distinction
A typed language is one that has a type system. Python has a type system. It's typed.
...but Python is obviously typed. It has types. In fact everything has a type, and even the types are of "type" type. It has type errors. Saying it's "untyped" invokes a wrong impression. Your usage is very non-standard in programmer circles.
What's wrong with universally understood and well defined concepts of "statically" and "dynamically" typed languages?
Untyped computation in the academic sense you refer to is untyped in the sense of Forth and assembler. The untyped lambda calculus doesn't even have numbers. Pragmatically, a language in which type errors occur is a typed language.
Nor does it make sense to conflate "typed and untyped" with "statically typed and dynamically typed". These are simply very different things. Julia is an example of a dynamically typed language with a quite sophisticated type system and pervasive use of type annotations, it would be insane to call it untyped. Typescript is an example of a dynamic language which is nonetheless statically typed: because type errors in Typescript prevent the program from compiling, they're part of the static analysis of the program, not part of its dynamic runtime.
The fact that it's uncommon to use untyped languages now is not a good reason to start describing certain type systems as 'untyped'! A good term for a language like annotation-free Python is unityped: it definitely has a (dynamic) type system, but the type of all variables and parameters is "any". Using this term involves typing one extra letter, and the payoff is you get to make a correct statement rather than one which is wrong. I think that's a worthwhile tradeoff.