Lesson 1 — Why Python won
Python is a slow, interpreted, dynamically typed language. On paper it is a poor candidate for work that involves billions of arithmetic operations. It nevertheless became the language of Artificial Intelligence, essentially without competition. Understanding why tells you something useful about how the whole ecosystem is built.
The wrong answer: "because it is simple"
Python is readable, and that matters, but simplicity alone explains nothing. Ruby is at least as pleasant. Basic was simpler still. Neither took over machine learning.
The real answer: it delegates
The insight behind the scientific Python ecosystem is that Python is not the thing doing the work.
When you write a NumPy operation that multiplies two large matrices, here is what happens: Python spends a few microseconds identifying the objects and dispatching the call, then hands control to a compiled library — written in C, C++, Fortran or CUDA — which performs the computation on many cores at once and returns the result. Python's slowness applies to the dispatch, not to the arithmetic.
So the language you write is optimised for the human, and the code that runs is optimised for the machine. You get readable code and near-native performance in the same file, provided you express your work as operations on whole arrays rather than as loops over individual numbers.
This architecture creates one rule that governs how you write numerical Python: never loop over data in Python when a whole-array operation exists. A loop over a million elements stays in the slow layer. The equivalent array expression drops into the fast layer. The difference is routinely a factor of fifty.
Why it happened to Python specifically
Several languages could have played this role. Python got there because of a sequence of accidents that reinforced each other.
It was easy to extend from C. Python's C interface has been usable since the 1990s, which is why numerical extensions appeared early. Numeric, the ancestor of NumPy, dates from 1995.
Scientists were not software engineers. The people who needed these tools were physicists, statisticians and biologists who wanted to express an idea and get a number, not manage build systems and type declarations. Python let them do that.
A single array type unified everything. NumPy's consolidation in 2006 gave the community one shared representation for numerical data. Every library that came afterwards could accept and return that same type, so tools composed instead of competing. This is the technical decision that mattered most.
Then the feedback loop closed. Once enough tools existed, any new project targeted Python because that is where the users were, and any new user chose Python because that is where the tools were. By roughly 2015 the question was settled, and no amount of technical superiority elsewhere was going to reopen it.
What this means for the alternatives
The alternatives are not bad. They are outside the loop.
| Language | Genuine strength | Why it did not win AI |
|---|---|---|
| R | statistics, exploratory analysis, publication-quality plots | ecosystem centred on statistics rather than deep learning; smaller community outside academia |
| Julia | genuinely fast without delegating; designed for numerical work | arrived in 2012, well after the loop had closed; far smaller library base |
| C++ | maximum control and performance | development is slow and error-prone; it is what Python calls into, not what you prototype in |
| JavaScript | runs models directly in a browser | training tooling is thin; used for deployment, not development |
| Java / Scala | strong in large-scale data processing | verbose for experimentation; the data engineering layer rather than the modelling layer |
The pattern is consistent: each is better than Python at something, and none offers the near-certainty that a paper published tomorrow will ship a Python implementation you can run.
Choose Python because of the ecosystem, not because of the language. The moment you need to read a new model's reference implementation, apply a published technique or ask a question someone has already answered, the ecosystem is the only thing that matters.
How much Python you actually need
Far less than a full language course. To do machine learning you need:
- Variables and types: numbers, strings, booleans
- Data structures: lists, dictionaries, tuples, sets
- Control flow: conditionals, loops, comprehensions
- Functions: arguments, default values, return values
- Enough object orientation to read a class: you will subclass a model in PyTorch, and rarely design a hierarchy
- Imports and modules: knowing where a name came from
- Reading a stack trace: this is a genuine skill and it saves hours
What you can safely postpone indefinitely: decorators beyond using them, metaclasses, async programming, descriptors, the finer points of the type system. They belong to application development, not to modelling.
Two focused weeks are usually enough to reach that level.
In three sentences
Python won not because it is fast but because it delegates every heavy computation to compiled libraries, so you write readable code that drives native machinery. NumPy's shared array type let the whole ecosystem compose rather than compete, and the resulting feedback loop made the outcome irreversible by around 2015. You need only the basics of the language, plus the discipline to express work as array operations rather than Python loops.
Next — Lesson 2: NumPy and pandas →