This doesn't match my experience. For an apples-to-apples example, here's the first function I found in numpy, compared to widely used libraries in C++ and JS:
The JS one is simple enough, but even here be dragons. The "number" type supports storing decimals like 2.3. There's an isInteger() function on it that's never used, and the implementation doesn't actually check that they're integers as far as I can tell. It's anyone's guess what happens when you violate the docs-only requirement for integral values only. Moreover, -1 is a sentinel value indicating autosize, so there are non-integral values that are accepted.
The numpy interface is worse. First off, fully static typing would involve dependent types here. We'll ignore that. Then you have the shape parameter, which is a structure of "ints". What do ints mean here? Any number of things, from python native bigints to np machine types. It also takes sentinel values. The order parameter is the real nightmare here though. Using this effectively is incredibly difficult because numpy doesn't want to constrain itself by specifying memory layout. But choosing appropriately here requires knowing that! Of course we could also just look at the static typing annotations for this function, which has 6 overloads for reshape (https://github.com/numpy/numpy/blob/0066c73f573daafa01cbb975...).
I don't see a lot of evidence in either of these that the dynamic typing forced people to keep them actually simple. They're filled with edge cases.
Compare with Eigen, which uses static typing to separate type parameters from runtime parameters. You don't need to worry about non-integral values because they're unrepresentable. You don't have sentinel values, because AutoSize is a different type with a clear name. The layout is specified as a type parameter, so the order parameter is usable based on information available at compile time. The return type is a bit complicated, but no worse than numpy.
Comments
This doesn't match my experience. For an apples-to-apples example, here's the first function I found in numpy, compared to widely used libraries in C++ and JS:
MathJs: https://mathjs.org/docs/reference/functions/reshape.html
NumPy: https://numpy.org/doc/stable/reference/generated/numpy.resha...
Eigen (C++): https://libeigen.gitlab.io/eigen/docs-nightly/classEigen_1_1...
The JS one is simple enough, but even here be dragons. The "number" type supports storing decimals like 2.3. There's an isInteger() function on it that's never used, and the implementation doesn't actually check that they're integers as far as I can tell. It's anyone's guess what happens when you violate the docs-only requirement for integral values only. Moreover, -1 is a sentinel value indicating autosize, so there are non-integral values that are accepted.
The numpy interface is worse. First off, fully static typing would involve dependent types here. We'll ignore that. Then you have the shape parameter, which is a structure of "ints". What do ints mean here? Any number of things, from python native bigints to np machine types. It also takes sentinel values. The order parameter is the real nightmare here though. Using this effectively is incredibly difficult because numpy doesn't want to constrain itself by specifying memory layout. But choosing appropriately here requires knowing that! Of course we could also just look at the static typing annotations for this function, which has 6 overloads for reshape (https://github.com/numpy/numpy/blob/0066c73f573daafa01cbb975...).
I don't see a lot of evidence in either of these that the dynamic typing forced people to keep them actually simple. They're filled with edge cases.
Compare with Eigen, which uses static typing to separate type parameters from runtime parameters. You don't need to worry about non-integral values because they're unrepresentable. You don't have sentinel values, because AutoSize is a different type with a clear name. The layout is specified as a type parameter, so the order parameter is usable based on information available at compile time. The return type is a bit complicated, but no worse than numpy.