4 ms·

A lot of this language's unreadability is due to how it was originally interpreted instead of compiled because of the cost of memory at the time of its inventio

A lot of this language's unreadability is due to how it was originally interpreted instead of compiled because of the cost of memory at the time of its invention: > Since memory was tight originally, the language design for MUMPS valued very terse code. Thus, every MUMPS command or function name could be abbreviated from one to three letters in length, e.g. Quit (exit program) as Q, $P = $Piece function, R = Read command, $TR = $Translate function. Spaces and end-of-line markers are significant in MUMPS because line scope promoted the same terse language design. Thus, a single line of program code could express, with few characters, an idea for which other programming languages could require 5 to 10 times as many characters. Abbreviation was a common feature of languages designed in this period (e.g., FOCAL-69, early BASICs such as Tiny BASIC, etc.). An unfortunate side effect of this, coupled with the early need to write minimalist code, was that MUMPS programmers routinely did not comment code and used extensive abbreviations. This meant that even an expert MUMPS programmer could not just skim through a page of code to see its function but would have to analyze it line by line. https://en.wikipedia.org/wiki/MUMPS#Overview https://en.wikipedia.org/wiki/MUMPS#Overview I'll add that Wikipedia's take here is a little optimistic: perhaps it was true when MUMPS was invented that it could use one line to accomplish what would require "5 to 10 times as many characters" in other languages, but MUMPS's language constructs are by and large about as low level as assembly with a couple exceptions, so this is definitely no longer the case if we're comparing it to modern high level languages. In addition to Epic, the US Department of Veterans Affairs wrote their homegrown EMR in MUMPS. Their development group is here: https://groups.google.com/forum/#!forum/hardhats https://groups.google.com/forum/#!forum/hardhats

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).
flyinghamster 9y ago
>> Since memory was tight originally, the language design for MUMPS valued very terse code. Thus, every MUMPS command or function name could be abbreviated from one to three letters in length, e.g. Quit (exit program) as Q, $P = $Piece function, R = Read command, $TR = $Translate function. Spaces and end-of-line markers are significant in MUMPS because line scope promoted the same terse language design. That makes me think of TECO, where a string of commands resembled transmission line noise more than anything resembling program code. The most TECO that I ever learned was how to invoke VTEDIT, and I forgot that a long, long time ago. :)
telotortium 9y ago
> I'll add that Wikipedia's take here is a little optimistic: perhaps it was true when MUMPS was invented that it could use one line to accomplish what would require "5 to 10 times as many characters" in other languages, but MUMPS's language constructs are by and large about as low level as assembly with a couple exceptions, so this is definitely no longer the case if we're comparing it to modern high level languages. Eh, as someone who's used it professionally, I wouldn't compare it to assembly. It's more like Awk - fairly concise for a good deal of its intended uses (linewise text manipulation for Awk, trees for MUMPS) and horribly clunky for most everything else.

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

flyinghamster 9y ago

>> Since memory was tight originally, the language design for MUMPS valued very terse code. Thus, every MUMPS command or function name could be abbreviated from one to three letters in length, e.g. Quit (exit program) as Q, $P = $Piece function, R = Read command, $TR = $Translate function. Spaces and end-of-line markers are significant in MUMPS because line scope promoted the same terse language design. That makes me think of TECO, where a string of commands resembled transmission line noise more than anything resembling program code. The most TECO that I ever learned was how to invoke VTEDIT, and I forgot that a long, long time ago. :)

telotortium 9y ago

> I'll add that Wikipedia's take here is a little optimistic: perhaps it was true when MUMPS was invented that it could use one line to accomplish what would require "5 to 10 times as many characters" in other languages, but MUMPS's language constructs are by and large about as low level as assembly with a couple exceptions, so this is definitely no longer the case if we're comparing it to modern high level languages. Eh, as someone who's used it professionally, I wouldn't compare it to assembly. It's more like Awk - fairly concise for a good deal of its intended uses (linewise text manipulation for Awk, trees for MUMPS) and horribly clunky for most everything else.