> Certainly, there are many functions that do what I need - but in my experience, the "higher" the level of the function is, the smaller the chances that it fullfills my needs.

Ok. It's hard to argue with a generalization absent more examples. I don't see DateListPlot as one that supports your point: it's relatively specific to plotting lists of dates. Whereas e.g. Classify and Predict are much more level: they're single-function wrappers around the most common use cases of machine learning.

But in a sense what you say must be true: the higher level you get, the more likely there will be some low-level detail you will not be able to change. That's kind of inevitable -- if you don't write it yourself, it is unlikely to do exactly what you want to do.

But that doesn't make the high level functions ridiculous, at all, or the entire project of building them ridiculous. When the high-level functions provide, they're beautiful. Plus, the low-level functions (in this case, Graphics) are still there.

Look, I don't want to discount your experience -- you're a customer, after all :). But it's a vast system that I know in some amount of detail, and despite my obvious bias, I think you are vastly overstating the case that it's a "demo language". People generally like to form opinions and then rant on the basis of little data, so I guess I'm challenging you there.

> Over the years I have come to appreciate Matlab. Like Mathematica, it also has some maddening idiosyncrasies [0] and is mostly closed source, but it let's me inspect its high level functions.

While not as friendly as seeing a source file, you can inspect almost all the high-level Mathematica code via tools like Spelunking: https://github.com/szhorvat/Spelunking (see my comment below)

> In comparison, Mathematica seems like a front-end to the kernel to me. It is not a proper IDE.

Agreed there, our 'package editor' isn't appropriate for serious programming. Workbench is fairly decent, but as you say, not free. Still, in my view Sublime* surpasses almost all other text editors, anyway, so it's much of a muchness. [* replace with Emacs or Vim to taste]

> File corruption and sign error bugs are absolutely not ok for software that I base my publications on, and I have not encountered them in the alternatives

I have often found network file systems (and their integration in modern OSes) to be unreliable with many kinds of software. Perhaps the FE could be more defensive about the OS lying to it ("I wrote those bytes, I promise"). Or perhaps there is a genuine bug where we don't check that some buffer got flushed successfully. Either way, I don't think this can be adduced in support of your crumbling foundations claim.

> I wonder why Wolfram Research is devoting so much energy into developing all these new, shiny features while the foundation is crumbling.

A function like TextString, which is new in 10.0.0, is not I think an indication of a crumbling foundation :). But sure, there are sections of entropying code. But we spring clean them with some regularity, at least.

One thing I think we can agree on: the whole grandiloquent project of Wolfram Language does make those flaws, when they come up, somehow infuriating. I wouldn't be infuriated if I found them in an open source project (partly because I could just contribute a fix, but also partly because my expectations wouldn't have been built up).

It makes working on the language a rollercoaster. When you add something really tight and clean, or when you rationalize some domain that was previously irrational, or when you see things fit together really beautifully, it can be incredibly satisfying. But when you see problems, or it lets you down, or you see when someone in the past took a shortcut, it can be very frustrating. Irrationally so.

[0], [2], ... wow... It reminds me of how the Glasgow Haskell Compiler used to delete your source code if it didn't type check. Apparently people didn't complain: "fair enough, I deserved it..." :)

[3] That's a glorious image I will carry with me for the rest of my life. Thank you.