Multiplication with multi-dimensional arrays comes to mind (not unlike numpy, actually). Rare bugs when simplifying symbolic expressions. Unconventional definitions of special functions. Probably several others that I am forgetting now.

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.

So, still like a 100x improvement in the areas you're concerned with, compared to using any standard programming language (to either re-implement the same stuff or use third-party libraries)?

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 access it's doing the right thing, apparently numpy also doesn't as you say). Another specialized tool (why wouldn't it 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?

Battles have been fought over dumber things. Writing system-critical code in Mathematica is probably "a terrible idea" for most applications that don't make enough money to justify paying for a license. For the people who do pay for that license... don't they reserve the right to complain about "multiplication with multi-dimensional arrays"?

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.

Indeed. I think they're experimenting with moatless because a worse thing than people complaining about your language/software is people not using it at all.

Why is element-wise multiplication for a multi-dimensional array a "footgun"?

You try it once, realize it's doing things element-wise, and then go lookup the proper product symbol (@ in numpy).

I think I mostly like that element of NumPy’s design. 2D arrays are in general not matrices. Images, for example, do not have matrix multiplication semantics.

I guess when you have a software package named "Mathematica", mathematicians expect to be able to take their math and transliterate it easily. Making them specify the "Dot" function would irk them.

I don't know the motivation of the decision, but "ElementwiseProduct" is harder to type, and still has a lot of use cases.

The error handling is atrocious. The language isn‘t just untyped - everything that‘s not defined is symbolic, and builtins will silently operate on symbolic expessions even if you don‘t expect them to. Consider this:

    myfunc[x_] := {2*x, 3*x};
    myfnuc[5][[1]]

Without the 'fnuc' typo, this would create the list {10, 15} and take the first part, giving 10. With the typo, it returns 5 without warning. Why? myfnuc[5] is now treated symbolically, and the first part/argument is 5.

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.

This sounds like the job for a linter or intellisense editor.