And in Tcl the runtime type is computed at time of use. An optimized Tcl could cache an integer with a string that represents an int to avoid that cost.

Nevertheless, a runtime type tag is an optimization. That doesn’t make Bob’s statement any less true.

How is it not related?

Because Python is “strong typed” vs “weak typed” for Tcl?

    $ tclsh8.6
    % expr 1 + 2
    3
    % expr 3 + “hey there”
    invalid bareword “hey”
    in expression “1 + hey there”;
    should be “$hey” or “{hey}” or “hey(…)” or …

vs.

    $ python3.11
    >>> 1 + 2
    3
    >>> 1 + “hey there”
    Traceback (most recent call last):
       File “<stdin>”, line 1, in <module>
    TypeError: unsupported operand type(s) for +: ‘int’ and ‘str’

I don’t really see a difference. Both checked types at runtime. Clearly Tcl can check types at runtime, even though it represents everything as a string. Whether all commands do so is another story. But, not all functions in Python check types before trying to do things that don’t make sense, either. So…