4 ms·

Also mentioned in the linked tutorial: Memory on early mini-computers was limited, sometimes only a few thousand characters. Mumps programs were loaded into me

by ptx 9y ago

Also mentioned in the linked tutorial: Memory on early mini-computers was limited, sometimes only a few thousand characters. Mumps programs were loaded into memory as source code rather than as compiled binary. This was done because it was determined that compiled Mumps programs would be far larger than the corresponding source code versions, especially if the source code employed size reducing abbreviations. So why didn't they use a bytecode interpreter, or at least a minifier (as is done with JavaScript), so that the programmer could keep the source code readable while still giving the interpreter a compact version? Would it have been too computationally expensive, or had people just not come up with the idea yet?

hyperpape 9y ago
I’m not at all sure, but poking around on Wikipedia suggests that the idea of bytecode interpreters might have dated to roughly the same time as MUMPS, which means it wouldn’t have necessarily been the obvious choice at that time. https://en.m.wikipedia.org/wiki/P-code_machine https://en.m.wikipedia.org/wiki/P-code_machine
epmatsw 9y ago
I’m going to go with they hadn’t come up with it yet. Modern M, at least at Epic, goes through a few levels of transpilation/compilation before ending up running in Java (I think that’s what Cache is now). New code isn’t really much worse than any other codebase IMO, but some of the old code there is crazy.
- dahakon 9y ago
  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.
dahakon 9y ago
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).

by ptx 9y ago

hyperpape 9y ago

I’m not at all sure, but poking around on Wikipedia suggests that the idea of bytecode interpreters might have dated to roughly the same time as MUMPS, which means it wouldn’t have necessarily been the obvious choice at that time. https://en.m.wikipedia.org/wiki/P-code_machine https://en.m.wikipedia.org/wiki/P-code_machine

epmatsw 9y ago

I’m going to go with they hadn’t come up with it yet. Modern M, at least at Epic, goes through a few levels of transpilation/compilation before ending up running in Java (I think that’s what Cache is now). New code isn’t really much worse than any other codebase IMO, but some of the old code there is crazy.

dahakon 9y ago
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.

dahakon 9y ago

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