> On the contrary, I prefer my languages lightweight, and capable of allowing arrays (and strings, dictionaries, etc) to be implemented by libraries.

I agree with this philosophy! But that is certainly not at all the case with python, where fancy strings and even fancier dictionaries are readily available at the language level, instead of being implemented as separate libraries that you have to import.

If Python did not support strings nor dictionaries as basic data types, you might have a point. But it does, and it chooses to ignore multidimensional arrays and their basic operations. This is weird, and even a bit offensive when all you need to do is dealing with such arrays of numbers. You always feel like an "outsider", unlike when you program in octave or julia, for example.

Semi-inactive Octave dev here.

Even though I use Python every day, and I have used scipy often, I still reach for Octave whenever I need a quick calculation that I don't feel like turning into a big project.

And yeah, it's nice that matrices are first-class objects. Sometimes I miss 1-dimensional arrays or sensible strings, but it's not a big deal, and for quick, short things, the Octave syntax is still a lot easier to deal with than Python.

Most of Octave's users describe themselves as "not a programmer", despite using a programming language, so I think there's still room for this kind of software in the world.

To give a different perspective:

- the existence of tools for working with strings and dictionaries doesn't take away from numpy at all

- I have never been offended by a programming language or felt like an outsider while using numpy

It always seems a bit weird to me that np.einsum needs to parse a string in its own private syntax. I guess it's a good thing that at least it has tools for this!

The big challenge with leaving core data structures and interfaces to the community is fragmentation. If you look at the rust/go numerical communities the big struggle has been a lack of universal ndarray implementation.

Most numeric libraries can be Described as functions of/on ndarrays that return ndarrays, not having a language wide ndarray is the equivalent of having every library carry it's own unique list interface/implementation.

Well, you could still have a set of "core" packages for basic data structures, or an official library. For example, C++ has STL, and most libraries build on top of that.

Probably explains Fortans continued hold on numerical computing

> Probably explains Fortans continued hold on numerical computing

indeed! a sizeable part of numpy is written in fortran

Only insofar as numpy relies on BLAS and LAPACK for certain functionality, and most (all?) implementations are written in Fortran. The actual numpy source code contains no Fortran; you don't need a Fortran compiler to build numpy. Scipy does contain Fortran, though.

"certain functionality" is a bit of an understatement, here. Those are precisely the core algorithms, that allow you to do things with matrices, solve systems, etc. As you put it, numpy is simply a wrapper for this.

I think that's an unfair characterization of numpy's functionality. Numpy introduces data structures not present in the core python library (another one of your complaints about python, though it's not clear to me why it matters that numpy is a separate library), and certain manipulations do not require BLAS/LAPACK acceleration, eg. multiplying an array by a scalar (yes, I know dscal exists in BLAS) or array slicing. Further, it is possible to use numpy without any BLAS/LAPACK libraries at all, and it continues to work (albeit more slowly).

Note that most accelerated implementations of BLAS are not written in Fortran, but use e.g. SIMD instructions directly.

See also: https://stackoverflow.com/questions/1303182/how-does-blas-ge...