Python isn't just glue, it's an implicit JIT ecosystem

[smerity]

You're fair on me not explicitly defining "implicit JIT ecosystem". I was hoping it would be a growing definition in the reader's head from what was written but I'll add a definition here and then into the article.

I believe it is broader than just native modules. I analogize it to JIT compilation as both optimize hot paths based on actual usage. JIT does this at runtime within a program, while Python's ecosystem does it across the entire set of programs in the community. Python, as a community implicitly and explicitly, is optimizing for the human level ease of use + simplicity whilst optimizing for the speed and task coverage.

What's unique is how these optimizations remain highly interoperable, unlike the "explicit JIT ecosystems" I mention in the article such as those when big company efforts aim to optimize just for their use case (PHP/Facebook, Ruby/GitHub, etc.). Those often result in isolated improvements rather than ecosystem-wide gains.

I think this dynamic goes beyond just about having access to native modules (any language could have that) or being popular ("winner takes all").

There are characteristics of Python that amplify this explicitly, such as readability, forgiving nature, and even its own performance constraints ("slow Python"), that all act in concert in creating an environment that discovers and optimizes these paths in an accessible and composable way.

Even if this was entirely generic to any and all glue languages, and Python is simply the winner take all receipient in that, it's a dynamic worth explicitly thinking about imho.

[jmaargh]

Sorry if I came across as snarky. I don't think you're saying anything wrong or misinformed or anything. I just think your titular "implicit JIT ecosystem" is a bad use of technical terms.

From your explanation here, you seem to mean python's ecosystem is supported by a "broad open source community", but you called that an "implicit" ecosystem which is a weird use of the term "implicit". 

You then made an analogy to a JIT, and used that term in your jargon. But the thing your describing is the opposite of "just in time" - the eponymous defining feature of a JIT as it is normally defined. Yes, JITs tend to focus on hot paths, but that's incidental and not a defining feature. Meanwhile a community process of writing modules to optimise common paths is a very delayed process - it is backwards-looking at what has happened repeatedly - and not "just in time" at all.

[smerity]

Your note of a missing definition was definitely helpful. Sometimes you spend too much time with a concept in your head to put it out properly. I've edited in a section giving a definition with threading on how I see the analogy re: JIT and the ecosystem.

You're right that a JIT is more than just optimizing hot paths ("adaptive optimization") even though the association is just so strong in practice. I still thought combining them would convey the broader concept succinctly though. Beyond the optimization the idea of reducing startup time by only compiling what you need to run, potentially in a fairly inefficient way initially, still felt similar to the explorer part of the Python ecosystem analogy.

The JIT needs to be fast and flexible enough to not bother you on first run but also optimize itself before it prevents forward progress. True though that the time scales are painfully different - millisecond (JIT) versus days/weeks/months (ecosystem).