Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to the Mumps Language (2017) [pdf]

cs.uni.edu

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Introduction to the Mumps Language (2017) [pdf]

#41

Post by epmatsw »

nwhatt wrote: post #21
epmatsw wrote: post #7

Mumps! There's a couple of docker images floating around out there for playing around in it. If anyone hasn't tried it, it's "fun". M's global data stores, weird scoping, and strange syntax make for some interesting problems :P https://hub.docker.com/r/tsafin/fis-gtm-env/ https://github.com/KRMAssociatesInc/docker-vista

Time to relive my Epic glory days. Seriously thanks for sharing these and appreciate your positive attitude.

I’m also an ex-Epic guy! It’s been a while since I played with these (M without EpicStudio is painful), but I think starting my career in M definitely helped me as a developer. Every time I hear someone complain about JS at work I’m like “If you think that’s crazy...”

Re: Introduction to the Mumps Language (2017) [pdf]

#42

Post by epmatsw »

ptx wrote: post #15
lgessler wrote: post #13

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 com…

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…

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.

Re: Introduction to the Mumps Language (2017) [pdf]

#43

Post by dahakon »

ptx wrote: post #15
lgessler wrote: post #13

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 com…

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…

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

Re: Introduction to the Mumps Language (2017) [pdf]

#44

Post by dahakon »

epmatsw wrote: post #42
ptx wrote: post #15

Earlier quoted context omitted.

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…

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.

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.

Re: Introduction to the Mumps Language (2017) [pdf]

#45

Post by twunde »

nwhatt wrote: post #20

This was posted last year. https://news.ycombinator.com/item?id=13859961 Does anyone know the story behind why these slides keep getting updated? Is this a databases class?

OP here. Looking at the author's CV (http://www.cs.uni.edu/~okane/resume.html), he's apparently written a book on Mumps revised in 2016 and presumably does some consulting as well. I would imagine that he incorporates it into at least one of the classes he teaches.

Re: Introduction to the Mumps Language (2017) [pdf]

#46

Post by nwhatt »

twunde wrote: post #45
nwhatt wrote: post #20

This was posted last year. https://news.ycombinator.com/item?id=13859961 Does anyone know the story behind why these slides keep getting updated? Is this a databases class?

OP here. Looking at the author's CV ( http://www.cs.uni.edu/~okane/resume.html ), he's apparently written a book on Mumps revised in 2016 and presumably does some consulting as well. I would imagine that he incorporates it into at least one of the classes he teaches.

He's apparently also a conservative fiction writer: http://threadsafebooks.com/?page_id=103

> Caution: Not recommended for moonbats, liberals, Clinton drones or Bernie’s Sandernistas.

Post reply on HN