The libraries that are more generically useful are lower level ones like the linear algebra libraries: BLAS, LAPACK, SuiteSparse, etc. I think the key to their success is at least in part because of a shit simple common data format. A dense matrix is just a bunch of floats packed in memory... if that's your common format, you can do a lot.
Also, relative to other domains in scientific computing, there tend not to be too many ways of doing something in linear algebra. Gaussian elimination with optional full or partial pivoting is basically good enough. QR factorization, rank revealing or not.
On the other hand, even "simple" things like function approximation get complicated quickly. There is no one-size fits all solution. Do you want to do an L2 or minimax approximation? Or would you rather interpolate a function? What polynomial basis do you want to use? What degree of polynomial? Piecewise? Splines? Oh yeah, there are rationals, too...
Solving linear or nonlinear equations brings in many different iterative solvers. Maybe you need preconditioning?
Solving PDEs combines all this complication and difficulty and then throws geometry into the mix, which is even more subtle and difficult to get right than all the rest.
I think in a lot of cases writing your own stuff just means you can sidestep all this. Writing a library that is general and handles all this stuff elegantly and efficiently is really hard. Using one can be just as hard.
Edit: I think my point about the common data format also partly explains the success of "scientific Python" and MATLAB, with Julia struggling to gain a foothold. In MATLAB, everything is a matrix; in scientific Python, numpy's ndarray is the common data format. I've seen people waste a lot of time shuffling data back and forth between different Julia libraries' idiosyncratic data formats.
It looked cool in demos, but there was no way to get a foothold on it as a library. I never got it to do anything useful. I only made modest progress by implementing a custom XML tag that let me get my data into one of their huge example programs.
I'm a better programmer now than I was then, but I still kinda think that software sucked.
> - Familiar. Morpho uses syntax similar to other C-family languages. The syntax fits on a postcard, so it's easy to learn.
> - Fast. Morpho programs run as efficiently as other well-implemented dynamic languages like wren or lua (Morpho is often significantly faster than Python, for example). Morpho leverages numerical libraries like BLAS, LAPACK and SUITESPARSE to provide high performance.
> - Class-based. Morpho is highly object-oriented, which simplifies coding and enables reusability.
> - Extendable. Functionality is easy to add via packages, both in Morpho and in C or other compiled languages. Packages can be downloaded, installed and distributed via the morphopm package manager.
> MIT License
> Languages: C 98.8% Python 0.7% CMake 0.5% Batchfile 0.0% Makefile 0.0% Objective-C 0.0%
https://github.com/Morpho-lang/morpho
That builds libmorpho.so, the CLI is at:
https://github.com/Morpho-lang/morpho-cli
I’m not involved in this project in any way, just trying it out because it sounds interesting.
Simulate Literally Everything!
I would expect most design is like this. There are thousands of constraints a designer has in the back of their head, most they are not even consciously aware of. The optimization of the objective is the trivial part. Defining the proper objective function will be very hard.
I'm not holding my breath either though.