Most, if not all the points made in the article, seem to stem from a sense of "we need to optimize the code to be readable by mathemeticians, not programmers" which is fair, depending on what you're doing. But goes a bit overboard with the safety argument, which we've seen much better ROI by focusing on memory safety, rather than abstract mathematical proofs.

In fact, the entire safety argument is undermined by the author themselves:

> The engine is closed source. You cannot see how fft or ode45 are implemented under the hood. For high-stakes engineering, not being able to audit your tools is a risk.

What's the point of optimizing your code to be easy for physicists/mathematicians to read for safety, when you can't even verify what the compiler will produce?

I suppose it basically boils down to whether your orgs engineering is run by academics or software engineers, but Matlab doesn't really do anything that python can't for free. And python is more accessible, has more use cases, and strong academic support already.