Data-Oriented Programming in Python

That article talks about DL, where blas is much less relevant. The kernels are mostly CUDA (for GPU) and similar stuff for other accelerators.

It actually isn't saying that. What do you think Python is made of, under the hood? It's C modules.

The argument is not that NumPy is written in C, but that it amortizes the cost of Python overhead over multiple data, rather than incur it on each datum.

It's a details, but I keep seeing it:

> Yet, [the scientists] struggle to move away from Python, because of network effects, and because Python’s beginner-friendliness is appealing to scientists for whom programming is not a first language.

I don't believe it's the whole story.

In my case, during my 13 years in academia, I saw my field going away from C++ and towards python. Not because of network effects (it was the opposite: it was more difficult to not use what everybody was using), or because scientists were not able to program (the entry language of the whole field was C++, and python arrived only because scientists with a deep knowledge of C++ started to themselves switch the core library to be usable with python).

I think something that computer scientists forgot when they consider the subject is that the way computer scientists do software is just not working when you do science.

In science, you use coding as an exploratory tool. You are lucky if 10% of your code ends up being used in your final publication. Because the 90% was only there to understand and to progress towards the proper direction. For this reason, things like declaring variables, which is very important when one makes a professional software, are too costly to be useful when you need to write down a piece of code that you will ever run once to check a small hypothesis, especially when you have another language not requiring it. Another aspect is that you will present your scientific results to your colleagues, not your code (they are not interested in that), and they will come up with questions or good ideas, all very good for science, but rarely compatible with the way your algorithm was built in the first place, and you will need to shoe-horn it into your code (to test it) without taking 3 weeks. In this case, python flexibility and hackability is very useful.

It's also visible in the popularity of things like Jupyter notebooks (I have to acknowledge it even if I personally don't like working with such tools), which reuse a working approach similar to what was done in mathematica and matlab, that were created with the scientific workflow in mind.

I'm sure python simplicity has played a role. But I have the feeling that some people are totally oblivious on the fact that there may be other reasons.

Wait, what? Thanks for pointing this out. I was pretty close to submitting an order with a Data-oriented Programming book in my cart.

All good points. I think the network effects are more important than they were in the past, because the network has gotten bigger. Today, new graduates make sure to put Python on their resumes, even if they've barely touched it. A colleague who left for another job thanked me for encouraging him to learn Python. Contrast that with 13 years ago, roughly when I switched to Python. My colleagues thought it was some weird toy, and encouraged me to learn C# instead. The past 13 years have also seen most programmers get over their aversion to open-source tools.

It's true, as mentioned in another comment, that repeatability is important. But at least in experimental science, the repeatability of an experiment is a bigger hurdle than making the same code run twice. I use Python code to control my experiments, and the ability to read my way through a complex workflow is quite valuable.

One thing I like is being able to bodge together a huge blob of data and metadata into a dict that's easy to store and unpack. That encourages me to keep more experimental data and metadata, and use it later.

Python and its libraries have sprawled to the point where it's anything but simple.