In safety-critical systems where invalid data could kill someone, using a typeless, schema-less system with nonstandard language conventions as a starting point seems irresponsible. Why not start with a normalized relational database and a language designed to encapsulate and protect data from inadvertent data-entry or programming errors?
Because performance. Yes, Epic had to put extra work in to essentially build their own version of the SQL server black box, but now they are very difficult to compete with.
Epic doesn't use the Cache SQL API. Instead, they built an API on top of objectscript that stores fields safely. They have a staggering amount of code written in objectscript, and while it's true that "nothing will stop you" from writing directly to the underlying data oddly enough that doesn't seem to be an issue because developers can learn how to follow best practices.
There is nothing a hierarchical database can do that relational databases don't do better.
That's rather absolute. It seems performance is an area that hierarchical can be better, at least in certain use cases:
In tests simulating a data analysis application typical for a telecommunications software firm, Caché was 41% faster than Oracle when creating a data mart of mobile phone information. When the resulting data mart was queried using SQL, Caché’s response times ranged from 1.8 to 513 times faster. Clearly, Caché’s unique multidimensional data engine make it a good choice for applications that require rapid analysis of large amounts of data.
As a computer scientist, I was appalled by certain features of the language, particularly the ability to change a running program by executing a variable. That's a security nightmare, since you could effectively read a string (stored as a global or input from the console) and then execute it as MUMPS code.
Do you spend a lot of time being appalled? Many languages have this capability, including SQL and the C variants.
The possession of a book becomes a substitute for reading it. -- Anthony Burgess