> have a network dynamic that can dominate rational factors. Yes, but only if they are all equally expressive, or if you only care about the lowest common deno

> have a network dynamic that can dominate rational factors. Yes, but only if they are all equally expressive, or if you only care about the lowest common denominator. In a situation with an expressiveness gradient, the distinction will always survive. I think this insight is articulated well in PG's essay on the blub paradox. Eg: English is a pathetic solution if you want precise/expressive communication for the purpose of engineering -- so no amount of network effect will enable English to trump equations even if it were some new idea (language) like calculus competing with a thousand year old language. > similarly one would think that if python continues benefiting from lavish attention at some point there will be a python 4 etc. you might argue that this not really "fixing the problem" but in the context of delivering useful products here and now this becomes a bit academic Probably the most fundamental tenet (self-professed) of Python is its "simplicity". Whatever that might mean, it seems highly incompatible with growing the language in the manner of C++, and even more so if the changes were backwards-incompatible (as the 2->3 transition demonstrated). The dynamics of language evolution might still bias towards that outcome as the needs of large corporate codebases dominate the beginner's need for simplicity, but at that point Python would have lost most of its soul. But, regardless of all that, (as a concrete example of the kind of limitation I'm talking about) it seems impossible to support generic programming in Python without giving up on OOP / single dispatch. <Lipstick, pig, etc.> > in the context of delivering useful products here and now this becomes a bit academic I disagree, vehemently :-) When there is an impedance mismatch between the problem domain and the abstractions fundamentally embedded into a language/system, you are setting yourself up for a world of pain -- needing an exponential amount of engineering effort to overcome the barrier, and the solution will still forever be doomed to mediocre quality (at best). Calling Python (or pretty much anything) "general purpose" in an absolute sense is a bit of a misnomer -- it just means one is blind to the limitations/biases embedded in the technology, or is implicitly focusing on a limited set of problems.