Could you expand on, for a person who only dabbled with Mathematica some time back, what that niche is?

Mathematica usage appears widespread in my own domain of theoretical physics, but it is probably used in elsewhere as well.

A good niche for mathematica is finance: type in your equations, tell it what "type" your variables are, let it solve them. Let the machine get it right.

Do you have a good example of this beyond Black Scholes and with eg real world market data and picking a portfolio of ETFs, say?

Yes but I can't legally tell you (weird exotics and fixed income models with lots of daycounts that you'll make a mistake on are a hint)

As a random computer engineer, I find using mathematica to be extremely convenient when trying to grok a problem or lay out a first attempt at a solution. Of course it isn't really helpful when dealing with glue issues (i.e. making software work together) but it is really good at letting you experiment at a high level and put together an algorithm to process/interpret/transform/generate some data.

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.

1. https://reference.wolfram.com/language/

It used to be the big differentiator was the ability to do symbolic math and actually solve equations. Maple could also do it, as could the TI89, so I never really got into it. It was just a huge difference from Matlab.

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.

The reason I might find Mathematica interesting is its language, which I found to be on my popularity-brevity Pareto frontier.

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.

I bought a one time home license for like $200ish a number of years ago and it still works, and will likely work forever. I have transferred it between computers and even OSes over time. Worth it. I pay as much for JetBrains annuallt and way more for the Adobe stuff I use maybe twice a year.

Are one-time licenses a thing of the past ?

A permanent home/hobby license for Desktop costs $387, as far as I can tell. It only allows 4 cores being used, and for more you need to buy Core Extensions.

They do make some attempts on their web site to steer you into the yearly subscription, or into buying a yearly support contract if you do buy a permanent license, so some folks might not realize the permanent licenses are still available without a support contract.

They also run regular sales on all their products. Pi day is coming up.

It's extremely versatile which makes it able to solve some neat problems. My favorite example is this was a CodeGolf to find if a goat in an image is upside down. - https://codegolf.stackexchange.com/questions/71631/upgoat-or...

For those who didn't click: Mathematica stdlib contains a "detect goat" function.

That's not quite true. The function call in question is

> 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.

Could you illustrate some footguns of Mathematica/Wolfram Language?

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.