I realize this is just a comic, but it's one of the reasons that we try to be as compatible with C and Fortran libraries as possible — that's where the vast bulk of high-quality scientific computing work has been done, and we want to be as compatible with it as possible. The goal here is not to duplicate all the work that's already been done, but to allow existing high-quality libraries to be smoothly and easily used together in one environment. That's very much the same philosophy that NumPy and SciPy have, and indeed, it much the same goal. The biggest issue with NumPy, IMO, is that Python arrays aren't designed with linear algebra and interoperability with libraries like BLAS and LAPACK in mind. This leads to the somewhat maddening distinction between Python arrays and NumPy vectors and matrices — and lots of conversion back and forth between them.
I also posted that comment without reading the article -- that was just my first response to "yet another programming language".
I'm sure that it's filling a real need. I just wish that groups could cooperate to make a handful of languages/libraries better rather than having 100 competing ones.
Actually, there is much more co-operation than is visible. Almost all the groups share the same libraries, same bugfixes, same patches, etc., which typically will account for much of the user experience.
The different language approaches will typically compete on things like syntax, speed, etc., and this leads to innovation and cross-pollination of ideas. I personally prefer to have some choice, and use a number of languages for scientific computing myself - but I guess too much choice makes things confusing for the newcomer.
It's about standards, but it still applies.