Both are commercial software, have a low barrier to entry, are powerful enough to run the software for a nuclear power plant, have enough footguns to make this a terrible idea, and are so overused that it might be happening anyway.
But I do not think we will get rid of it any time soon.
More importantly there are lots of possibilities for disaster caused by the lack of typing, and complex Mathematica code quickly becomes impenetrable. Oh and version control systems are all but useless for the main ".nb" file format. Again, just like Excel.
I mean footguns in "Multiplication with multi-dimensional arrays"? That's a problem with Mathematica as opposed to what? Implementing it yourself? Using a third party library for that (that you have to also find and assess it's doing the right thing - which apparently numpy also doesn't as you say). Another specialized tool (and wouldn't that just have it's own footguns)?
If you just said "it has its set of caveats that you need to be careful about" that would be understandable.
But your wording/tone implies that Mathematica is somehow worse, and using it is (your words) "a terrible idea". So, what are those wonderful alternatives that don't have the same and much worse issues?
Neither of you have to be wrong, but insisting that Wolfram isn't liable for the situation isn't right. They built the moat, now they have to deal with people falling in on both sides.
You try it once, realize it's doing things element-wise, and then go lookup the proper product symbol (@ in numpy).
I don't know the motivation of the decision, but "ElementwiseProduct" is harder to type, and still has a lot of use cases.
myfunc[x_] := {2*x, 3*x};
myfnuc[5][[1]]
A similar problem comes from functions like Integrate, which become symbolic when Mathematica doesn‘t find a solution. So instead of a number, you might randomly get a symbolic expression. If you were trying to do a complicated computation with the result, this might now produce a symbolic result which is too big to fit your memory, filling up all RAM before the Mathematica kernel crashes.
I say it's good for high level experimentation because basically every function/transform/operation/solver you could ever need is present in the standard library [1] and stuff "just works". IMHO it's not really something you'd want in production but it lets you get an MVP for a given problem/solution working faster than any other tool I've used and all while rarely needing to even consider a 3rd party library. You can then focus on just mapping that MVP to whatever language/library/ecosystem you are actually working in.
But if I have an actually nasty equation to solve, like a system of differential equations with erf functions or something, I do actually go to wolfram alpha for help. It happens more often than I'd like, it's especially nice that no matter how nasty the equations you can still use units.
https://danuker.go.ro/programming-languages.html#non-math-ma...
So, it can express an average Rosetta Code non-math task in ~180 bytes, compared to Python, ~270, or Java, ~420. I guess this is because of its vast libraries of "batteries included".
Where it all falls apart is sharing. Nobody can run my creation, and even Mathematica Home Cloud is $194/year, which I find pretty steep, being used to free & libre software.
Monetizing is a whole different story, with commercial licenses starting at $1620/yr, which I could only justify if I already had a team wanting to learn the language and a large-ish profitable business service whose source code I wanted to convert to a locked-in solution for some reason.
They also run regular sales on all their products. Pi day is coming up.
> ImageInstanceQ[x,"caprine animal",RecognitionThreshold->i/100]
I think it's less misleading to say it has a generic image recognition function that supports goats, among many other recognition targets.