• (cs) in reply to themagni
    Build in obfuscation? oO
    Appendix 7: An example of "traditional" M coding style
    %DTC ; SF/XAK - DATE/TIME OPERATIONS ;1/16/92  11:36 AM
         ;;19.0;VA FileMan;;Jul 14, 1992
         D    I 'X1!'X2 S X="" Q
         S X=X1 D H S X1=%H,X=X2,X2=%Y+1 D H S X=X1-%H,%Y=%Y+1&X2
         K %H,X1,X2 Q
    From http://www.faqs.org/faqs/m-technology-faq/part2/

    We need an old priest and a young priest.

    Wait. I...I understand what they're trying to do there. Not the text, but what the point was.

    MUMPS predates C, Unix, and just about everything else. This thing is ancient by anybody's standards.

    The original specs were for a PDP-7. The goddamned thing was put together with wire wrap! They couldn't have comments, because that would eat space. Condensing everything to one character saves space. They didn't have TBs of HDD space to run their programs.

    It was from a time when this was good code.


    It's not sane, but it makes sense. Or it did, 40 years ago. Now it's got senior managers and hospital bureaucrats who "have a computer system that works, has worked, and will continue to work." Think about how long it takes to get a surgical technique to change. Now apply that thinking to something that they don't understand.

    It makes you think - what will the programmers and engineers in 2047 think of our antiquated workmanship? "You have to remember that they had only 2 dimensional displays, and the neural interface was still 20 years away."

    ... and there will be still poor sods maintaining this M stuff.

    But seriously, after reading the wikipedia article I realized this M(UMPS) thingy has been designed at a medical lab by medical practioners. Now these guys were used to work on bodies which are - translated to IT terms - a bunch of persistent global variables with a persistent global naming space. So they designed for themselves a application programming environment where similar mental concepts apply and bingo M(UMPS) was born.

    The real WTF here is that this crap has not been retired in time. Now you cannot retire it anymore - too much (irretrievable) domain knowledge is encoded in M.

  • parv (unregistered) in reply to Jon

    brainfuck (or whitespace) language seems, though alomst as senseless, but more joyful.

  • (cs) in reply to earl
    I also worked there. Call it Ep*c Syst**s.

    So, yeah. All storage are in a giant automatically sparse global arrayo. So what you do is you have ^data[ attribute one, , , attribute four] = x

    where you aren't specifying attributes 2-3. The whole scheme works like this, so it's very hard to convert to SQL. That would be, for example, a way of storing data about someone if attribute one were SSN, etc.

    Better yet, the attributes themselves can be the data -- ie attribute 1 is SSN, attribute 2 is sex, etc. So you can actually store / query data from the attributes.

    NB: my syntax may be off, it's thankfully been years.

    Funny story: someone accidentally took down a major hospital by mistyping. Everything is done on production servers; this person was typing k ^varname to delete (k is short for kill = delete) over a remote connection. Instead of completing the varname and the attributes to delete, this person accidentally hit enter or the connection gremlin decided to screw him.

    What was sent over the terminal was: k ^enter

    which deletes all data. Everywhere. In the middle of a day in a hospital. There was a screamed "OH SHIT" then he ran down the hall to the recovery team.


    You think that is funny ? Remember, this a hospital you are talking about ... like, people's lifes are at stake !

  • (cs) in reply to Veinor

    Uh, plenty of languages can autocreate references. Whether or not its good practice is a different story. I avoid such seduction like the plague.

    And I think the point of local/global arrays was to underscore the part about no scoping rules, no references, etc.

  • (cs) in reply to gwenhwyfaer
    Also, because it bears saying:
    Anonymous Coward:
    it's like human languages. If you know 24 different words for snow, then you naturally pay more attention to snow because you have more ways to classify and decipher it
    Beware of referencing things you think you know without checking them first. Not to mention that not only have you inferred causation from correlation where not even correlation exists, you've done so backwards.

    On the language thingy: Unlike the English language, many languages do concatenate nouns and have therefore an infinite numbers of valid words in their vocabulary.

    I'll give you an example (with added hyphens between the originial nouns used to make up the concatenated noun):


    Translated: the badge of the cap of a captain of a steam ship on the river Danube. Pls note that in this case I have used the old german spelling in order to avoid abfuscation introduced by the current spelling.

    Having said all that: in the daily use of the german language one will usually find no more than a maximum of three concatenated nouns being by native german speakers and that rarely. But again: it is possible and legal.

  • me (unregistered) in reply to Hank Miller
    Hank Miller:
    VI is user friendly.


    Do the tutorial and in a matter of hours you will be faster than notepad

    Does not compute.

    A tutorial and "hours" to learn how to use a TEXT EDITOR? That's the antithesis of "user-friendly" to me.

    Let me guess, you see no reason why peoples' grandmas shouldn't be forced to use a command prompt, right?

    You are wrong. There are several different classes of user friendly. One is friendly to "grandma" (meaning those who rarely use a computer and are afraid of it). Another is friendly to those who are trying to get something done fast.

    Phone directory operators for instance work the same job for years. If the phone company can save 1/10th of a second on each directory assistance call they save millions each year. Thus in the context of phone operators a system that requires 1 month of intense training to use is user friendly - you can afford to make sure only those who have the training use it.

    Vi is like that. Hard to learn, but once you learn it very friendly. The only question is if it is worth learning. There are editors that use technology vi doesn't, and thus have a lot of power without being as hard to learn.

    Exactly. VI is kind of like chorded keyboards. When the PC was first being invented at SRI (yes, before xerox parc.. SRI is where the mouse was invented BTW and the beginings of GUIs, most of those researches ended up at parc) they had a text input keyboard and a chorded keyboard for commands. You would use one hand and "chord" commands (ie press multiple keys at the same time). It takes some time to learn, but the speed and ease once you learn it is amazing. VI is quite similar. There is a learning curve, but the benifits are great. I die a little inside whenever I see someone hitting backspace multile times to delete one word back or slowly highlighting multiple lines with a mouse just to cut a few lines to paste elsewhere.

    Another arguement (for GVIM at least, which is available for windows) is that it is a good UI. You can do the basic visual stuff you do with other text editors, and if you are in insert mode it will pretty much behave like any simple visual text editor (easy entry for begining users). But it also offers shortcuts for advanced users, so they can increase their productivity. Everytime I bring up easing use for advanced users I am reminded of a program for windows I am forced to use for one job (label design) that doesn't have a keyboard shortcut for print. The program is basically designed just to print and ctrl-P does nothing (nor does any other exoteric key combination), you are forced to go to file, down past 8 or more options to print everytime you want to print. The time wasted adds up very quickly.

    Which also reminds me.. I am reasonably sure that outlook 2002 did not have keyboard shortcuts for email, contacts, agenda etc but 2003 does (ctrl-1 2 3 etc). WTF? Finally introduce keyboard shortcuts in 2003?

  • squid (unregistered)

    i've seen MUMPS code once.. it looked like a drawing of a headache.. still, to its credit, the MUMPS application we've reverse engineered (i wasn't here when that happened) and are now re-writing in c# & java still runs better then the monstrosity we're creating..

  • Heinz Gorgon (unregistered) in reply to not a phb
    not a phb:
    Security by antiquation: who would want to hack such a system?

    If someone did, they would be haunted by nightmares of secret agents knocking at their doors, saying: "Mr. Anderson? We have a big file on you. But, we are willing to forget about everything... if you come and work on our MUMPS system!"

  • Heinz Gorgon (unregistered) in reply to rmr
    Ruby on MUMPS anyone?

    I have a great name for it: Rubella!

  • Bill (unregistered) in reply to akatherder

    Actually, Mumps -> M -> Cache for most current users. And Cache is perfectly adequate as a programming language. The built in database is nothing but a big B-tree that is part of the language. It really is quite fast at runtime and is kind of fun to code in. I've programmed in everything from FORTRAN IV on punch cards to AJAX, and Cache is just another language. (Speaking of AJAX, Cache has a library that makes it pretty simple. .csp files are Cache Server Pages. They've got a library that maps the DOM info very nicely. Supports vector graphics in Firefox.)

    It certainly does have weird syntax, but no worse than some other languages of its day. It has been around a long, long time. Anyway, I like it. I also like C and PHP and zsh and FORTRAN and Ada and ... I just like to program and after 35 years the language and environment don't matter to me as much as they used to.

  • Bill (unregistered) in reply to me

    vi(m) is not user friendly. It IS expert friendly.

  • squid (unregistered) in reply to Heinz Gorgon
    Heinz Gorgon:
    Ruby on MUMPS anyone?

    I have a great name for it: Rubella!

    how about RUMPS?

  • Anonymous (unregistered)
    CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.


    DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.

    DECLARATIONS: NONE. Everything dynamically created on first reference.

    Interestingly enough all of these are true for php as well.
  • jayson knight (unregistered) in reply to EvanED

    "Okay, that's really the only local tech company I know. And their Wikipedia entry confirms their use of MUMPS. (Sort of an ironic name for the health care industry, no?)"

    Check out their career page on the web...notice they don't mention that the language they use is MUMPS.

  • Kuba (unregistered) in reply to Stas
    Yes, it is ancient. Yes, it's a mindfuck to do anything in it. However, it is fairly powerful and works well with hierarchical data.
    Sounds to me like a really borked implementation of AllegroCache :) All in all, while M would be admittedly hard to "trivially" port to anything but lisp, I can't see it hard to get it running in lisp.

    In fact, people fluent in Allegro CL could probably whip a more-or-less complete implementation of M in less than a week. Heck, it could easily machine-translate M to CL first (using AllegroCache and AllegroServe), and then run from the translated files.

    In fact, it might be a nice product (no, I have no such intentions myself).

  • Jens Fudge (unregistered) in reply to tharfagreinir
    But they made sure that all new developers saw the carrot and understood that, if they worked hard enough, they might get to savor it one day.

    Pah, that's nothing special. I see carrots every day. Matter of fact, there's one right here in front of me as I'm typing this.

    I never ever before considered Visual Basic a carrot... But I think I do now... Poor Bryan

  • Mikolaj (unregistered)

    I just don't believe!!!!

    captcha: wigwam

  • Watson (unregistered) in reply to Stas
    works well with hierarchical data.
    So all it really needs is an XML parser...
  • (cs)

    I don't know if anyone has noticed this, but the Wikipedia article mentions that the legacy of MUMPS still lives in Intersystems Caché. That creeped me out a bit.


  • Geoff Connolly (unregistered) in reply to tharfagreinir

    I empatise with Bryan Mumps was my first Language back in 1990 I was supporting legacy systems from the 70's

    I have to say all the bad habits were there except storing programs in globals, thats taking the piss However I had the pleasure of debugging machine written code

    along with supporting icobol on MV systems and a Novel Networks and dos versions 3 & 5 (mumps doesnt work well with 4 - did anything? )

    There were only 3 members in the IT Dept and we had 6 sites of systems (1500 programs) all of which started off th same at one stage.

    I stayed for 5 years (no other jobs in Ireland at the time) In terms of knowledge it did me no good going into a Sco Unix & progress rdbms environment

    However if you can program in MUMPS you can program in anything.

    All languages can be abused however and I have seen some scary uses of include files and pre-processors in progress that comes close to the use of indirection in mumps


  • Matt (unregistered) in reply to triso

    Let's just analyse this daft comment shall we. Given the need to limit the risks and liabilities involved, and given their significant financial resources, surely it's pretty interesting that these financial services companies (and there are many of them), decided to use mumps as the basis of their core operation rather than any one of those super-fantastic "proper", mainstream programming languages and databases that I am sure they would have considered, evaluated, tested, etc. Financial Services institutions are not renouned for being willing to take many risks, let's face it. So....go figure....

  • Tragomaskhalos (unregistered) in reply to tharfagreinir

    Don't know if it's just me, but I've always been hugely creeped out just by the name of this language - who calls something after a disease, fer chrissakes ?

  • dkf (unregistered) in reply to Zygo
    Don't say things like that, someone might hear you and implement GOTO in Tcl...
    I said it because I've done it myself in the past. I know exactly what's involved. I know it's a terrible terrible idea once you start to really look at what is involved, especially with third-party libraries in the mix.

    Captcha: ewww (apt, so apt!)

  • devious (unregistered) in reply to Watson
    works well with hierarchical data.
    So all it really needs is an XML parser...
    Mumps/Cache data is a lot like working with the xml DOM.

    Except you have gigs of data that no dom could hold (you'd have to use sax or xmlreader).

  • (cs)

    I felt nasueous and slightly clammy after reading this one. Excuse me while I visit the bathroom.

  • no_star (unregistered) in reply to gwenhwyfaer
    Old Phart:
    Well, I'm almost 55 and don't mind working on stuff like this at all.

    Me too, and not just because I value job security over the chance to be a Star(tm). (After all, these pages are filled with the contributions of stars...)

    No, the reason I like doing maintenance programming is that it's actually fun (for me) working out what the hell is going on in a language, or a chunk of code, I've never seen before. Especially when you have a specific problem to solve; debugging other people's code (or even your own, once you've forgotten writing it) is like a cross between solving a crossword puzzle and weaving an enchantment. I'm looking at the MUMPS examples here and thinking "you know, this actually sounds like fun"...

    (Trouble is, I'm in Yorkshire, and I don't think anyone uses MUMPS around here...)

    Well when you're young you can actually choose wether you want to do something meaningful that moves people or you just want to geek on solving meaningless puzzles that no one really cares about. It's your choice what you want to do with your life.

    Of course at the age of 50+ you usually missed your chance so you spend the time solving silly puzzles much for only your own amusement.

  • Winston (unregistered) in reply to Remco G
    Remco G:
    Also, this reminds me of a friend, who recently finally landed a programming job (he didn't finish his degree) - and promptly got sent on a COBOL class. Poor guy.

    COBOL isn't that bad - it's merely just not fashionable or trendy.

  • craaazy (unregistered) in reply to Zygo
    Your entire rant is predicated on one huge assumption--that most MUMPS code is compiled

    The post I replied to mentioned a compiler. Obviously then, in his case, some stuff is compliled. That it's compiled badly unless you abuse the language is the compiler's fault, and not a feature of the language.

    , and most MUMPS code maintenance involves writing new code in some other language.
    I merely pointed out that many other languages also started out with huge limitations, but such limitations were shed, as 1) the language evolved - if a language doesn't evolve, that's not a feature 2) IDEs evolved - if a horrible-to-use texteditor is part of the language, something is wrong. A smart IDE could even do some amount of the next point; 3) precompilation - plenty languages do convert user input to some intermediary format that is a lot less nice to program in. Java bytecode springs to mind, c++, etc.
    To the second point, there are very few successes among those who try to rewrite an existing system with a new language that compiles to the old one. Even fewer that involve interoperation between a dozen vendors. There would have to be massive external pressures against development on the old system while at the same time massive value in maintaining the old system intact. That set of circumstances is rare.

    To the first point, everything I've read so far suggests that MUMPS is normally not compiled, not even to the extent that Perl code is compiled to bytecode immediately before execution. Some implementations don't even do that. It seems that MUMPS has some level of bytecode compilation but only under certain circumstances where the cost of compilation is expected to be recovered by savings during execution.

    So there's no precompilation step, and no way to avoid having to directly understand machine-generated 1970's MUMPS code if you are maintaining this crap.

    You misunderstand the term pre-compilation. It's just something that happens before the compiler is called. If there's no compiler, but an interpreter, you can still call it a precompiler.

    How about this example; java is interpreted, or at best JIT compiled. Evenso, many IDEs for java allow you to do

    • refactoring
    • context highlighting
    • pretty printing
    • validation
    • nice lists to pick method/classnames, etc.

    None of this modifies the language or the compiler/interpreter. It's all syntactic sugar.

    It should be trivial to add a undo-pretty-print-before-saving-source-to-weird-global-array step.

  • Hanno (unregistered)

    Reading about this brought back images of the movie "Nineteen Eighty-Four", as Big Brother keep the working class under his control by inventing a language that makes revolt impossible. The language is called NEWSPEAK.

    Mumps doubleplusgood. Miniluv say coders must bellyfeel Mumps. BB is watching you.

  • deltreme (unregistered)

    From the FAQ (http://www.faqs.org/faqs/m-technology-faq/part1/):

    John Lewkowicz:
    When I was first at the VA, Greg here gave me a 1 page batch of M code and asked if I could do it any faster in C. Two weeks, a lot of aspirin, and two compilers later, I had 'barely' working code (it would only run *once*).

    Before I die I would like to see that C program :D

  • Fuzz_x (unregistered)

    Oh god!!

    Little times in my geeky life I've heard a WTF that actually make me wanna puke...

  • (cs) in reply to Top Cod3r

    Just looked on jobserve, there are 7 jobs advertised for Mumps developers - frightening...

  • (cs) in reply to fennec
    DECLARATIONS: NONE. Everything dynamically created on first reference.
    Kinda like Perl.
    Or PHP, or JavaScript
    <rant> Actually not really in javascript and Firefox complains when you activate strict warnings. Javascript works like that:
    • If a variable is prefixed by the keyword var in an affectation statement (e.g. var foo = 3;) and doesn't already exist in the current scope, then it's created in the current lexical scope (if it already exists, a simple affectation is generated)

    • If a variable isn't prefixed by the keyword var in an affectation (e.g. foo = 3;) then the engine will walk the scope chain looking for it in every upper scope. If it finds a variable with the same name in the scope chain then it uses it, if it doesn't then it creates the variable in the global scope

    This means that creating variables without using var creates unmarked global variables from the middle of your code do not ever do it. Only bozos create variables in javascript without using var </rant>

    An erstwhile toy language like PHP (any one remember PHP2?) has been extended so much that it's getting almost enterprisy.
    Beg to differ sir, PHP is still a toy language.

    edit: god damn it, give me my inline code blocks back!

  • meh (unregistered) in reply to Top Cod3r
    Top Cod3r:
    Ontario Systems is the only company I have heard of who use MUMPS. I thought this was supposed to be anonymous for the companies! :)

    It is also used for a lot of stuff in UK healthcare, and we're pretty annoyed about it too. Our govt. keeps throwing lot of money at NHS IT projects which inevitably result in failure and whichever consultants showed up being paid double to leave.

  • OldAndInTheCode (unregistered)

    Well, I've coded in C, VB, Oracle SQL, VB and MUMPS not to mention AWK, NAWK, etc... Frankly any poorly implemented language can be a support nightmare. VB is probably the worst as it has built in memory leaks and no way to get the Gate keeper to fix them when there's more money to be had in something new. Oracle's better now, but I've seen some butt ugly implementations. "M" or Cache is quite different than MUMPS for a number of reasons. The most notable being direct Objectscript mapping via Cache server pages that provide fairly seamless web access to the MUMPS database. The future of MUMPS is to create external access that keeps people away from the command line. Any decent MUMPS programmer knows that you never do a direct kill you always read your line into a variable and Xecute it that way fat finger doesn't get stuck in everyone's eye. (R X<cr> K ^GLO(SUB0,SUB1)<cr> X X<cr>). Properly implemented MUMPS code can whip the pants off of any other database hands down. Poorly implemented it's a mess. Also MUMPS hasn't had to use single line execution for like 15 years - ever since block structuring was brought in. But hey if you kiddies don't want toprogram it that's ok by me. Puts me on more demand to maintain all that old legacy code and let's face it - a Job's a job - can you say 6 figure income? Now go run off and play in the JAVA sonny.

  • dreadlocks (unregistered) in reply to Hans
    I don't know if anyone has noticed this, but the Wikipedia article mentions that the legacy of MUMPS still lives in Intersystems Caché. That creeped me out a bit.


    The wikipedia article also mentions this article.

  • Anonymous (unregistered)

    Several people correctly guessed the company correctly.

    Some people are defending the language, but one of the indefensible aspects of MUMPS is the lack of any built in security. Your medical records are likely to be in a MUMPS pseudodatabase. Any MUMPS "user" can read and delete everything. That might have not been bad if there was a security wrapper around the MUMPS environment, but that "client-server" model with telnet made the lack of security or access control in MUMPS even worse.

    And for those who say that it's old, and MUMPS was all that was available. There is a lot of active development going on there in MUMPS. The size of this company had increased in size by about 500% in a period of one or two years. How long can you do new development in a relic from the 70s? It is way beyond "maintenance programming". If you're doing active, new development in an awful programming language with severe limitations, perhaps you should consider changing the programming language.

    Job security by working with something that is obsolete and stupid isn't worth it. To me, it's way more important to be doing something that I want to do. I quit my job at that company upon finding job where I could develop software in C for embedded devices that run Linux. I am much happier. I do have this experience on my resume.

  • old mumps guy (unregistered) in reply to meh

    You would be surprised where mumps still runs today. Most of the code was built on the old PDP 11 version (compiled at runtime) with either Greystone or MVS ansi standard versions. The code was migrated to (fast mumps) in the mid 80's to run on DEC VAX hardware. There are two big companies on the east coast that still sell systems (legacy products)that i'm aware of. Mckesson still sells its legacy HIS system and is in over half the hospitals in the US and an old company (National Computer Systems) acquired by Sun Guard in the 90's still has its Trust Operations product in a majority of all US Banks. There was nothing more painful than coding in the early versions of mumps were memory was an issue and code was written with single charachter commands calling single charachter variables and read accross the page like a book. Developers crammed the most commands into one line as possible.

  • Guess what? (unregistered)

    From Wikipedia:

    "MUMPS was developed by Neil Pappalardo and colleagues in Dr Octo Barnett's animal lab at Massachusetts General Hospital (MGH) in Boston during 1966 and 1967."

    Neil Pappalardo ended up founding MEDITECH and now makes more money than all of you combined.


  • cynd (unregistered) in reply to akatherder

    Sometimes, when you hate your job, you're too exhausted to even think about doing ANYTHING in your spare time.

    CAPTCHA: onomatopoeia - PING!

  • Brady (unregistered)

    During my career as a developer I have worked with MUMPS, VB, Delphi, .NET and Java. Just like all programming languages MUMPS has both advantages and disadvantages but when used effectively MUMPS is a superb programming environment.

    I found your article to be ignorant and naive at best. The protagonist in your story was most likely unhappy due more to his employer rather than the programming language he had to use each day.

  • iogy (unregistered) in reply to OldAndInTheCode
    Properly implemented MUMPS code can whip the pants off of any other database hands down.
    So can x86 assembly - but you don't want to work directly with that, either. Which makes me wonder if MUMPS isn't one of the first platform-on-a-platform languages.
  • (cs) in reply to asuffield
    The editor made extensive use of DEC VT 220 keys as shortcuts; these keys, naturally, did not exist on any modern keyboard. Things that we take for granted (the Enter key, for example) required a bizarre set of escape commands to be entered.

    IBM mainframes still do this.

    And don't I know it! I still tend to use the NumPad's Enter-key when I want to execute a command on the CL. That's what did the trick in my trusted 3270 terminal (that or the right Ctrl-key IIRC)

    When I first started in IT (gosh, it's been 10 years now...) I was placed on a "project" as a PacBase programmer. Anyone ever heard of that language? Apparently it is still supported. There's even a VisualAge for PacBase which interfaces with UML modelling tools.

    Of course we had none of that newfangled mumbojumbo.

  • Lianne (unregistered) in reply to cynd

    I am currently a programmer for MEDITECH, using the proprietary language MAGIC (a MUMPS descendant). These languages are specialized, and they get the job done - thus what MEDITECH made $344 MILLION in 2006.

    Not to mention that Neil wrote this language fresh out of college (something I couldn't even IMAGINE doing) and made a living by USING IT himself! He didn't create it to torture other programmers. He used it, improved it, and began a technological revolution that created thousands of jobs and spread around the world.

    He's good to his employees, and is STILL working here, creating new products and languages, and improving his old stuff.

    If you don't like working with the language, then quit. Don't bash a man's life's work not even knowing the story.


  • Kenneth Spicer (unregistered)

    Okay. Time for me to come clean. I'm one of the blokes who wrote MUMPS interpreters and compilers to feed myself while I went to college. I was a systems programmer, not applications. So I worked on the logic engine. Yes. It is an interpretive language like BASIC. So compiler optimization is an oxy-moron. We tried C+'s YACC, but it didn't do a very good job. So our interpreter was written in PL/1 and Assembler. The machines were slow and memory was expensive. GUI was nothing more than a mess of code in Steve Job's hands at the time, so everything was line oriented. If you're into reading, I'd suggest Tracy Kidder's "Soul of a new machine" to get a sense of the times. I've also seen a 16 year old kid write a kermit interface in MUMPS in an afternoon. So it was relatively fast to code. Now it's largely a data server for a GUI front end. As I said, I worked Oracle in my younger years, and internally, Oracle and MUMPS use the same data structures (a linked list). Joe-user is not permitted to Xecute MUMPS logic in variables in the current environment, and all transactions are journaled. Only 'GOD level' users can Xecute M code directly. We are very rare, and we know each other well (it's a small community). Even normal users are carefully registered and audited by the FBI. Can you say the same for your Credit Card Records? Yes, I can read that MUMPS snippet given earlier. It was a date conversion routine. MUMPS is self-organizing (you never have to sort anything). The programmer used variables starting with % because the stack is indexed alphabetically and % would get a 'hit' sooner than 'ZED'. The objective of the spagetti code was speed, not documentation. This stuff is low level, and even a small improvement could mean huge gains overall. I've written SQL and many other structured interpreters in MUMPS. They work, but I haven't seen enough improvement in programmer efficiency to impliment them. Given the nature of the native database, M is absolutely fantastic for AI. The internal global structure is a b-tree. If you want a MUMPS job, you might try Internationally. Since M has no english verbs, a MUMPS programmer can work anywhere in the world.

    So chant all you want about C++ and JAVA my children. For you stand on the shoulders of giants.

  • kiwi (unregistered)
    MUMPS was developed by Neil Pappalardo and colleagues in Dr Octo Barnett's animal lab at Massachusetts General Hospital (MGH) in Boston during 1966 and 1967. The original MUMPS system was, like Unix a few years later, built on a spare DEC PDP-7.

    Says it all really...

    Personally i worked in a shop for 5 years that used their own proprietry development-language/environment....why didnt i leave sooner, well because no-one else was daft enough to start the money was actually quite good.

  • (cs)

    Thanks to the people who commented on the Vi thing.

    The initial problem, it seems, was that peoples' definition of "user-friendly" can differ. My definition has always been a program that you can sit a person unfamiliar with it down in front of, and there will be enough cues (via visual analogy or blatant helper text) to allow said unfamiliar user to get their work done. My typical definition doesn't have anything to do with somebody who knows it in and out like the back of their hand -- if a program is fast, convenient, and easy once you have done a multi-hour tutorial and have memorized all the shortcuts, then I wouldn't call it necessarily "user-friendly," I'd just call it "incredibly powerful and efficient." But to be "user-friendly" to me, it has to do at least something to help the user figure out how to accomplish what they want to accomplish, and not run off a Byzantine collection of hotkeys and shortcuts :)

    Vi is certainly incredibly powerful once you learn it. But I can't ever see anybody inexperienced with it just sitting down and using it with any degree of success, hence my comment about its lack of user-friendliness.

  • Milkshake (unregistered)

    Anyone who doubts the existence of this language... do a search for "MUMPS" on Monster.com. Currently, they show 39 positions available.

  • maninthemachine (unregistered)

    Defender of MUMPS I am. I've been a coder in MUMPS, M, M Technology, whatever you want to call it. for roughly 10 years, I hated it, loved it, I get along with it. The shop I for work has done a good job in preparing this 40 year old language for the present. They have built an OOE that sits on top of the true M platform, the have a very swift DBMS and try their hardest to make it look relational, they have JDBC and ODBC drivers, MQ series, and there's nothing we cannot talk to...plus it's fast as hell.

    There are a ton of mainstream enterprises that run M, from big name banks with 20 million plus customers with millions of transaction per day (and they are secure as fort knox), to big name insurance companies, and some of them fairly new into the world. With M, they can run their whole system from a laptop if they wanted to...I SYN.

    Bryan could land a job with a top-tier bank if he wanted too but probably doesn't own a tie.

  • grammar nazi (unregistered)

    I couldn't bring myself to read this story because I see three or four large mistakes in the blurb alone!

    Proof your shit Alex! If you're too lazy, send it to me.


Leave a comment on “A Case of the MUMPS”

Log In or post as a guest

Replying to comment #:

« Return to Article