dahakon

Some companies use their own higher-level layer on top of M. For example, FIS (banking software) uses Profile Scripting language which compiles to M which compiles to native machine code. Cache compiles to custom bytecode unrelated to Java or the Java Virtual Machine.

InterSystems Caché (one of the most popular Mumps versions today because InterSystems bought out a lot of the market) uses a bytecode interpreter. Your source goes in a ^ROUTINE global and the bytecode gets sent to a ^rOBJ global. And yes, the bytecode is usually much smaller since it is stripped of comments (and has other size optimizations).

Many of the M implementations today (Cache, MiniM, GT.M) support <= and >=. That's a recent development in the case of GT.M (mid 2014).

It has been done. FIS writes in a higher level language called Profile, which is compiled into M code that can be run by GT.M. https://en.wikipedia.org/wiki/Profile_Scripting_Language

If you put the money you save on Cache licenses toward better hardware, GT.M will be faster. Cache would still be necessary only for the most demanding cases.

The size limits were for object code, not source code. Comments and short command names have no impact on object code size. Ages ago, there was a 32KB object size limit. Now you can use up to about 8MB, which is large enough for pretty much all non-machine generated code. You can, of course, just use multiple routines to avoid the limit.

Times are changing.

Some functional areas use Hadoop and SQL now. New server development can be done in VisualStudio using Typescript (which gets converted to M).

There are automated tools to set and verify OS parameters.

Most new installs are Linux now. No one uses VMS today. HP-UX and Solaris will be out of use in a couple years. InterSystems licensing is why people continue to use AIX (you have to buy new licenses to switch from AIX to Linux).