Smalltalk prizes interactivity, in the manner that arises from being able to make small, incremental adjustments to code while it (and it's state) remain in mem

Smalltalk prizes interactivity, in the manner that arises from being able to make small, incremental adjustments to code while it (and it's state) remain in memory. Its rejection of static typing is not axiomatic, merely an expedient way of achieving those interactivity goals. Could the two things be reconciled? I don't know, but I think at least that it shouldn't be unthinkable. As an aside, static type systems which can be mutated during runtime are astonishingly commonplace. They're very crude, and tend to be called "relational databases", and doing those mutations is a major pain because in spite of all that's elegant about relational algebra, actual SQL is a fucking abomination. (And this is coming from a full-on Postgres fanboy.) On your comment about the similarity of Ruby, I know what you mean, and yet I regard Ruby as being basically nothing at all like Smalltalk. That's because I'm principally thinking in terms of the development culture, tools, and working practices, and not thinking in terms of the implementation of the VM or the object model, or the names of certain methods. So similarity between languages is a tricky thing to nail down, not least because in the case of a gestalt system like Smalltalk, "programming language" is actually a tricky thing to nail down.