That's the perspective of a software developer. Neither Mathematica nor Matlab actually try to address this market. Both are languages for mathematicians, scientists and engineers and are still mostly unrivalled when it comes to domain knowledge.
Python has the domain knowledge in the datascience domain, Julia has pretty good domain knowledge in OR. No one really comes close to capturing the symbolic computation domain as Mathematica does.
Targeting the non-engineering crowd also means they are optimizing for a group that cares less about stability. That allows them to deprecate features, change interfaces, etc. An open source language is inevitably going to attract some maintainers who care about (or are paid to care about) keeping legacy code working.
I haven't worked with Mathematica in years, though, so this is mostly speculation: how strictly do they maintain backward compatibility?
> AbsoluteOptions has been reimplemented to be more accurate, and the form returned for a particular option may be different now.
They deprecate stuff, but almost never remove it:
> ValueQ has been redesigned to test for the presence of a definition regardless of whether the definition is used. Old behavior can be restored by specifying "Legacy" as the method.
They play more fast-and-loose with functions documented as "experimental".
> Targeting the non-engineering crowd also means they are optimizing for a group that cares less about stability.
Looking at how many buzzword bingo boards I could make with JavaScript frameworks de jour and even enterprise platforms like .NET I find this statement exactly backwards in practice.
> An open source language is inevitably going to attract some maintainers who care about (or are paid to care about) keeping legacy code working.
Over 20 years I’ve found this to be quite a mixed bag.
I wouldn't lump Mathematica and Matlab together. Not least because Matlab is almost ubiquitous in academia and in engineering while Mathematica is extremely rare.
The matlab licencing will be their downfall. Its the only licence we have in work that is per seat vs being token (floating) based, due to the cost of a floating license. So instead of having a tool any of our engineers can use, we have it assigned to a few engineers, and the others make do with octave or python. The sensible long term is to standardise on one language, and if it were not for certain toolboxes, that would be python or Julia, most likely. If the matlab licenses we had were floating, mathworks would get the same money, but would be more likely to keep our business, instead of pushing us to look into how best we can replace them.
yup, I'm currently taking Andrew Ng's newly redone machine learning course. the biggest change is that the language has been switched from matlab to python.
