vukonen

The reason to choose it in the first place is, as I said, ease and convenience of use when used as a glue language. It's easier than in say, C or C++, to call some functions operating on Numpy arrays and make a graph based on that.

I just think saying "the person who created Numpy chose Python" is a bit weird, when all the heavy-lifting code is in C. Following this logic that person also chose all the other languages that have bindings to Numpy. Yes, the creators of Numpy probably had Python in mind when creating the library. But that just means they chose Python as their glue language of choice, not as their platform for implementing algorithms used in ML or scientific computing.

I did say that being easy to learn is a great language feature that made Python succeed in scientific circles. It's just that using Python for science exposes its shortcomings much less often that using it more generally, which is in most cases done by "full-blown" software engineers, who spend more time programming than, for example, creating a scientific model.

I don't think anyone has "chosen" to implement Numpy (or any of the hundreds of C and C++ modules) in Python because of its language features. On the contrary, they specifically avoided using pure Python because of its low performance and opted for more performant languages used through FFI.

The reason people have gone through the effort to implement those modules is absolutely because of "captive audience based killer apps" which for Python were ML and scientific computing. And while Python is decent in its role as a glue language, it succeeded mostly by being easy to pick up and very forgiving, which shouldn't be the main factors for choosing a language for anyone who is a software engineer and not a scientist.

Numpy is written in C and PyTorch is written in C++. If you mean their APIs, you are right that they are more pleasant to use in Python, but that's because Python trades off performance and control for convenience and ease of use.

I only meant to say that in my opinion something like C++ "hiding" behavior in libraries, classes or through operator overloading is not different from Python where easy to use modules hide extreme amounts of complexity. In fact, C++ is better, because it uses FFI way less than Python and by being a lower level language it limits the maximum possible difference in abstraction level between visible and "hidden" code.

I agree that Python is great as a glue language. Maybe "arbitrary" wasn't the right word to use. What I meant was that Python hides what actually happens in exactly the same way that lower level languages do, just at a higher abstraction level.

Python is just an arbitrarily chosen glue language in regards to data science and machine learning. Pretty much all the heavy lifting (where having a lot of control is required for performance) is done by modules written in C or C++.

There's not a lot of difference between usage of such modules in Python "hiding" complexity and abstractions used in Java, C#, C++ or Rust except those languages don't actually need to use FFI to get acceptable speed. Computer Science is pretty much just layers and layers of abstractions and the level of abstraction that Go or Python chose to operate on isn't special in any way.