A Case of the MUMPS

« Return to Article
  • tharfagreinir 2007-02-13 13:07
    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.
  • Ebs2002 2007-02-13 13:09
    ...

    Wow.

    I'm not surprised this is happening, but...wow. I feel bad for Bryan, not just because he had to work here, but because he can't find something else because he stayed for 2 years.

    captcha:muhahaha, what I'm sure the management is thinking to themselves when someone tries to quit: "muhahaha, you'll be back, there's nowhere else for you to work!"
  • Craig 2007-02-13 13:11
    That has to be one of the most horrid and evil stories I have ever heard.
  • the-moss 2007-02-13 13:12
    This company wouldn't be based in Madison, Wi would they?

    I think I also worked for them straight out of college.. I only lasted a year though.
  • Remco G 2007-02-13 13:14
    See its Wikipedia page: http://en.wikipedia.org/wiki/MUMPS.

    Looks like the article wasn't exaggerated one bit. That Wikipedia article is full of wondrous WTFs by itself.
  • EvanED 2007-02-13 13:14
    the-moss:
    This company wouldn't be based in Madison, Wi would they?

    I think I also worked for them straight out of college.. I only lasted a year though.


    As someone currently attending UW, I must know who these people are so I can avoid them.
  • Remco G 2007-02-13 13:16
    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.
  • the-moss 2007-02-13 13:18
    You know someone that works there (everyone in Madison does). They are building a massive campus in Verona, and the company is a huge success. But it sucks being a developer there.
  • Top Cod3r 2007-02-13 13:19
    Ontario Systems is the only company I have heard of who use MUMPS. I thought this was supposed to be anonymous for the companies! :)
  • z 2007-02-13 13:20
    Nice Google ad on the right:

    MUMPS to Java and RDBMS
    Automatic migration from MUMPS to Java and relational databases

    Salvation? :)
  • Rick 2007-02-13 13:21
    You know, some days the stories are kind of bland, boring, so-what. This is not one of those days.

    I had to shake my head at every single part of the story. My favorite part was reading the UNIX login and unencrypted password from a file. Obviously, security is of paramount important to these guys...
  • the-moss 2007-02-13 13:22
    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! :)


    Makes me think it is possible that it was my old company.. What they use isn't called MUMPS anymore, it's called 'M'. But it from what I remember M is just what the newer versions of MUMPS are called.
  • not a phb 2007-02-13 13:24
    Rick:
    You know, some days the stories are kind of bland, boring, so-what. This is not one of those days.

    I had to shake my head at every single part of the story. My favorite part was reading the UNIX login and unencrypted password from a file. Obviously, security is of paramount important to these guys...

    Security by antiquation: who would want to hack such a system?
  • EvanED 2007-02-13 13:25
    the-moss:
    You know someone that works there (everyone in Madison does). They are building a massive campus in Verona, and the company is a huge success. But it sucks being a developer there.


    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?)
  • Eeby 2007-02-13 13:28
    It sucks that he had such a horrible experience and now he's having a hard time finding a job. I'd suggest that he get involved in an open source project that uses a more widely-known language. Then he can chalk up some experience and have examples of his work out in the public sphere.
  • Sgt. Zim 2007-02-13 13:31
    the-moss:
    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! :)


    Makes me think it is possible that it was my old company.. What they use isn't called MUMPS anymore, it's called 'M'. But it from what I remember M is just what the newer versions of MUMPS are called.

    'M' is what happened when the current owners of the "technology" decided that "MUMPS" had negative connotations... The latest version of the system has layers upon layers of WTF-ey goodness on top; an "SQL Projection", a VB-like language, etc ... All built on top of good ol' M. I'd suggest googling Caché (that accent is important).

    Note, also, that if you happen to be involved in the VA hospital system (that's the Veteran's Administration for those outside the US), all of your data is in a MUMPS-base somewhere ... Unless it was on that thumb drive that got stolen, but that's another story.

    I, too, am unfortunate enough to be in a MUMPS-shop, with no light at the end of the tunnel, unless it's a train.

    Edit: And in my experience, everyone that uses it either absolutely hates it, or has consumed the Kool-Aid and absolutely loves it, and will extol its "virtues" at great length. There doesn't seem to be a middle ground with this pile of crap.
  • asuffield 2007-02-13 13:32
    Much of this stuff is not new (sadly). And I say that in the full knowledge that MUMPS is from the 1970s.


    The primary design goal MUMPS was to create code that, once written, can never be maintained by anyone ever again.


    APL.


    CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.


    Numerous flavours of BASIC did this.


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


    Not a WTF.


    LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.


    Many forms of BASIC did this, only without the ability to use string keys.


    Within each application lived hundreds of modules, and within each module lived thousands of routines. All of these routines shared the same environment. To ensure that global arrays and code didn’t get mixed up, a strict naming convention was followed. Each routine name was no more than eight characters, and consisted of a two-character application identifier, a two-character module identifier, and a two-character routine identifier.


    This one is right out of the system/360 playbook, and probably goes back even further.


    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.

  • dolo54 2007-02-13 13:33
    From the wiki: "The M syntax allows multiple commands to appear on a line, grouped into procedures (subroutines) in a fashion similar to most structured programming systems.

    In MUMPS syntax, some spaces are significant; they are not merely whitespace. There are contexts in which a pair of spaces has a different syntactic significance than a single space. However, extra spaces (in this context not syntactically significant) may always be added between commands for clarity, up to the line length limit in an implementation. Lines are syntactically significant, and carriage returns and linefeeds are not treated as white space; they are statement/function terminators. There is no requirement to put semicolons at the end of commands, and lines may be explicitly continued when needed."

    HOLEEE GUACOMOLEE BATMAN!!! A Russian goolag would be preferable to MUMPs developer job.
  • Veinor 2007-02-13 13:34
    DECLARATIONS: NONE. Everything dynamically created on first reference.
    Kinda like Perl.
    LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.
    Perl's arrays and hashes, though you can't auto-convert between the two (not in the expected way, at least.)
    DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.
    Err... I've never seen Perl auto-truncate, but yeah. The rest of the stuff, though... totally dumbass
  • Danny 2007-02-13 13:35
    Bah! As an intern I got a desk, a chair and a COBOL manual on the first day, and that was great (back in 1978). I also wrote a small program in MUMPS in the 80s and it was no big deal.

    MUMPS may not be buzzword-compatible but it was a good option in the 70s and early 80s when most languages (C, Pascal, Basic) supported only sequential and random access. MUMPS has a very simple yet powerful indexed access - ^Table("Key"). You could also get decent multiuser support from a 16 bit microprocessor (like the good old brain-dead 286). COBOL was another option, but is it really a better language?
  • themagni 2007-02-13 13:36
    z:
    Nice Google ad on the right:

    MUMPS to Java and RDBMS
    Automatic migration from MUMPS to Java and relational databases

    Salvation? :)


    Java? - The savior?
    Wish for a merciful death.
    I weep tears of blood.
  • Jack 2007-02-13 13:36
    This story has to be about IDX/GE Centricity. Their systems are so backwards but hospitals have to use it a lot of times because there simply isn't a better alternative.

  • Sgt. Zim 2007-02-13 13:40
    asuffield:

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


    Not a WTF.

    In theory. When it works. But when it doesn't ... Get the bandages, because your eyes will start bleeding.
  • Havic 2007-02-13 13:42
    > Note, also, that if you happen to be involved in the VA
    > hospital system (that's the Veteran's Administration for
    > those outside the US), all of your data is in a MUMPS-base
    > somewhere...

    I worked with the VA for a few years and fortunately never encountered Mumps. All of my work was in C# or older ASP with a database of our choosing.
  • Top Cod3r 2007-02-13 13:42
    All MUMPS code was stored in a Global Array named ^ROUTINES. The only code that existed outside of this array was stored in “Application Startup” codefiles, each containing a single line of code: X(^ROUTINES("XSTARTGB")). The only difference between each file was the last two characters, or, the application identifier.


    First of all, for all you newbies out there, you want to store your code in a global array for performance optimization purposes. You see global arrays get optimized by the compiler making them as much as twice as fast as normal arrays.

    And the code in the Application Startup codefiles was probably put there for flexibility purposes, since startup code only gets executed once it doesnt need the performance boost offered by global arrays.

    The only WTF about this is why you guys all think this is a WTF. Maybe you just dont understand MUMPS.
  • Flash 2007-02-13 13:43
    My first job out of college (25 years ago) was a COBOL programming position. (I worked the summer before on a Tandem minicomputer, but I didn't realize at the time how cool that platform was.) I stopped in at the workplace two weeks before my start date to pick up some code examples. (My only experience with COBOL was one course in college, and I wanted to brush up.)

    I saw all sorts of WTF code. I figured it wasn't as bad as I thought, so on the first day of work I asked all sorts of questions about programming practices there. I got all the wrong answers.

    It wasn't easy to quit my first-job-out-of-college on the second day, but I did it. And I was lucky enough to avoid Bryan's fate. I've never regretted that move.

    [And this grammar nazi likes an essay where "caret" and "carrot" are used and spelled correctly!]
  • Porkchop 2007-02-13 13:44
    Sometimes I feel like the only person over 30 on the internet.

    "Back in the day" MUMPS was considered state-of-the-art. Of course, so were 300 baud modems.

    The only real problem I saw in all of this was a company that lacked the vision to build an upgrade path for these legacy applications.
  • Jeff S 2007-02-13 13:46
    I like the spec indicates (if I am reading it correctly) that block of code in FOR loops and IF statements must all be on one single line. And we argue over where to put the curly braces!!! Maybe you can use GOTO's to avoid this?
  • TomTheGeek 2007-02-13 13:49
    Wow, how many more of you are from Madison, WI? I saw like three people in the first few posts.

    Just seems like a above average number of people from the same place.

    Is it the VA hospital in Madison that uses MUMPS? I came dangerously close to working for them, I worked for the school of Nursing in the Hospital.
  • CDarklock 2007-02-13 13:51
    Porkchop:
    Sometimes I feel like the only person over 30 on the internet.


    I usually feel like the only person who is AND ACTS over 30.

    There are plenty of old farts on the internet. They're just all trying to hook up with teenagers on MySpace.
  • the-moss 2007-02-13 13:55
    The company I worked for was a WTF.

    MUMPS had some WTF's about it. The big one I remember is being told to keep comments to a minimum because they slow down the code's execution.

    It also had some cool features. Being able to store code in a variable and execute it made it easy to customize the app for different clients.
  • cob666 2007-02-13 13:57
    Back before I was a 'real' developer I was working for a network integration company in the Boston area. We were tasked with a rather large netware upgrade for a Partners facility in Newton (Partners was partly founded by the Mass General Hospital). One of the IT managers found out that I was the 'developer' on the team and tried to get me to jump ship and work for them. In my initial very informal first interview with one of the managers there I was told that they maintain applications written in MUMPS and was told how incredible and deliciously awesome it was to work with such a powerful language that was designed from the ground up for the medical field. I did some talking to a couple of the developers there and was amazed by how much they HATED their jobs.

    Needless to say, I didn't take the job.
  • Reed 2007-02-13 13:57
    Umm... what's so scary about MUMPS?? Looks like quite a few other crappy database resident languages. Epic in Madison?
  • TB 2007-02-13 13:58
    I actually almost got a MUMPS job when I graduated in 1989, from a company in Kensington, MD. They wrote healthcare software. Thankfully, it didn't work out, becaue I would most likely have taken the job, due to poor economic conditions then (and poor interviewing skills at the time on my part).

    This article makes me glad it didn't work out!
  • rmr 2007-02-13 13:58
    Remco G:
    See its Wikipedia page: http://en.wikipedia.org/wiki/MUMPS.

    Looks like the article wasn't exaggerated one bit. That Wikipedia article is full of wondrous WTFs by itself.

    At risk of being thoroughly ridiculed, I actually like the sound of the overall concept. There are clearly some major WTF's in the implementation (i.e. an else must be followed by two spaces) but I like the idea of having a transparent database accessible through some syntactic sugar. I can imagine a web development framework that provided the same feature being extremely popular. Ruby on MUMPS anyone?
  • Zonkers 2007-02-13 14:02
    That is a sad story. Keep at it Byran! I can relate a bit.

    I had a similar experience, but with COBOL, I worked my first job out of college for 1 year working on a system that wasn't nearly as bad as that but antiquated and full of WTF's none the less. Some of the stuff that I had to code was basically writing a relational database that was full of business logic that sat upon ISAM and flat files all written in COBOL! It still makes my head hurt remembering that garbage. I hated that job.

    I got out the same way, no job prospects and for a while it looked pretty bleak. It took me about 8 months to find another job (this was in 1996), this time working with modern day tools with a saner environment. There were a couple of times when I wanted to just go into another industry because I thought I might just end up working at another brain dead shop. I'm so glad that I stuck with it.

    Maybe play up your experience in MUMPS. Stress how you had to handle a lot of complexity in that environment that modern environments hide from developers. If you spin it right you might sound like a genius developer for being able to write anything at all in it, which is probably true. But it might be better just to say that MUMPS is a highly specialized language for such and such, etc. etc.
  • curmudgeon 2007-02-13 14:02
    His job skills are at least a little portable: a lot of the skills one needs to maintain and write MUMPS are similar to those need to maintain Perl code!
  • Seaph 2007-02-13 14:09
    Wow, how many more of you are from Madison, WI? I saw like three people in the first few posts.

    Just seems like a above average number of people from the same place.

    Is it the VA hospital in Madison that uses MUMPS? I came dangerously close to working for them, I worked for the school of Nursing in the Hospital.


    My guess would be that people are refering to Epic Systems Corporation, who makes software for the healthcare industry, but I could be wrong.
  • DaveAronson 2007-02-13 14:10
    There are a LOT of companies using MUMPS in the Philadelphia (PA USA) area. The main industries there that need programmers, are medical, financial, and cable TV.

    Re Cache', that explains a lot. I was contacted by one of their recruiters a few years back. They want you to take a test. They fax you the test, and want you to fax back your results! Silly me, I fell for it and did it. Or maybe they were serious.

    Captcha: dubya -- don't get me started on a comparison of him and MUMPS....
  • vic 2007-02-13 14:14
    From the FAQ :

    prints a table of primes,including code to format it neatly into columns
    f p=2,3:2 s q=1 x "f f=3:2 q:f*f>p!'q s q=p#f" w:q p,?$x\8+1*8

    Almost as friendly as perl.
  • darin 2007-02-13 14:14
    A friend of mine did his PhD thesis on code restructing and tools. Instead of making up fictitious examples, he needed to find real world programs with the most convoluted spaghetti-like call structures he could. His search ended when he found a MUMPS program from a hospital.

    When printed out in a visualizer, it looked like the result of putting cobwebs in a blender. His goal was to automatically try to reorganize the code to give it a more understandable structure. But first he had to understand the code himself, and try some manual refactoring. I think this was when he learned the phrase "WTF?".

    Interestingly enough, his professor's father was one of the creators of SNOBOL.
  • anonymous 2007-02-13 14:15
    I agree a guy on the thread.
    Yes, the Real WTF is not having a upgrade path, so better code is posible.

    There are people on mainframes that need emulators to run legacy BINARY code because the src is lost, even the src of the compilers is lost. Seems that crap is OK in the mainframe area, because you need giganteous efforts to upgrade, while on microinformatic is lightweight to do a upgrade. So people still use absolute shit like Cobol and this Mumps shit.
  • Tailors Suit Ya 2007-02-13 14:18
    Eeby:
    It sucks that he had such a horrible experience and now he's having a hard time finding a job. I'd suggest that he get involved in an open source project that uses a more widely-known language. Then he can chalk up some experience and have examples of his work out in the public sphere.


    You mean like Progress? How about those 4GL's huh? Woot.
  • Flo 2007-02-13 14:19
    Build in obfuscation? oO

    Appendix 7: An example of "traditional" M coding style
    

    %DTC
    %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
    ;
    C S X=X1 Q:'X D H S %H=%H+X2 D YMD S:$P(X1,".",2) X=X_"."_$P(X1,".",2)
    K X1,X2 Q
    S S %=%#60/100+(%#3600\60)/100+(%\3600)/100 Q
    ;
    H I X<1410000 S %H=0,%Y=-1 Q
    S %Y=$E(X,1,3),%M=$E(X,4,5),%D=$E(X,6,7)
    S %T=$E(X_0,9,10)*60+$E(X_"000",11,12)*60+$E(X_"00000",13,14)
    TOH S
    %H=%M>2&'(%Y#4)+$P("^31^59^90^120^151^181^212^243^273^304^334","^",%M)+%D
    S %='%M!'%D,%Y=%Y-141,%H=%H+(%Y*365)+(%Y\4)-(%Y>59)+%,%Y=$S(%:-
    1,1:%H+4#7)
    K %M,%D,% Q
    ;

    [...]
    From http://www.faqs.org/faqs/m-technology-faq/part2/
  • Jon 2007-02-13 14:20
    themagni:
    z:
    Nice Google ad on the right:

    MUMPS to Java and RDBMS
    Automatic migration from MUMPS to Java and relational databases

    Salvation? :)


    Java? - The savior?
    Wish for a merciful death.
    I weep tears of blood.


    HAIIII-KU
  • SarcasticSOB 2007-02-13 14:21
    So would you say that M is the Enterprise verion of MUMPS?
  • CoderForChrist 2007-02-13 14:23
    I'm currently working in a MUMPS shop directly out of college.

    MUMPS (or, M, as it's called now) is not that bad of a language in and of itself, especially considering its age. In fact, M can be maintainable, etc., if it was written well. The system described in the article, however, sounds horrid. I mean, I've seen some bad code, but that just blows me away.

    I actually like the fact that an array can have string subscripts. It makes sorting things, etc., much easier. Also, there's a function, $ORDER() that iterates through any array at a specific subscript level ($QUERY() iterates through all subscript levels at once).

    M really isn't too bad once you're used to it, and if it's written well.

    Also,
    Jeff S:
    I like the spec indicates (if I am reading it correctly) that block of code in FOR loops and IF statements must all be on one single line. And we argue over where to put the curly braces!!! Maybe you can use GOTO's to avoid this?
    Actually, the DO command (used for calling subroutines) serves a double purpose here.

    FOR I=1:1:10 DO
    .[code]
    .[code]

    The DO command sends it to the next line, and the block is made up of lines beginning with '.'. Each nested block of code adds a dot, so:

    FOR I=1:1:10 DO
    . code
    . IF condition DO
    . . code
    . . code
    . code

    The syntax does allow for some...interesting uses as well, that I won't get into (for sake of time). At the same time, we don't have to sit around and try to figure out where to put braces...

    Granted, M doesn't conform to the ideals of certain programming experts, but that doesn't make it wrong. It's just a different way of doing things that, like anything else, can be abused to heck, but can also be useful when done right.
  • AceoStar 2007-02-13 14:24
    I feel this guy's pain. Lots of us are in similar situations.
  • akatherder 2007-02-13 14:25
    I don't see any mention of the timeline for this WTF. Actually I read it once, then got curious about the timeline and I'm too lazy to do anything more than scan through it. But why in the world are they still using this MUMPS thing if this is a present-day story? Of course the language is going to be a POS if it is that old... the decision to continue using it is the real problem.

    I also find it hard to believe he is completely out of the job market. He should be able to find an entry level or junior level position easily. After working with MUMPS for two years, he decided not to learn anything marketable like .Net, PHP, and perl in his free time? I'm an idiot and I could still make a living doing PHP, VB.Net and systems administration. Diversify!
  • brian 2007-02-13 14:25
    MUMPS sounds like the boogie man of all programming langauges. I pray that I never hear about it again.
  • mkb 2007-02-13 14:31
    Veinor:
    DECLARATIONS: NONE. Everything dynamically created on first reference.
    Kinda like Perl.


    Not if you are using "use strict" like you should be. Ruby and PHP have similar behavior, though. "autovivification" is what perl calls it.

    LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.


    Perl's arrays and hashes, though you can't auto-convert between the two (not in the expected way, at least.)


    PHP arrays can contain both hash keys and integral indices at any given time. If you use a Boost variant as the key into a C++ STL map you might be able to do something weird as well.


    DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.
    Err... I've never seen Perl auto-truncate, but yeah. The rest of the stuff, though... totally dumbass


    Boost variants in C++, etc.
  • Mr.<undefined> 2007-02-13 14:35
    Line scope is significant in M; "For" and "If" operate on the rest of the
    current line. Multistatement lines are natural to M, and M permits lines to
    be up to 255 characters long. When the natural logic of a statement calls
    for more than eighty characters, the programmer can choose to write a long
    line, or rework the logic to avoid this. The argumentless DO and block
    structure make this easy to do; for example

    I X?1.N1"H" S X=X*3600,%H=$H,@("X=$P(%H,"","",2)"_Y_X),%=$S(X<0:-
    1,1:0)+(X\86400),X=X#86400,%H=$P(%H,",")+%_","_X G RT

    can be rewritten as

    If X?1.N1"H" Do Go RT
    . Set X=X*3600,%H=$H,@("X=$P(%H,"","",2)"_Y_X)
    . Set %=$S(X<0:1,1:0)+(X\86400)
    . Set X=X#86400,%H=$P(%H,",")+%_","_X


    CAPTCHA: Waffles... OMFGBBQWAFFLES!!ONEONE!1!!1!ELEVEN!!! SO EASY!
  • obediah 2007-02-13 14:37
    Flo:
    Build in obfuscation? oO

    Appendix 7: An example of "traditional" M coding style
    

    %DTC
    %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
    ;
    C S X=X1 Q:'X D H S %H=%H+X2 D YMD S:$P(X1,".",2) X=X_"."_$P(X1,".",2)
    K X1,X2 Q
    S S %=%#60/100+(%#3600\60)/100+(%\3600)/100 Q
    ;
    H I X<1410000 S %H=0,%Y=-1 Q
    S %Y=$E(X,1,3),%M=$E(X,4,5),%D=$E(X,6,7)
    S %T=$E(X_0,9,10)*60+$E(X_"000",11,12)*60+$E(X_"00000",13,14)
    TOH S
    %H=%M>2&'(%Y#4)+$P("^31^59^90^120^151^181^212^243^273^304^334","^",%M)+%D
    S %='%M!'%D,%Y=%Y-141,%H=%H+(%Y*365)+(%Y\4)-(%Y>59)+%,%Y=$S(%:-
    1,1:%H+4#7)
    K %M,%D,% Q
    ;

    [...]
    From http://www.faqs.org/faqs/m-technology-faq/part2/


    Unless that hunk of crap executes 20 times faster than C, it needs to be eradicated from the planet. I mean suspend the consitution, and take "We're fighting for survival of the human race, damnit!" EXTR3ME measures.
  • Anonymous Coward 2007-02-13 14:38
    I always felt sorry for the AS/400 (sorry I meant iseries, no wait I meant system i....) folks that only knew RPG. How useful is RPG in an era of Unix/Linux/Windows?

    This MUMPS monstrosity puts RPG in perspective for sure.
  • mkb 2007-02-13 14:38
    brian:
    MUMPS sounds like the boogie man of all programming langauges. I pray that I never hear about it again.


    You must be joking. You've never heard of INTERCAL? or Brainf*ck?
  • Anonymous 2007-02-13 14:40
    brian:
    MUMPS sounds like the boogie man of all programming langauges. I pray that I never hear about it again.


    You got that right. It's like Dr. Frankenstein put a brainfuck brain into a Perl body... It's aliiiiiiive!!!!
  • SomeCoder 2007-02-13 14:41
    Ok... this WTF... it hurts. Physically.... oh god, the pain!


    As to the guy who said "use strict" for Perl... yes. If you are writing in Perl and not using "use strict" then stop right now and never code again.

    I've never heard of MUMPS until today but it sounds kinda like this proprietary language we have at my work. I won't name it, obviously, but there is one guy here who swears it's better than any other language out there for text parsing. Yeah right, give me Perl any day.

    I never really had to write scripts in it but I did have to try and understand some of the older scripts. It was pretty painful though MUMPS sounds infinitely more painful.
  • gwenhwyfaer 2007-02-13 14:45
    Ebs2002:
    I feel bad for Bryan... because he can't find something else because he stayed for 2 years.

    I feel bad for Bryan because he's managed to land in the one so-called "profession" so abusive to its members that two years of hard-earned debugging skills in an esoteric architecture, from scratch, can be dismissed out of hand in favour of meaningless buzzword compliance. Come to think of it, this probably explains a lot about the popularity of C++ or Java - anyone who's been using anything else for longer than six months is magically unemployable.

    I'm dismayed at the number of people working in the field who think that this is somehow acceptable. Even to the point of arguing that popularity is a direct measure of quality, or that allowing almost the entire recruitment process to be left in the hands of people incompetent in, or completely ignorant of, the field. Has anyone ever come across a recruitment consultant who does know what they're talking about? or who can analyse a CV at a slightly deeper level than fgrep?

    Sometimes I think the whole damn software industry behaves like an abused wife who insists that her husband has every right to beat her senseless, because she's headstrong and keeps stepping out of line.
  • Rootbeer 2007-02-13 14:47

    It seems to me that MUMPS isn't remarkably different from any other language that was state-of-the-art 40 years ago; the microcomputer BASIC I myself was weaned on had several traits in common with it.

    The strict left-to-right evaluation of expressions is surely a WTF though. It's algebraically incorrect to perform an addition before a multiplication.

  • use the backups 2007-02-13 14:51
    I thought IDX (LastWord) was cobol based, but I could be wrong.

    Lots of alternatives! Meditech, Cerner, McKesson, Epic....
  • Saladin 2007-02-13 14:55
    he was assured that he’d receive plenty of training and should have trouble picking it up

    Well, there's your problem.
  • facetious 2007-02-13 14:57
    ... Yeah, I still vote APL as much much MUCH worse. :(

    I mean .. come ON! More than half the symbols they use in the code aren't even letters!! WTF!
  • gwenhwyfaer 2007-02-13 14:59
    akatherder:
    the decision to continue using it is the real problem.

    Yes, because everyone knows that a system that's evolved over 25 years can be rewritten from scratch, to match every single feature and quirk of the original, in three months...
    He should be able to find an entry level or junior position easily.

    Not with two years' experience in anything. (No other profession believes that specialisation sets in that quickly. Can you imagine a lawyer being turned down by a criminal practice because he's spent the last two years with a commercial firm?)
    After working with MUMPS for two years, he decided not to learn anything marketable like .Net, PHP, and perl in his free time?

    Maybe it's on there, but he's just chosen to not lie about his experience with them? Not many people consider hobby experience to be of anywhere near the same calibre as commercial experience; I remember the culture shock of my first job well enough to understand why.
  • Old Phart 2007-02-13 15:05
    CDarklock:

    There are plenty of old farts on the internet. They're just all trying to hook up with teenagers on MySpace.


    Well, I'm almost 55 and don't mind working on stuff like this at all. Technologies like MUMPS aren't mainstream, so the jobs are unlikely to be offshored. Here where I am in Western PA there are MUMPS jobs going begging.

    Work is work, so suck it up and take the paycheck. Go spend it on some books and nice computer gear for home where you can play with Linux or Python or Ruby or whatever your heart desires. Then start a small consulting business and sell your skills with the new stuff there. That'll give you some independence and also some money to spend on those nice girls you meet on MySpace.

    Author Chad Fowler calls this type of niche work "technology hospice". It's not glamorous, but as with maintenance, there's always a need for folks to work on older systems that many people (especially those right out of school) won't touch. It can pay nicely and can be quite stable, too -- there are usually enough older systems and applications around that you can jump from one to another as they get phased out. And some take YEARS to die.
  • Bill 2007-02-13 15:06
    I work for a large regional health care company that uses MUMPS, Cache and other ancient languages and databases. I interviewed for a .Net position, but had to interview with the division that used the stone age software. All prospective developers had to interview with that division. They didn't talk about the languages they used, deferring that to the next round of interviews. Of course, there was no next round because I walked out of the first one feeling as if I had just talked to three people who'd had all the joy of life beaten out of them.
  • gwenhwyfaer 2007-02-13 15:07
    Rootbeer:
    The strict left-to-right evaluation of expressions is surely a WTF though.

    APL, Smalltalk and FP didn't think so (and I'm sure there are others.) Not to mention Lisp and Forth, which don't even use infix. What it does is make expressions completely unambiguous. Much more so than having to look up which of any pair of operators has higher precedence (and that's even without taking different associativities into account).
    It's algebraically incorrect to perform an addition before a multiplication.

    x = x + 1 is algebraic nonsense, but that doesn't seem to have stopped anyone. I'm afraid the only real reason for operator precedence is "Fortran did it".
  • AS 2007-02-13 15:09
    My first interview out of college was for a MUMPS shop. The issue that made me decide against was that each routine (or maybe it was file) was limits to something like 2k characters, including comments, variable names and whitespace.

    The practice at tis shop was to abbreviate evreything: "i" for if, "d" for do and variables named "x", "y" and "z". Sometimes "x1", "x2", ... if you had many.

    I ran a mile and never looked back!

  • themagni 2007-02-13 15:15
    Flo:
    Build in obfuscation? oO

    Appendix 7: An example of "traditional" M coding style
    

    %DTC
    %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
    ;

    SNIP

    [...]
    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.

    Brr.

    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."
  • Stan 2007-02-13 15:17
    Some of those language features sound like REXX, one of my favorite work experiences and one of the most readable languages. It's inspired by PL1, ANSI standard, still on all IBM OSs and most others, small but loyal user base.

    I've seen people build REXX program by concatenating conditional subroutine files into one file but that's rare and scary. On the other hand, programs that write programs and return code are tremendous fun. :)

    The M samples do look like hell on earth, tho.

    BTW: BASIC was invented by a mathematician (first math dept president of an Ivy League college) and x=x+1 was originally "Let x=x+1" which I can picture any math prof saying. The "let" keyword was later made optional.
  • me 2007-02-13 15:18
    "It actually made vi look user-friendly."

    That wouldn't be hard, VI is user friendly. Some are thrown off by the whole two-mode thing, but the commands make sense once you learn them. Do the tutorial and in a matter of hours you will be faster than notepad or pico etc.

    Now if it made Emacs look user friendly... (*ducks while running away).

    captcha: kungfu - ah yes, if you don't know VI, then your kungfu/kungfoo is weak.
  • Otto 2007-02-13 15:19
    Remco G:
    See its Wikipedia page: http://en.wikipedia.org/wiki/MUMPS.

    Looks like the article wasn't exaggerated one bit. That Wikipedia article is full of wondrous WTFs by itself.

    I think reading about this language has caused me to have liver failure.

    Please call an ambulance.
  • ewhac 2007-02-13 15:29
    If Brian's still wondering where to steer his career, I recommand he consider going out for embedded systems work.

    MUMPS was designed to be written and run on systems we today would consider tiny (hence the wacky syntax -- it's way easier to parse). Living in MUMPS for two years tells me you can A) work in a very constrained execution environment that is B) highly idiosyncratic -- the very definition of an embedded environment.

    Go visit Freescale's or Cypress' Web sites and have a look at their systems-on-chip and development tools. And no fair using the C compiler; read up on the assembly code.
  • gwenhwyfaer 2007-02-13 15:31
    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...)
  • Bill 2007-02-13 15:34
    After working with several GUI languages and SQL databases I have found myself in a Mumps position. At first I was a little reluctant as the language is a bit cryptic. However, having cut my programming teeth on microcode and assembly language I figured WTF give it a try (besides, I'm over 50 and needed a job).
    When the work began it wa slow going trying to get used to the concept of sparse arrays. This turns out to be a very efficient database structure and the strength of a well designed M system shines through when creating report extracts.
    Yes, SQL is more user friendly. Yes, a custom interface is neede to access Mumps from a GUI. But the Mumps code is simple to write and executes very fast, Many of the restrictions no longer exist.
    Many of the people who have criticized Mumps here either have no experience with the product or have had a bad experience (often do to their own design). Just because a language is old, this does not make it bad. I would not attemot to write a game in Mumps, but in certain nitch applications it cannot be beat.
  • gwenhwyfaer 2007-02-13 15:35
    I actually agree with everything you said, but I read this:

    themagni:
    "You have to remember that they had only 2 dimensional displays, and the neural interface was still 20 years away."


    I don't think the 2d display is going anywhere. How much depth does the letter 'A' normally have...? Even if we do live in 3d holographic virtual utopia, we'll still be reading our information from the virtual pages of digitised books in rendered libraries. ;)
  • EvanED 2007-02-13 15:35
    Seaph:
    Wow, how many more of you are from Madison, WI? I saw like three people in the first few posts.

    Just seems like a above average number of people from the same place.

    Is it the VA hospital in Madison that uses MUMPS? I came dangerously close to working for them, I worked for the school of Nursing in the Hospital.


    My guess would be that people are refering to Epic Systems Corporation, who makes software for the healthcare industry, but I could be wrong.


    Look at the Wikipedia page.

    Stan:
    Some of those language features sound like REXX, one of my favorite work experiences and one of the most readable languages. It's inspired by PL1, ANSI standard, still on all IBM OSs and most others, small but loyal user base.


    I've only used REXX a little bit (on IBM's CMS), but the PARSE keyword is damn sweet. Only other thing that I've seen with similar uses are regexs with backreferences, but PARSE doesn't require you to learn a new language to use.
  • gwenhwyfaer 2007-02-13 15:49
    me:
    VI is user friendly. Some are thrown off by the whole two-mode thing

    Someone made an observation once that stuck with me, because it makes a lot of sense. The observation was that vi isn't actually a modal editor. It's as modeless as emacs; when you type iSOMETEXTHERE<ESC>, what you're actually doing is beginning an insert command, typing the text to insert, and terminating it with the ESC key. Just like you would in ex, in fact - the only difference is that 'vi'sual mode gives you instant feedback.

    Of course, editors such as vim and elvis have complicated things to the point where you do now have two modes... but originally (and certainly on SunOS 12 years ago) vi wasn't like that.

    As for being user-friendly - very... but only to users of vi (or to those who've never seen a text editor before). It's pretty damn hostile to users of emacs or Wordstar, even though the interaction model is to all intents and purposes the same. The only difference is that printable characters are mapped not to a range of different commands, but to just one - "insert this character into the buffer".
  • mikelieman 2007-02-13 15:50
    Checkout what Cache has done with M. They call it "Post Relational" databases.

    And while you may be dissing this stuff, your EHR Backend *WILL* be written in this shit.

  • Reed 2007-02-13 15:50
    if(Progress == BARF) {
    No Query optimization
    } else {
    You haven't used it
    }
  • devious 2007-02-13 15:51
    Mumps is 1960s technology. If a system is still around that's written in mumps, it is probably at least 20 years old and possibly 30. Or the owner of the system is too poor to buy anything new (like some hospitals).

    It was designed for PDPs holding masses of text data with hundreds or thousands of users on dumb VT terminals. The restrictions on memory were crippling (there's probably more computing power on your mobile phone). Hence the 8 character name limit (and the one-letter commands).

    So yeah, it was cryptic, but that's all they had until the 1990s and OO started to take off.

  • fennec 2007-02-13 16:07
    Veinor:
    DECLARATIONS: NONE. Everything dynamically created on first reference.
    Kinda like Perl.

    Or PHP, or JavaScript, or...? The difference is that in Perl, you can
    use strict;
  • Anonymous Coward 2007-02-13 16:08
    gwenhwyfaer:
    Ebs2002:
    I feel bad for Bryan... because he can't find something else because he stayed for 2 years.

    I feel bad for Bryan because he's managed to land in the one so-called "profession" so abusive to its members that two years of hard-earned debugging skills in an esoteric architecture, from scratch, can be dismissed out of hand in favour of meaningless buzzword compliance. Come to think of it, this probably explains a lot about the popularity of C++ or Java - anyone who's been using anything else for longer than six months is magically unemployable.

    I'm dismayed at the number of people working in the field who think that this is somehow acceptable.


    Yes, but the bad habits learnt in those years can be deadly and worse than nothing. It's not just the language; the general quality and culture of a place can strongly affect how a programmer thinks. For instance, suppose you want to develop a new system from scratch. The fresh-faced neophyte out of (a good) college may miss some "obvious" things and require some guidance, but they're probably used to building things on their own, thinking ahead, and designing before coding. On the other hand, somebody who spent 3 years maintaining Windows code from 1996 may well have already resigned themselves to arbitrariness and cleaning up other messes by generally trying random things until the bug seems to go away.

    As for languages... again, 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. If you come from a langauge that uses GOTOs, you'll find yourself thinking in GOTOs; if you come from an object-oriented language, you'll think in objects. Obviously, this can be overcome, but it is relevant.

    Paul Graham has a rather harsher opinion on this than I do. Check out http://www.paulgraham.com/avg.html ; as far as he's concerned, if you're using a "weak" language, you are closing your brain off to the possibilities of what you could do in a stronger language.
  • aGould 2007-02-13 16:11
    I'd tell the guy to put those two years back on his resume. Either:
    1) They won't know what MUMPS is, which means they'll read "two years programming experience";
    2) They'll see it as proof that he's willing to work under really bad circumstances;
    3) They'll see that he stuck it out, then got A Clue, which is hard to find in today's employment market.
  • Saladin 2007-02-13 16:19
    me:
    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?
  • Rev. Johnny Healey 2007-02-13 16:29
    As far as production-use obfuscated languages go, nothing really compares to BANCSTAR. MUMPS looks like a walk in the park by comparison.
  • Plasmab 2007-02-13 16:36
    MUMPS sounds like Perl!
  • Plasmab 2007-02-13 16:39
    > If you are writing in Perl ..... then stop right now

    Use a real programming language!
  • G Money 2007-02-13 16:43
    It's the Web 2.0 version.
  • aKarma 2007-02-13 16:52
    aGould:
    I'd tell the guy to put those two years back on his resume. Either:
    1) They won't know what MUMPS is, which means they'll read "two years programming experience";
    2) They'll see it as proof that he's willing to work under really bad circumstances;
    3) They'll see that he stuck it out, then got A Clue, which is hard to find in today's employment market.


    I'd tell the guy he should have kept his MUMPS programming job and searched for another job while still staying employed.
  • AC 2007-02-13 16:52
    mikelieman:
    Checkout what Cache has done with M. They call it "Post Relational" databases.

    And while you may be dissing this stuff, your EHR Backend *WILL* be written in this shit.

    If this is "Caché" the database system then it's not so bad actually. It's an object oriented database which allows you to use SQL but adds cute stuff like looping over an extent and putting code you'd normally write as procedures into the database using java or whatever you want. It's actually pretty cool since you don't have to use ORM mappings for one, which usually are dog slow (at least in my experience, but I've only used hibernate).

    I'm too tired to actually think of something useful to do with it but don't diss the "post-relational" bit. While the underlying technology (M I guess) might be old, the idea is pretty newish and definitely not 60s technology.
  • anonymous guy 2007-02-13 16:58
    Saladin:
    me:
    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?

    Peoples' "grandmas" rarely have any need to use a text editor. Unless you count the one built into their email program. So, compared to ~1000 hours per year I spend using that text editor? Ya, a couple of hours is nothing. I love vim (I suppose if you like emacs, go ahead) and the vast majority of other text editors are complete and utter crap. You've got to learn to use just about anything, and if you can find something as quick to learn as notepad, but which is as user-friendly as vim, then by all means, let me know!
  • Alan Burlison 2007-02-13 17:06
    And of course they have a support organisation for anyone who suffers from MUMPS - the MUPS User Group. Go on, spell out the acronym ;-)
  • earl 2007-02-13 17:07
    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.

    Haha.
  • slinkp 2007-02-13 17:10
    rmr:
    ...I like the idea of having a transparent database accessible through some syntactic sugar. I can imagine a web development framework that provided the same feature being extremely popular. Ruby on MUMPS anyone?


    Sounds kind of like Zope (the framework on which Plone is built). Zope uses a transparent object database. Zope has accrued its own share of WTFs since 1998, but there are still some really cool things about it.
  • the-moss 2007-02-13 17:12
    When/which team did you work for? I was in EDI over in the mall.
  • craaazy 2007-02-13 17:19
    Top Cod3r:

    First of all, for all you newbies out there, you want to store your code in a global array for performance optimization purposes. You see global arrays get optimized by the compiler making them as much as twice as fast as normal arrays.

    The only WTF about this is why you guys all think this is a WTF. Maybe you just dont understand MUMPS.


    You're joking right?
    I mean, why on earth doesn't the compiler optimize anything well but the stuff in a global array? These days, it's the compiler's job to figure out which pieces of code get called most often, and to try harder to optimize those pieces of code. Surely the MUMPS compilers could be upgraded to handle this better?

    Same with the arcane syntax. Surely some de-obfuscators could be written that change back 1-letter commands to full-length commands? Surely restrictions that code has to be on a single line can be lifted, maybe adding braces?

    Perhaps (optional) declaration of types could be added, with type-checking on the variables that do have a declared type? Perhaps some sort of built-in module namespace-functionality, arrays that aren't global to every piece of code, but with local scopes? How about lifting length restrictions on variablenames, significance of whitespace, make case sensitivity saner etc. etc.

    That's all pretty easy to do using, say, some sort of "pre-compiler". Convert your code to the new language specs, and voila, it's indented, syntactically sugarified, easier to maintain, and, most important of all, harder to break. Write according to the new and improved conventions, and let a precompiler spew out old-style unreadable MUMPS.

    It's not like this hasn't been done in other languages. C++ was precompiled into C back in the day. An erstwhile toy language like PHP (any one remember PHP2?) has been extended so much that it's getting almost enterprisy. Perl has use strict and objects. Java added stuff like templates, and just-in-time compilation using hotspots. Languages change for the better all the time.

    And then there's IDEs that color-highlight code, do lookups on variable names and functions, pretty-print, validate..

    But such changes, that in other languages are universally regarded as improvements, would, when applied to MUMPS, suddenly somehow sully the greatness of MUMPs?

    If that's the case, why not switch from MUMPS right back to, say, PL/1 on punch-cards? Or just soldering radiotubes together?

    I mean, come on, I read one comment here saying that using comments has negative performance impact on MUMPS..
  • Stinkfoot 2007-02-13 17:20
    I can totally relate.

    I used to program Delphi.
  • Sgt. Zim 2007-02-13 17:21
    AC:
    mikelieman:
    Checkout what Cache has done with M. They call it "Post Relational" databases.

    And while you may be dissing this stuff, your EHR Backend *WILL* be written in this shit.

    If this is "Caché" the database system then it's not so bad actually. It's an object oriented database which allows you to use SQL but adds cute stuff like looping over an extent and putting code you'd normally write as procedures into the database using java or whatever you want. It's actually pretty cool since you don't have to use ORM mappings for one, which usually are dog slow (at least in my experience, but I've only used hibernate).

    I'm too tired to actually think of something useful to do with it but don't diss the "post-relational" bit. While the underlying technology (M I guess) might be old, the idea is pretty newish and definitely not 60s technology.

    "Post-relational" = marketingese for SQL-like, object-like, and a couple of other "-like" layers over a hierarchical DB structure ... MUMPS was first written a few years before Codd, and hierarchical was hot shit then. Caché is pure M at the bottom, and can even be worked with exclusively in M, if you're a masochist. Admittedly, the SQL, Cachescript (proprietary VB-like language) and Java bindings make it easier to work with, but it's still a crack-smoke, 40+ year old methodology underneath.

    In my (admittedly limited, because I have to deal with a third-party package) experience, for well-designed structures, it can be extremely fast, but at the cost of massive disk consumption and no normalization... And if you decide to use its SQL-ness, and want to do something wacky like one o' them new-fangled join thingies, performance tends to go down the toilet.
  • Zygo 2007-02-13 17:23
    Veinor:
    DECLARATIONS: NONE. Everything dynamically created on first reference.
    Kinda like Perl.
    LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.
    Perl's arrays and hashes, though you can't auto-convert between the two (not in the expected way, at least.)
    DATA TYPES: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires.
    Err... I've never seen Perl auto-truncate, but yeah. The rest of the stuff, though... totally dumbass


    I actually think more of Tcl than Perl when reading descriptions of MUMPS (especially Tcl with the metakit DB package).

    All Tcl commands run on one line, but there's a string quoting syntax which looks a lot like C, but isn't. Consider:


    set x 5
    while ($x>0) {
    # This is a comment
    puts $x
    set x [expr $x-1]
    }


    which is an infinite loop, because it's equvalent to


    "while" "(5>0)" \
    "# This is a comment\nputs \$x; set x \[expr \$x-1\]"


    and since 5 is always greater than zero, it runs forever. You can also see why comments would be frowned upon in performance-critical environments.

    Tcl has no reserved words. All commands are procedures written in either C or Tcl, bound to string names. The interpreter starts with a bunch of predefined procedures implemented in C code. Procedure and variable names can be any string, including the empty string. Procedures can even be renamed. So one could do something like


    rename rename r; # who wants to type all those letters?
    r set s; # rename set to s
    r puts p; # rename puts (print) to p
    r while {""}; # rename while to ""
    # That's "\"\"" for you C++ people
    r expr ""; # rename expr to the empty string
    # That's "" for you C++ people

    proc puts {string} { p stderr $string }
    # replace the standard puts command with
    # one that outputs on stderr instead of stdout

    # We put ; before # above, because you can also write
    p #foo
    # which calls the "p" procedure with the string argument "#foo".

    #Note that "#" is not a Tcl command.
    # If it was, then "#Note" would not start a valid comment.

    s {} 5; # set variable named empty string ("") to 5
    \"\" {${} > 0} {
    # "" is the new name for while
    # (the \"'s mean literally "", as opposed to "" or {}
    # which would both be an empty string)

    # ${} is "value of variable named empty string"
    # In this context the variable is interpreted as a string.
    p ${}

    # "" here means empty string, which is the new name for expr
    # ${}-1 is "value of variable named empty string" minus 1
    # [foo] means "execute foo and substitute return value
    # of foo in the command"
    # In this context the variable is interpreted as some kind
    # of number (there are three kinds, which one is used
    # depends on the existing value of the variable, and
    # remember that currently the variable is internally
    # a UTF-8 string data type).
    # Type conversion is implied here, where the
    # variable is a number, and earlier in
    # this block when the variable was printed as a string.
    s {} ["" {${}-1}]
    }
    # The end of line after the } ends the "", uh, while command.


    You can also create a nested hierarchy of Tcl interpreters within Tcl, each one running a slightly modified version of the language implemented using procedures available to the outer interpreter. You can create alias procedures (so you can have both "w" and "while" bound to the same procedure) and you can also redirect a procedure from one interpreter to another (which allows you to do restricted sandbox type secure code, or write Tcl scripts that transform other Tcl scripts by executing them with a specialized custom Tcl interpreter).

    Want to execute a command that doesn't exist? No problem, Tcl will run a procedure named "unknown" and give that procedure your command name and arguments as parameters. The "unknown" procedure can dynamically load code, generate code on the fly, execute the command as a function call in a different language or as an external command. You could for example send unknown Tcl commands and their arguments as query strings to some SQL database (although since many SQL command words are already defined as procedures in Tcl the results would be a whole new level of WTF). The interactive Tcl interpreter by default sends unknown Tcl commands to a shell for execution as shell commands.

    Tcl's variable types all have a type-specific representation (UTF-8 string, 32/64-bit integer, double, list, byte-array, compiled byte code) and a common representation (UTF-8 string) which is used to convert variables of different types as required. I suspect this is similar to what MUMPS does with its "optimized global arrays" (assuming that the truth is not that MUMPS's local arrays are just incredibly slow).

    Unlike M, there are only the usual 32-bit implementation limits on line or string lengths in Tcl, whitespace is mostly insignificant except for newlines, and everything is uniformly case sensitive. There is also no GOTO in Tcl, or at least it doesn't come with one (anything's possible if you start mucking with the language at runtime).

    Above are some of the most horrible examples of Tcl code I've yet seen. It's startling how compact they are, and how easy they were to write...
  • Zygo 2007-02-13 17:27
    Veinor:
    DECLARATIONS: NONE. Everything dynamically created on first reference.
    Kinda like Perl.


    Except that in Perl you can use declarations if you want to, and you can turn off support for undeclared and unscoped variables.

    Perl still allows undeclared scoped variables ($::global or $somePackage::someName) though, with only a warning if the undeclared scoped variable name is used only once.
  • danixdefcon5 2007-02-13 17:27
    This "language" looks worse than JCL, COBOL, LISP, APL, VB combined! Looks like something using the worst features from any of these languages. (And no, I am not dissing on all of these languages. Except VB, which should have never existed.)

    To all y'all MUMPS defenders: 'Tis a general security rule not to allow data to be executed as code. Ah, I can only begin to see the world of exploits based on XECUTE...

    (Then again, the would-be hacker would die of brain explosion while trying to write the exploit...)

    I actually like COBOL after reading this thing ... it may have been fast and efficient 40 years ago, but so is assembly code. And I'm not about to write an ERP system out of assembly...

    Addendum (2007-02-13 17:34):
    Oh yes I know about why it was used back in its own days. But trying to defend it against current languages is just insane. Maybe 40 years ago I would've wanted to have code and data side by side, but now I don't.
  • RH 2007-02-13 17:29
    Ebs2002:
    ...

    Wow.

    I'm not surprised this is happening, but...wow. I feel bad for Bryan, not just because he had to work here, but because he can't find something else because he stayed for 2 years.

    captcha:muhahaha, what I'm sure the management is thinking to themselves when someone tries to quit: "muhahaha, you'll be back, there's nowhere else for you to work!"


    That brings about a new twist in "job security"... I've always thought of it being the coders making horrible code in order to keep their job since they only know how to maintain it. I never heard of employers having their employees use a horrible language in order for them to never quit. ;)
  • its me 2007-02-13 17:32
    This is why when developers say to me "I don't care what language I code in" I laugh. Yes, yes you do. The programming language world is larger than java, perl, ruby, and C#.... ;)

    As far as the WTFness of MUMPS.... that's pretty weak, MUMPS is simply old and does what a lot of languages did in it's time. Abbreviate commands with a single letter? Brilliant when every byte counts. Xecute code stored in a variable? Uh, even early BASIC could do this. Today it's called a function pointer or a delegate....

    Would I want to code in it today? Hell no, but recognize the past for what it is. Features and oddities we laugh at today the next generation will be laughing at ours.

    -Me

  • JCDenton 2007-02-13 17:37
    Well what would you expect of a language that was born in an Animal lab by a (presumably) evil doctor?


    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.

    Source:wikipedia
  • dkf 2007-02-13 17:48
    Rev. Johnny Healey:
    As far as production-use obfuscated languages go, nothing really compares to BANCSTAR. MUMPS looks like a walk in the park by comparison.

    Ugh. Looks just like it is working directly with machine code (not assembler, real raw machine code). I've done that, and it sucks.

    Indeed, it was hard enough that I used another machine I had to develop my own toolchain (in the only higher-level language I had at the time, BASIC) and built my own communications hardware and bootstrap loader so that I could develop in greater comfort. I wouldn't do it that way now, but it was tremendously instructive.

    Curiously, that mess ended up (indirectly) getting me my first real job. :-)

    Come to think of it, I've also done machine code in situations where the only input mechanism I had was DOS's 'COPY CON:' and that was even suckier. But that's a story for another time...
  • bspiral 2007-02-13 18:06
    the-moss:
    This company wouldn't be based in Madison, Wi would they?

    I think I also worked for them straight out of college.. I only lasted a year though.


    ?smetsys cipe

    Yeah, burnout in 2 years tops for most fresh meat. If they're using MUMPS - then I see why.

    Ironically enough, my captcha for posting this is: sanitarium
  • RogerC 2007-02-13 18:11
    You see, because MUMPS has a rather small routine limit, developers had to spread code across several routines (GBLVCM1, GBLVCM2, etc) and “chain” them together with a GOTO at the end.

    To edit the code stored in the “database” (if you’re charitable enough to call it that), developers needed to use the internally-created text editor. It actually made vi look user-friendly. 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.


    Both of these put me much in the mind of Forth: code stored in 1 kbyte disk blocks with continuation operator to chain to the next block; an integrated and irritating editor that made extensive use of the VT 100 PF keys and number pad.

    I'm glad to have left it behind many years ago.
  • lToro 2007-02-13 18:12
    At this point I would like to point out a previous sidebar article: http://forums.thedailywtf.com/forums/thread/73428.aspx
  • dkf 2007-02-13 18:21
    Zygo:
    There is also no GOTO in Tcl, or at least it doesn't come with one (anything's possible if you start mucking with the language at runtime).

    I advise regarding GOTO as impossible in Tcl. The amount of work required to make even a simple C-like GOTO is quite enormous; it's far easier to handle exceptions, build state machines or drive automated resource deallocation by other means.
  • WIldpeaks 2007-02-13 18:26
    Sgt. Zim:
    asuffield:

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


    Not a WTF.

    In theory. When it works. But when it doesn't ... Get the bandages, because your eyes will start bleeding.

    The googles, they do nothing!
  • Sizer 2007-02-13 18:41
    gwenhwyfaer:

    I'm afraid the only real reason for operator precedence is "Fortran did it".


    That's not completely true - it comes from how you'd normally evaluate written equations. 3x+4y should be read as (3*x)+(4*y), not ((3*x)+4)*y. And that holds true even if you do 3(dot)x+4(dot)y.


  • Mitch 2007-02-13 18:45
    I've worked as a programmer for 22 years in a multitude of environments, technologies and languages. And that code is by far the most awful, unmaintainable bollox I've ever seen!!! But then again, maybe I've just been lucky...

    Certainly wouldn't want to be dreaming in that code.
  • Hank Miller 2007-02-13 19:04
    Saladin:
    me:
    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.
  • Prozak 2007-02-13 19:05
    How can I state that this is by far the worse horror story of the industry. And I was only complaining that my last company, that went bust in London 2 months ago, where not using hibernate and Spring. I brought Java 5 in there. Building yesterdays technology with today's tools, was the hidden motto.

    I was part of the hot team, the one building the next flagship product that never got delivered. And that made customers go bust. Would not mention any names, but my next job is in the same sector, and God did we leave a stench.

    So for the story of this fellow, it nearly brought a tear to my eye. That language has all the worse that the industry can make. Please get him a job at Google for life. He deserves that more than any one.

    May the many years of industry hell ahead of him help him heal from such a deep trauma.

    After that the rest, its peanuts, you have seen hell, please do enjoy life.
  • Derek Johnston 2007-02-13 19:06
    Anonymous Coward:

    This MUMPS monstrosity puts RPG in perspective for sure.


    RPG as in Rocket Propelled Grenade...?

    Captcha: paint (mmmmmm.... smells good)
  • Mr. Mike 2007-02-13 19:10
    Our hospital's main patient database uses MUMPS. They've been working on a replacement for at least two years. (Users enter patient info into the replacement system, which feeds into the MUMPS system, where users can then correct the data, if they need to enter something the new system doesn't implement yet, which is a fair amount.)
    Anyway, to get data out, we have a DTS script which launches a telnet session, which runs reports, and then runs kermit to download the reports. They are fed to a perl script which cleans up the data, which is then piped to MS SQL Server. We then get the data from SQL Server. It has about a 50% chance of completing successfully.
  • Mr. Mike 2007-02-13 19:10
    Our hospital's main patient database uses MUMPS. They've been working on a replacement for at least two years. (Users enter patient info into the replacement system, which feeds into the MUMPS system, where users can then correct the data, if they need to enter something the new system doesn't implement yet, which is a fair amount.)
    Anyway, to get data out, we have a DTS script which launches a telnet session, which runs reports, and then runs kermit to download the reports. They are fed to a perl script which cleans up the data, which is then piped to MS SQL Server. We then get the data from SQL Server. It has about a 50% chance of completing successfully.
  • Stas 2007-02-13 19:11
    I worked on the VA .NET project and I can say they still use MUMPS a lot. They tried to get rid of it, but it seems like it's impossible to kill the thing. The execution environment migrates from platform to platform (VAX/VMS, Cache) but their entire software package remains virtually the same.

    One of my first tasks (after working for several months) was to create an interface between a .NET application and MUMPS system. When I started looking at M code, I was horrified at first, just like many folks here. I was totally disgusted. Then I learned that the stuff was nearing 30 years in production and it changed my perspective a bit.

    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.

    In the end, I didn't have to learn much M since I was working together with M programmer and we practically didn't touch the M part of it (there already was some server side code developed for interaction with Delphi and Java clients). I wrote my .NET client (XML over TCP, simple stuff) and it proved itself well.

    I agree, it's about time for MUMPS to retire. However, looking at pro users working with our new GUI .NET app and the legacy MUMPS text-based app, I still think it was a step back.
  • Stas 2007-02-13 19:13
    I think Mr. Mike and I worked on the same project :) This all sounds very familiar :)
  • Thuktun 2007-02-13 19:19
    Given that (IIRC) it was the second language to get ANSI approval, MUMPS was exceedingly high-tech for its time. Many of the modern MUMPS interpreters are quite fast.

    One of the reasons the code referenced in the article may be slow is that it sounds like it's using interpreted strings (rather than stored routines) for *EVERYTHING*. Rather than having the possibility of tokenization or pre-compilation using a saved routine, it's having to re-interpret everything at runtime because it's all stored as strings.

    MUMPS might be considered the Perl of the 1960s. It had associative arrays and was very easy to write obfuscated code in. It was even better at this last than Perl, given each command could be specified as the shortest, unambiguous abbreviation. The ability to access a hierarchy of lockable, multi-process global variables alongside your local-process global variables was kinda cool.

    I almost got sucked into that after graduating from college with a background in C/C++. I almost didn't get out, and was lucky I did. It's very much a dead end, but there are still well-paying jobs there because there's lots of legacy code big business wants to keep running.
  • Zygo 2007-02-13 19:22
    Anonymous Coward:


    Yes, but the bad habits learnt in those years can be deadly and worse than nothing. It's not just the language; the general quality and culture of a place can strongly affect how a programmer thinks.


    Amen to that. I often find myself struggling with a thorny C++ problem and thinking, "what would I do if I were programming this in Perl?" If this trick works, my problem is solved and I write some simple and obvious algorithm in Perl code, translated into C++. If it doesn't work, I see that what I'm trying to do will result in C++ code that looks like the innards of the Perl interpreter, in which case I give up on the whole approach and try something else. Often the "other" language isn't Perl--it might be Tcl or Matlab.

    Strangely enough I never find myself wondering "what would I do if I were programming this in C++?" while programming in Perl...or any other language except C...funny, that.

    Perl, Ruby, Smalltalk, Tcl, Fortran, Lisp, Forth, SQL, even Java and Javascript provide inspiration for different approaches and techniques. I generally consider anyone who hasn't mastered at least two languages, where one language idiomatically treats variable values as potential code and the other doesn't, as at best a junior developer. It doesn't matter to me if the person has 20 years of industry experience in COBOL, Fortran, Java, VB, C and C++--as a developer, they're little better than a recent graduate until they learn from working in a larger variety of languages.
  • Matt 2007-02-13 19:30
    This article and the numerous and highly charged responses made me laugh. The examples quoted are almost all classic examples of stuff you'd fire a mumps programmer for writing, since they are patently obscure, opaque and barely maintainable. No wonder you all think it's bollocks. However, I'm sure I could dig up equally awful examples of the abuse of pretty much any other language. It's quite straightforward to write totally clear and maintainable mumps code.

    It's also the intensity of the cries of horror that everyone comes out with that amuses me too. A bit like someone who shoots a rattlesnake because he's led to believe it's nasty, rather than take the time to discover some background to the animal. Calm down guys, it's only a programming language with a syntax which, to guys who've swallowed the Java, C++ and .Net koolaid, looks freaky. So what? Chinese looks pretty scary to me, but it seems to do a good job in the hands of a proficient Chinese person.

    As a great example of a prejudicial article intended to show something in its worst possible light, it sure did a great job. It leaves me wondering what was its objective and motivation?

  • Zygo 2007-02-13 19:42
    Saladin:
    me:
    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?


    All computer programs communicate with their users through a command language. For vi, the command language is a number of simple letter and symbol commands. For notepad, the command language is a mixture of ape-like gesturing and finger-snapping, or a very limited set of keyboard commands.

    Now, gesturing like an ape and snapping your fingers will get you through the working day in some parts of the world. The experience will be frustrating and slow for both you and the people who have to work with you, but since a text editor knows nothing of frustration, in theory it's only the user who will be inconvenienced by a weak text editor (although in practice it's the user's co-workers who get the most frustrated). Maybe the user will spend 15 minutes of her life editing text, so the loss is acceptable.

    In other parts of the world, wandering around where you don't know the native language will get you in a dark alley somewhere with a knife wound in your chest while your worldly possessions and/or your children are stolen and sold in the nearest market. Arming yourself with a knowledge of enough language to express what you need and to negotiate as an equal with the people (or in this case machine) who can get it for you gives you real power over your environment. If the environment looks like a bunch of text files then you really want to spend a few hours to learn how to use a text editor, just like you'd want to spend a few hours learning self-defense before wandering in dark alleys in unfriendly neighborhoods...
  • Kenneth Spicer 2007-02-13 20:02
    I've been programming in M for about 25 years. Everything in this article is true. Sparse arrays, data and programs are interchangable. Oh, and you forgot post-conditionals (all commands can become their own IF statements).
    But I can't say the options (Oracle?) is any better. I've done Oracle DBA. PL/1, Assembler, JAVA etc. etc. etc.
    When I started oh so many years ago I was the first "trainee" who'd actually been trained to program in MUMPS design. All of the previous traineees were lab techs.
  • gwenhwyfaer 2007-02-13 20:14
    Anonymous Coward:
    Paul Graham has a rather harsher opinion on this than I do. Check out http://www.paulgraham.com/avg.html

    Wow, you completely misread his point there! He wasn't saying anything about people who merely use weak languages, and especially not about those who use them but are aware of stronger alternatives. His criticism in that article was aimed at those who refuse to believe that any language offers constructs more powerful and/or expressive those provided by the (weaker) language they're used to; and I agree with him wholeheartedly on that. That's not the situation described here, where Bryan is fully aware of the weaknesses of M(UMPS) (although apparently less aware of some of the things it got right, and unsympathetic to its historical context).

    I am in no way prepared to accept that two years spent learning to read and work with incomprehensible code in an industry riven with NIH syndrome is useless. Let alone worse than useless, as you seem to be contending. I can't imagine Paul Graham would be delighted to find himself quoted in support of such a position either.

    (And welcome to the redditors, I guess.)
  • Kenneth Spicer 2007-02-13 20:17
    Oh, and before I forget (old age, you understand). I do work for the VA now. I don't know if it's in spite, or because of MUMPS, but they are now 100% electronic medical records. And over 150 Medical centers working together. What other Medical system can say that?
    Their primary concern at this point is that many of us Mumpsters are getting old. And they are trying to fill the void with youngsters fresh out of college.
  • gwenhwyfaer 2007-02-13 20:29
    RogerC:
    Both of these put me much in the mind of Forth: code stored in 1 kbyte disk blocks with continuation operator to chain to the next block

    In fairness, I think that was a FIGforth thing; Chuck Moore is on record as believing it's a very bad idea, exactly because you can't tell the thing to load one block in isolation.
    an integrated and irritating editor that made extensive use of the VT 100 PF keys and number pad.

    Was that also FIGforth?

    The problem with Forth is that it's not a difficult language to implement. In fact, it's far easier to implement than to use - kind of like Lisp without the standardisation (!) - so hundreds of little "toy" implementations appeared and got distributed for free, but without decent support or a sane environment. And people picked them up, thought "This is Forth? Eurgh!" and rejected the whole concept, despite the rather nicer products available commercially (again, not entirely unlike Lisp). For a couple of examples of modern Forths, there's Forth, Inc's SwiftForth, MPE Ltd's VFX, or Bernd Paysan's bigForth.
  • foobar 2007-02-13 20:43
    OMG, poor guy!
    I actually checked the date for 2007-04-01
  • lazloman 2007-02-13 20:43
    I don't know that I'd hide the job. He should be honest and up front about the experience and that it was a bad one. No one will hold it against him. Either that, or he's going to look like he's been in jail for a couple of years.
  • gwenhwyfaer 2007-02-13 20:50
    Sizer:
    That's not completely true - it comes from how you'd normally evaluate written equations. 3x+4y should be read as (3*x)+(4*y), not ((3*x)+4)*y.

    Firstly, the earliest Fortrans limited the complexity of expressions in arbitrary ways (particularly inside things like array subscripts). In fact, Fortran-I was a total hack. The only reason it caught on was that IBM were pushing it, and that at the time there wasn't anything else (except dressed-up assembler).

    Secondly, in the comment you're replying to I've already pointed out one way in which algebraic convention was completely ignored. The use of multicharacter variable names and the asterisk to denote multiplication was another. So all you're doing is reiterating a suggestion I already gave reason for rejecting.

    Thirdly, APL is much more mathematically sound than Fortran; yet it eschews operator precedence entirely. Indeed, its successor, J, dispensed with the need to program non-functionally (and with the funny character set) - but did not reintroduce it. Thus, one can conclude that operator precedence is not exactly a deal-breaker for the mathematically inclined.

    ...Now if you'd countered with the argument that Algol-60 did a lot more to cement operator precedences than Fortran, you might have had an argument. But then the question becomes, if Fortran-I had enforced a strict left-to-right discipline on expressions, would Algol-60 have gone with precedences? But in view of all the other discrepancies between Fortran and expression/algebraic notation, would we have missed operator precedences if they had been thrown out too?
  • Henry Troup 2007-02-13 20:57
    The problem with one datatype is the inevitable unexpected interpretation. A former employer used department numbers of the form nAnn - n A digit, A an alpha. Periodically, someone in 2E02 or the like would find that their department was now rendering as "200" or more likely, 7E13 would see "****" for overflow - because something had interpreted the E as exponential notation. Excel will do this
  • Tim 2007-02-13 21:19
    PHP arrays can contain both hash keys and integral indices at any given time. If you use a Boost variant as the key into a C++ STL map you might be able to do something weird as well.


    Does this mean that you need to use a language extension to make C++ as baroque and convoluted as MUMPS? Talk about scoring a point for the other team. :-)
  • gwenhwyfaer 2007-02-13 21:46
    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.
  • Zygo 2007-02-13 21:55
    craaazy:
    Top Cod3r:

    First of all, for all you newbies out there, you want to store your code in a global array for performance optimization purposes. You see global arrays get optimized by the compiler making them as much as twice as fast as normal arrays.

    The only WTF about this is why you guys all think this is a WTF. Maybe you just dont understand MUMPS.


    You're joking right?
    I mean, why on earth doesn't the compiler optimize anything well but the stuff in a global array? These days, it's the compiler's job to figure out which pieces of code get called most often, and to try harder to optimize those pieces of code. Surely the MUMPS compilers could be upgraded to handle this better?


    Your entire rant is predicated on one huge assumption--that most MUMPS code is compiled, and most MUMPS code maintenance involves writing new code in some other language.

    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.

    CAPTCHA: craaazy
  • Tim 2007-02-13 22:02
    I have to say that while reading this post was a little depressing, reading the comments cheered me considerably.

    The MUMPS description in the original post did not strike me as particularly WTFable, and in fact reminded me a lot of Level II BASIC -- which, while not an enterprise programming language by any means, was also not WTF-class.

    Much of the shock and horror on this issue seems like terror at things that are different. I got news for you, guys -- not every language is procedural and not every database is relational. Alex, I recommend getting some screeners who are older than 22. :-)
  • Zygo 2007-02-13 22:13
    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.


    What? That's trivial to convert to SQL:


    update data set val = x where a1 = one and a4 = four
    and a2 is null and a3 is null;


    or


    insert into data (val, a1, a4) values (x, one, four);


    depending on the result of


    select val from data where a1 = one and a4 = four
    and a2 is null and a3 is null;


    Most SQL implementations provide a way to merge the update and insert into a single operation.

    Leave out the "and a2 is null and a3 is null" if not specifying an attribute means some datum is found with arbitrary values for those attributes.

    To get the semantics right you'd probably have to automatically create tables or add columns to existing tables (e.g. what happens when someone assigns to ^data[one, two, three, four, five]?). Or use a schema that we've seen many times on tdwtf:


    update global_vars set val = x where array_name = 'data'
    and a1 = one and a4 = four;


    where all data is stored in the "global_vars" table which has as many columns named a0..aN as the implementation allows.

    The SQL would never make any sense to human eyes (all tables would have a text column named var, and N text columns named a1, a2, a3...aN, no constraints, probably a lot of application code for handling transaction semantics since the RDBMS's transaction logic is not used, etc) and performance would utterly suck; however, translation seems to me to be not only possible but simple.
  • Stan James 2007-02-13 22:15
    Some of those language features sound like REXX, one of my favorite work experiences and one of the most readable languages. It's inspired by PL1, ANSI standard, still on all IBM OSs and most others, small but loyal user base.

    I've only used REXX a little bit (on IBM's CMS), but the PARSE keyword is damn sweet. Only other thing that I've seen with similar uses are regexs with backreferences, but PARSE doesn't require you to learn a new language to use.


    REXX on CMS is heaven! The most hacker-friendly OS I ever used. I tried to duplicate parse in Java ... the parsing pattern was in an array of strings. It didn't come out that well. Maybe I should try again with VarArgs. The EASEL language (now ESL corp) has "skip" and "take" commands that are almost as good as parse.
  • Watson 2007-02-13 22:20
    asuffield:
    Much of this stuff is not new (sadly). And I say that in the full knowledge that MUMPS is from the 1970s.


    I was just thinking how all those features made it sound like the illegitimate offspring of PHP and PickBASIC.

    I almost ended up in a PickBASIC shop. But if I was lucky down the road I might have got some of the Visual Basic jobs, too. Mmmm....
  • Foobar 2007-02-13 22:27
    gwenhwyfaer:
    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.


    Beware of tedious nerds who apparently spend the entire day reading the comments to this WTF and angrily responding with great brilliance and /delicious/ witicism. Are you sure you're not Larry Groznic?
  • icelava 2007-02-13 22:29
    Flo:

    Appendix 7: An example of "traditional" M coding style
    

    %DTC
    %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
    ;
    C S X=X1 Q:'X D H S %H=%H+X2 D YMD S:$P(X1,".",2) X=X_"."_$P(X1,".",2)
    K X1,X2 Q
    S S %=%#60/100+(%#3600\60)/100+(%\3600)/100 Q
    ;
    H I X<1410000 S %H=0,%Y=-1 Q
    S %Y=$E(X,1,3),%M=$E(X,4,5),%D=$E(X,6,7)
    S %T=$E(X_0,9,10)*60+$E(X_"000",11,12)*60+$E(X_"00000",13,14)
    TOH S
    %H=%M>2&'(%Y#4)+$P("^31^59^90^120^151^181^212^243^273^304^334","^",%M)+%D
    S %='%M!'%D,%Y=%Y-141,%H=%H+(%Y*365)+(%Y\4)-(%Y>59)+%,%Y=$S(%:-
    1,1:%H+4#7)
    K %M,%D,% Q
    ;

    [...]

    Can i have the private key, so i can decrypt this chunk to see the real message. Thanks.
  • Zygo 2007-02-13 22:39
    its me:
    Xecute code stored in a variable? Uh, even early BASIC could do this. Today it's called a function pointer or a delegate....


    Ummm, I don't think you (and quite a few other people today) understand. Function pointers look like this:


    // A function
    void foo() { printf("Hello, World!\n"); }

    // A function pointer variable
    void (*fooP)();

    // Assigning the function to the function pointer
    fooP = &foo; // your syntax may vary

    // Invoke a function through the pointer
    (*fooP)(); // prints "Hello, World!"


    Xecute isn't about function pointers. Function pointers require you to have a compiled function somewhere to point to. Xecute is about function bodies:


    // Compile this string as C source code inside
    // an anonymous function body, then execute it.
    xecute("printf(\"Hello, World!\\n\");");


    and in languages which have this kind of capability it tends to be used like this sooner or later:


    // Here's a string:
    char buf[1024];

    // Cut+Paste user input directly into some C code
    // as strings:
    sprintf(buf, "var[%s] = %s + %s;", argv[1], argv[2], argv[3]);

    // Compile and execute
    xecute(buf);


    Now if the user typed in "0", "2", and "3", then this compiles and executes:

    var[0] = 2 + 3;

    but if the user typed in

    0] = 1; system("c:/malware.exe"); var[0

    as the first variable then the results are a lot more interesting:

    var[0] = 1; system("c:/malware.exe"); var[0] = 2 + 3;
  • opie 2007-02-13 22:43
    It's ironic that someone mentioned the VA system...

    Check this out:
    http://www.tgdaily.com/2007/02/13/va_laptop_lost_18million/

    Yet ANOTHER one.
    There's no way these are all accidental.
  • triso 2007-02-13 22:45
    Remco G:
    See its Wikipedia page: http://en.wikipedia.org/wiki/MUMPS.

    Looks like the article wasn't exaggerated one bit. That Wikipedia article is full of wondrous WTFs by itself.
    Here's a good reason for keeping your money under your mattress: "MUMPS also gained an early following in the financial sector, and MUMPS applications are still in use at many banks and credit unions."
  • kavyboy 2007-02-13 22:54
    MUMPS is an abomination. I work with it daily, and there is possibly no worse computer language that has even been developed. Unmaintainable isn't even the word for it. My god, it's just... my god! I can post some real samples if anyone is interested. I seriously hurts to look at it, though. Goto branches named "4", and the like.

    Beyond syntax you get into the fun stuff:
    S X="10D2"+1
    S Y="10E3"+1
    S Z="10F4"+1
    This sets X and Z to 11, but Y to 1001. Obviously.

    Or how about the fact that there is NO standardization for input/output? The common solution is to put implementation-specific code into variables (agreed upon by convention only) then execute the variables to perform simple I/O. Yes, execute the variables.

    Oh, you can only have one I/O device open at a time. You have to switch between them with the "U" command. The current device in use is specified by the $IO variable, of course.

    And on and on it goes.
  • Watson 2007-02-13 22:58
    Meh, the offspring of an illegitimate orgy. The only language I haven't seen it compared to yet is FoxPro.

    I've realised something that's been bothering me:
    Because their MUMPS system was so ridiculously slow, it would often take minutes for a simple operation to complete. Reports would take hours.

    If using MUMPS was feasible forty years ago, what has happened to computing power since? Doesn't Moore's Law apply to it for some reason?

    CAPTCHA: tastey. "Like maybe what I think MUMPS coding's like was really coding like chicken."
  • TheQuux 2007-02-13 23:24
    Anonymous Coward:
    I always felt sorry for the AS/400 (sorry I meant iseries, no wait I meant system i....) folks that only knew RPG. How useful is RPG in an era of Unix/Linux/Windows?

    This MUMPS monstrosity puts RPG in perspective for sure.


    Last time I checked (last weekend), it was the "I series". Of course, that same IBM sales(err)person tried to sell me a Z series. (note: I'm a poor, starving college student...)
  • Dave Ross 2007-02-13 23:26
    I was just thinking how all those features made it sound like the illegitimate offspring of PHP and PickBASIC.


    I was thinking the same thing...*shiver*

    I have a similar story to the OP, having gotten my first programming job before I even finished my Associate's Degree. It was on Unidata, a Pick derivative. Then, from there, a Pick D3 shop. From there...well, until I got my Java certification nobody would talk to me about anything but Pick.
  • bucky 2007-02-13 23:41
    I'm a former Epic employee of around four years and this article is definitely about Epic. My role was not a true developer... more of a programmer / analyst where the coding needs were smaller projects in MUMPS (Technical Services).

    Personally, I didn't mind working in MUMPS or with the custom functions written to maintain Epic's data structure, think Epic treats its employees well, and disagree with some of the article's comments, but don't feel like going into that.

    What I do agree with is that the knowledge learned in such a role at Epic is a very specific skill set making Epic's customers or consulting firms likely employers of Epic folks (if they want to stay in health care after Epic). Epic makes it very difficult for employees to leave since employment agreements now typically state that the employee cannot work for customers until a year or so has passed since they left Epic. For employees that started before such a clause was added, customers also sign an agreement saying they will not hire ex-Epic folks for a certain amount of time.

    That may be off topic a bit, but felt it was an important "warning" despite what one may feel about MUMPS itself.
  • Zygo 2007-02-13 23:55
    dkf:
    Zygo:
    There is also no GOTO in Tcl, or at least it doesn't come with one (anything's possible if you start mucking with the language at runtime).

    I advise regarding GOTO as impossible in Tcl. The amount of work required to make even a simple C-like GOTO is quite enormous; it's far easier to handle exceptions, build state machines or drive automated resource deallocation by other means.


    Don't say things like that, someone might hear you and implement GOTO in Tcl...

    I wouldn't say GOTO is impossible in Tcl at all. Consider:



    # A label to go to
    begin_program:

    while {1} {
    # go up two blocks and forward
    if {[foo]} { goto block_exit }

    # go up two blocks and backward
    if {[bar]} { goto begin_program }

    # A label we can't actually get to from outside here
    forbidden_label:
    puts "in the while loop"
    }

    # We can't get here either
    puts "normal exit from while, should never happen"

    # Forward jump in this block
    goto end_program

    # A label we jump to from within while
    block_exit:

    puts "block_exit label, only if foo"
    exit 0

    # The forward jump ends here
    end_program:
    puts "end of the program"

    # Go backwards within this block
    goto begin_program



    It would be possible to jump out of while loops, procedures, etc. (e.g. block_exit) by implementing a new return code (like continue or break, but this one says "goto" and provides the label name in interp->result). A similar effect can be achieved by replacing the error, return, and catch commands with procedures. Once the call stack unwinds to a block (which is really just a text string) where that label is defined, the Tcl interpreter then starts executing from immediately after the label.

    It would be possible to jump around within a single block (e.g. begin_program, end_program) by modifying Tcl_Eval to understand the syntax (or replacing it with one that does). Since our goto command would be a procedure with a special return value (just like the break and continue Tcl commands are), this case is actually identical to the previous one (special return value with a label name).

    To do this within Tcl (i.e. without modifying Tcl) you'd have to replace just about every procedure that takes Tcl code as an argument (ironically including the proc procedure, which defines procedures) as well as uplevel, upvar, trace, etc. A pure Tcl implementation unfortunately won't handle cases like:


    set x [
    foo;
    bar: quux;
    if {[qux]} {goto bar} else {return 3}
    ]


    Fortunately within Tcl you can dynamically link in libraries to replace the built-in C functions.

    It would not be possible to jump into a block (e.g. jump to forbidden_label from outside the while loop) since the block's execution context doesn't exist and can't be created without first executing all the code leading up to the block containing the label...and even then this assumes you can predict which blocks are code and which are just data. Often you can't do this in C or C++ either (IIRC C++ explicitly forbids it, sometimes you can do it in C with a permissive compiler but the results are undefined) so even though this doesn't work it's still C-like.
  • Zygo 2007-02-13 23:56
    dkf:
    Zygo:
    There is also no GOTO in Tcl, or at least it doesn't come with one (anything's possible if you start mucking with the language at runtime).

    I advise regarding GOTO as impossible in Tcl. The amount of work required to make even a simple C-like GOTO is quite enormous; it's far easier to handle exceptions, build state machines or drive automated resource deallocation by other means.


    Don't say things like that, someone might hear you and implement GOTO in Tcl...

    I wouldn't say GOTO is impossible in Tcl at all. Consider:



    # A label to go to
    begin_program:

    while {1} {
    # go up two blocks and forward
    if {[foo]} { goto block_exit }

    # go up two blocks and backward
    if {[bar]} { goto begin_program }

    # A label we can't actually get to from outside here
    forbidden_label:
    puts "in the while loop"
    }

    # We can't get here either
    puts "normal exit from while, should never happen"

    # Forward jump in this block
    goto end_program

    # A label we jump to from within while
    block_exit:

    puts "block_exit label, only if foo"
    exit 0

    # The forward jump ends here
    end_program:
    puts "end of the program"

    # Go backwards within this block
    goto begin_program



    It would be possible to jump out of while loops, procedures, etc. (e.g. block_exit) by implementing a new return code (like continue or break, but this one says "goto" and provides the label name in interp->result). A similar effect can be achieved by replacing the error, return, and catch commands with procedures. Once the call stack unwinds to a block (which is really just a text string) where that label is defined, the Tcl interpreter then starts executing from immediately after the label.

    It would be possible to jump around within a single block (e.g. begin_program, end_program) by modifying Tcl_Eval to understand the syntax (or replacing it with one that does). Since our goto command would be a procedure with a special return value (just like the break and continue Tcl commands are), this case is actually identical to the previous one (special return value with a label name).

    To do this within Tcl (i.e. without modifying Tcl) you'd have to replace just about every procedure that takes Tcl code as an argument (ironically including the proc procedure, which defines procedures) as well as uplevel, upvar, trace, etc. A pure Tcl implementation unfortunately won't handle cases like:


    set x [
    foo;
    bar: quux;
    if {[qux]} {goto bar} else {return 3}
    ]


    Fortunately within Tcl you can dynamically link in libraries to replace the built-in C functions.

    It would not be possible to jump into a block (e.g. jump to forbidden_label from outside the while loop) since the block's execution context doesn't exist and can't be created without first executing all the code leading up to the block containing the label...and even then this assumes you can predict which blocks are code and which are just data. Often you can't do this in C or C++ either (IIRC C++ explicitly forbids it if there are local variables in the block, sometimes you can do it in C with a permissive compiler but the results are undefined) so even though this doesn't work it's still C-like.
  • cklam 2007-02-14 00:12
    themagni:
    Flo:
    Build in obfuscation? oO

    Appendix 7: An example of "traditional" M coding style
    

    %DTC
    %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
    ;

    SNIP

    [...]
    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.

    Brr.

    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 2007-02-14 00:20
    brainfuck (or whitespace) language seems, though alomst as senseless, but more joyful.
  • cklam 2007-02-14 00:28
    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.

    Haha.


    You think that is funny ? Remember, this a hospital you are talking about ... like, people's lifes are at stake !
  • hk0 2007-02-14 00:43
    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.
  • cklam 2007-02-14 00:55
    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):

    Donau-Dampf-Schiff-fahrts-kapitaens-Muetzen-Abzeichen

    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 2007-02-14 01:39
    Hank Miller:
    Saladin:
    me:
    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 2007-02-14 02:06
    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 2007-02-14 02:23
    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 2007-02-14 02:30
    rmr:
    Ruby on MUMPS anyone?


    I have a great name for it: Rubella!
  • Bill 2007-02-14 02:33
    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 2007-02-14 02:35
    vi(m) is not user friendly. It IS expert friendly.
  • squid 2007-02-14 02:36
    Heinz Gorgon:
    rmr:
    Ruby on MUMPS anyone?


    I have a great name for it: Rubella!


    how about RUMPS?
  • Anonymous 2007-02-14 02:36

    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 2007-02-14 02:56
    "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 2007-02-14 02:57
    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 2007-02-14 03:16
    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 2007-02-14 03:39
    I just don't believe!!!!

    --
    captcha: wigwam
  • Watson 2007-02-14 03:58
    Stas:
    works well with hierarchical data.
    So all it really needs is an XML parser...
  • Hans 2007-02-14 04:39
    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.

    /H
  • Geoff Connolly 2007-02-14 04:47
    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

    Geoff


  • Matt 2007-02-14 04:51
    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 2007-02-14 04:54
    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 2007-02-14 04:57
    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 2007-02-14 04:58
    Watson:
    Stas:
    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).
  • ExpatEgghead 2007-02-14 05:05
    I felt nasueous and slightly clammy after reading this one. Excuse me while I visit the bathroom.
  • no_star 2007-02-14 05:10
    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 2007-02-14 05:15
    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 2007-02-14 06:10
    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.

    Zygo:
    , 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.

    Zygo:

    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 2007-02-14 06:20
    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 2007-02-14 06:40
    From the FAQ (http://www.faqs.org/faqs/m-technology-faq/part1/):

    John Lewkowicz, The Complete MUMPS, p. xii:
    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 2007-02-14 07:44
    Oh god!!

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

  • chrismm 2007-02-14 07:46
    Just looked on jobserve, there are 7 jobs advertised for Mumps developers - frightening...
  • masklinn 2007-02-14 07:50
    fennec:
    Veinor:
    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>
    craaazy:
    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 2007-02-14 08:43
    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 2007-02-14 08:46
    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 2007-02-14 08:53
    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.

    /H


    The wikipedia article also mentions this article.
  • Anonymous 2007-02-14 08:57
    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 2007-02-14 09:14
    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? 2007-02-14 09:25
    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.

    http://en.wikipedia.org/wiki/Meditech
  • cynd 2007-02-14 09:26
    Sometimes, when you hate your job, you're too exhausted to even think about doing ANYTHING in your spare time.

    CAPTCHA: onomatopoeia - PING!
  • Brady 2007-02-14 09:28
    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 2007-02-14 09:31
    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.
  • Fabian 2007-02-14 09:33
    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 2007-02-14 09:35
    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.

    http://www.meditech.com/CorporateTimeline/homepage.htm
  • Kenneth Spicer 2007-02-14 09:54
    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 2007-02-14 10:08
    [quote="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. The original MUMPS system was, like Unix a few years later, built on a spare DEC PDP-7.[/quote]

    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.

  • Saladin 2007-02-14 10:22
    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 2007-02-14 10:33
    Anyone who doubts the existence of this language... do a search for "MUMPS" on Monster.com. Currently, they show 39 positions available.
  • maninthemachine 2007-02-14 10:55
    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 2007-02-14 11:36
    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.

    Jesus.
  • Anon 2007-02-14 11:42
    I spent the best part of four years writing code in CCSM Mumps in the mid 90's for a Software House producing shipping software in the UK. 50 terminals connected by RS232 connections - Arnet cards or Boca cards anyone? all powered by a 386dx

    The trick was to split the system into the "Code" database and the "DATA" database. The worst error was the dreaded "ERROR - SYSTEM 30" And yes it was Very fast becouse it used sparse arrays.
  • brunchboy 2007-02-14 11:46
    There are companies and recruiters that get it. I worked at the company described in this article for six years, although I didn't start as a freshly minted four-year graduate; I joined from a Ph.D. program in CS with all but my dissertation finished, so I was a bit better prepared to carve my own niche and defend myself.

    The criticisms of MUMPS/M/Caché are all valid, and don't go far enough in pointing out some of the deep flaws in the language and environment, although the points about the power and convenience of deep language/database integration are also valid. Sadly, the broader MUMPS community was well on the way to designing a modern, readable, expressive language called Omega which would preserve the power of that integration but let you write readable, concise, and disciplined object oriented programs, when that community was killed by InterSystems, the Caché vendor. They bought all the significant competitors in the MUMPS implementation ecosystem, and told the MUMPS standards body essentially "that's a neat idea, but we're now the only game in town, and we don't feel like implementing it."

    As for my fate, although I was fully immersed in learning how to write and support MUMPS code (I was one of the people who built the bridge from Visual BASIC controls to MUMPS database values, which was an interesting exercise in MUMPS code generating other optimized MUMPS code), I also found time in off hours to teach myself Perl, PHP and Java. I built a web-based graphical staff directory system in Perl which drew maps of the company and colored in people's offices, or let you click on rooms to see staff snapshots and contact information, perform searches including using regular expresssoins, or print out nice PostScript paper copies of the directory, eliminating tedious manual work for the administrative staff. I installed SCO (there was no Linux yet) on an old PC and got the company hooked up to the Internet.

    Because of all this, and the fact that even in MUMPS I was writing white papers to help developers code better as much as the environment allowed, explaining radical concepts like transactions and different kinds of locking for safe concurrent access, I had no trouble landing a different job in technologies I found more interesting and pleasant. Ironically, it was more the way the company was abusing Visual BASIC that prompted me to make the move; I didn't want to work for a Microsoft shop, especially one that was using the wrong tools for building what should be rich, powerful graphical applications.

    So as in any field, you have to take ownership of your career and continuing education. You get things back based on what you put in. There are certainly problems at the company, but where can you find a place that lacks any? There are also some smart and good people working there, and your work environment is strongly dependent on your team. It can be a fine place to develop broad skills and earn money, or it can chew you up and destroy your life for a time. Seeing that happen to a few too many friends was another big factor in my departure.
  • Mark 2007-02-14 12:09
    Brian, you poor poor bastard. Hold strong!
  • brunchboy 2007-02-14 12:21
    craaazy:

    But such changes, that in other languages are universally regarded as improvements, would, when applied to MUMPS, suddenly somehow sully the greatness of MUMPs?


    As I mentioned in another post, the MUMPS community was well on the way to building a really good modern language, with deep understanding of the human factors involved in writing and maintaining clean, powerful code. This language was going to be called Omega, and preserved the deep integration with a hierarchical database that was the value of MUMPS. But unfortunately, InterSystems bought all the other MUMPS implementation vendors, and told the MUMPS standards bodies that they might as well disband themselves, because InterSystems had no interest in implementing Omega, they had their own ideas.

    craaazy:

    I mean, come on, I read one comment here saying that using comments has negative performance impact on MUMPS.


    Yes, this used to be part of the new developer training at the company mentioned in this article. I don't think the impact is as serious as it once was, but you should see some of the legacy code.

    Even worse than the comments problem, though, is that there is no way to encapsulate code or data. Everything can access everything else; all variable space is shared unless you use expensive operations to make a variable local. And you can never be entirely secure about changing a routine, because any code anywhere else in the system can branch to it, by either label or line number. And some of the old code does this. Shudder.
  • brunchboy 2007-02-14 12:46
    CoderForChrist:
    I'm currently working in a MUMPS shop directly out of college.


    And you seem to be in peril of your immortal developer soul! I exaggerate slightly, but as other people have pointed out, you are in some danger of picking up bad habits and ideas, which are evidenced by your posting, so I will try to share my perspective. I worked at the company described in this article for six years, but I had significant graduate experience first, as well as some stints doing commercial work at major R&D centers for General Electric and AT&T Bell Labs, so I was able to defend myself from these pitfalls.

    CoderForChrist:
    MUMPS (or, M, as it's called now) is not that bad of a language in and of itself, especially considering its age. In fact, M can be maintainable, etc., if it was written well. The system described in the article, however, sounds horrid. I mean, I've seen some bad code, but that just blows me away.


    Actually, it is a bad language in and of itself, which has some really useful capabilities buried in there. If it wasn't useful in some way, nobody would still be using it. But the problems are real and significant. Some of them are so deep that it is impossible to write safe code in MUMPS. Even if you are careful yourself, someone else can come along later and do something that will make the system break if you change your own clean code, and there is no way for you to tell.

    This is because MUMPS lets code jump to anywhere else. Someone can branch to line 16 of your routine, from any other routine in the system. Then if you add another line in your code before line 16, that other code will crash or start doing the wrong thing, including corrupting data, and you won't know why. It will probably happen much later, when someone else is doing something unrelated.

    Features like that make it an inherently unsafe environment. Problems like the fact that white space is significant make it unsuitable for use by humans, for whom white space is not significant.

    The MUMPS community was well on the way to finishing the design on a replacement language called Omega, which had none of these deficiencies (nor the others I'm not mentioning). It was a modern, object oriented, encapsulated language that was easy to write, read and maintain, and it preserved the value of tight binding to the hierarchical database of globals. But InterSystems bought all other MUMPS vendors and killed off this community standardization effort.

    CoderForChrist:
    I actually like the fact that an array can have string subscripts. It makes sorting things, etc., much easier. Also, there's a function, $ORDER() that iterates through any array at a specific subscript level ($QUERY() iterates through all subscript levels at once).


    Yes, these are some of the nice features. Other modern languages have similar capabilities, but they are generally offered by libraries, so they aren't as easy to find or to use. The tradeoff is well worth it, however.

    CoderForChrist:
    M really isn't too bad once you're used to it, and if it's written well.


    The deep problems remain, even when you are used to it, and make it unsuitable for large-scale development with multiple, fallible human programmers. And it is impossible to write well in the sense of enforcing disciplined data encapsulation. Not with all the best intentions in the world.

    CoderForChrist:
    Granted, M doesn't conform to the ideals of certain programming experts, but that doesn't make it wrong. It's just a different way of doing things that, like anything else, can be abused to heck, but can also be useful when done right.


    This attempt to dismiss the criticisms shows that you don't really understand them. As you gain experience, you will. There are real flaws in MUMPS that can't be written around and that make it impossible to safely build large, maintainable systems. The benefits don't outweigh the risks. Omega would have changed that, but we won't get a chance to play with Omega.

    So, by all means continue to write careful MUMPS, but while you're at it learn Java and Ruby well, so you can continue to grow into a well rounded developer, and benefit from learning what's wrong with MUMPS rather than warping yourself to conform to (and be blinded by) its limitations.
  • Live N Breathe M 2007-02-14 12:52
    Every VA hospital uses M systems... Granted, you're most likely to work in M if you're working for the National VA IT folks. So, M is not exclusively found in Madison, WI. It's everywhere...
  • Kenneth Spicer 2007-02-14 13:05
    Add Saudi Arabia, Kuwaitt, and Gemany to the MUMPS list.
    When the VA analyzed their own software for Y2k compliance, they used a UK product!
    VA MUMPS code is public domain. You can file a FOIA request and open up shop in Mubai if you wanted to. Selling your IT support to every hospital in the district.
    Sound far fetched? A company in San Diego did that. Added some data fields for Military Rank, and sold it to the Dod for mega bucks.
    How's that for Value Added Resale? SAIC has gonads the size of Kansas!!
  • Kenneth Spicer 2007-02-14 13:05
    Add Saudi Arabia, Kuwaitt, and Gemany to the MUMPS list.
    When the VA analyzed their own software for Y2k compliance, they used a UK product!
    VA MUMPS code is public domain. You can file a FOIA request and open up shop in Mubai if you wanted to. Selling your IT support to every hospital in the district.
    Sound far fetched? A company in San Diego did that. Added some data fields for Military Rank, and sold it to the Dod for mega bucks.
    How's that for Value Added Resale? SAIC has gonads the size of Kansas!!
  • asciilifeform 2007-02-14 13:06
    MUMPS seems to have code-as-data representation, and a feature that is basically equivalent to lisp's EVAL. This puts it ahead of languages such as Java in my opinion.
  • Jan 2007-02-14 13:39
    The silliest thing about this account is the fact that the developer left the job off his resume, leaving a blank. Any prospective employer is going to look at a 2-year gap and assume the candidate spent the years smoking dope and playing WOW, or in prison. Even a job in MacDonalds is better than a gap.
  • Ricardo 2007-02-14 13:54
    I worked with MUMPS. I still have nightmares about it!
  • earl 2007-02-14 14:11
    brunchboy,

    That's too bad -- Omega sounds really interesting.

    For the record, I *really* liked the deep db / btree integration into the language. And I also liked the weakly typed db storage as opposed to SQL dbs.

    However, for all the other readers, the language made it verging on impossible to write maintainable code.

    An example:
    Mumps doesn't declare variables. I don't remember the compiler name for this -- I do math now, not programming -- but all variables are just created on first use. So when you use a variable, there is some notion of the current set of known variables. If you use a known variable, you change it's value; if you use an unknown variable, a new variable is allocated for you.

    Sound good?

    Problem is, in most functions, you don't want to muck around with variables declared somewhere up the call tree. Instead, you want to mostly work with local variables.

    To get a local variable, you just say "new k" or "n k", ie create a new variable named k local to me. The problem: you have to declare them. If you forget, your code will work -- remember, most variables names are short and this program is huge, so they're probably used somewhere -- and will have *wildly* unpredictable effects, not least because what will happen depends on who is calling the function! This leads to *impossible* to find bugs, and indeed, a senior VP is famous for creating a terribly hard to find bug this way.

    Now, MUMPS does have support for 'new'ing *all* defined variables, by just saying N. However... this is horridly expensive to do, so you are banned from doing it.

    Meh.

    earl
  • Jimbo 2007-02-14 15:02
    I cry for this developer. And I'm working in a vb6 shop.
  • old mumps guy 2007-02-14 15:16
    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.
  • not surprised 2007-02-14 15:30
    Back when I was a grad student, I had to be a Teaching Assistant for a class that taught MUMPS in an introductory class to non-CS and non-engineering students.
    Two WTFs for you there...
  • Chick Counterfly 2007-02-14 16:14
    I think there are a few different factors at work here :

    1) Fresh, young programmers don't want to work on yesterday's old-and-busted crap.

    Yes, MUMPS may have been hot shit back in the the PDP-7 days, but now it's just an antique. Young programmers are versed in all sorts of cool things like OOP, SQL, and AJAX. They don't want to code in something that was only impressive during the (first) Nixon administration.

    Even the oldsters in this thread should be able to relate - imagine if, your first day on the job as a programmer, someone handed you a desk calculator and told you to go to town.

    So yeah, leave the legacy jobs for the dudes like the programming language mortician a few comments back who suggests that we go from one dying platform to another, waiting for the businessheads to come to their senses and put these poor platforms out of their misery.

    2) Some businessheads are really short sighted, and will go to ridiculous lengths to keep an old codebase running. To young programmers, versed in theory and best practices, this comes like a slap in the face.

    This has been done to death here on DailyWTF, so there's really no point in rehashing.

    Heh. Kinda reminds me of the companny I did my internship for. They had this scary-ass VBA/Access program that was too much of a mess to port to VB/SQLServer. They even went as far as to implement multi-user access to the single-user Access app through Windows Terminal Services. I don't think this program ever worked properly.

    3) This dude, Bryan, must live someplace where the IT labor pool is really, really tight. South Dakota perhaps?

    Seriously, where is 2 years programming experience not enough to land even an entry level job?

    I don't agree with the merciless bastards in this thread who think that once someone learns a 'bad' language, that they're screwed for life. I cut my teeth on AppleBasic, then spent a number of years dabbling in classic C before moving on to Java and C#. People can always learn, if they want to.

    Plus, if you've spent 2 years coding in any language, then you've spent two years learning some of the most important skills for a programmer - problem solving, debugging, maybe even some requirements analysis.
  • Zygo 2007-02-14 16:17
    craaazy:

    Zygo:

    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.


    There is no compiler in Mumps. There is an interpreter which might do dynamic machine code generation as an optimization, but only when it doesn't conflict with the semantics of the language.

    craaazy:
    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.


    Now here you are misunderstanding the term interpreter. Java is absolutely a compiled language. The fact that the compiler's normal binary format is bytecode for an abstract virtual machine does not change Java's nature--there is an explicit, lossy, unidirectional process which translates the data structure of the source code into the data structure of executable code, after which recovery and manipulation of the initial source code data structure by the running program is non-trivial (aka compilation). No such process exists in Mumps, and adding it would result in a language that is unable to implement Mumps code except by implementing a Mumps interpreter.

    IDE's are useful with compiled languages because the language usually has lots of syntax and structure (so the IDE can get the data it needs) that is discarded as the program is translated into an executable (so the user can't get this information by directly querying the running program itself). IDE's are much less useful with interpreted languages because neither assumption is true--the IDE can't find any useful information because the meanings of expressions are indeterminate until just before they are executed at runtime, and users can simply query the interpreter directly if they want to examine the structure of the program. An IDE therefore brings no additional value since the few of its features that do something useful are redundant.

    Even if there is a compiler hidden in the implementation, there is still no compilation idiom in the Mumps language--in fact, in any case where adding a compiler to the language conflicts with the established semantics of the language, the compiler is usually forced to become an interpreter to remain in compliance with the language spec. This makes most IDE-like tools, which tend to be designed for compiled languages, somewhat useless. How is an IDE supposed to work when half the code of the program doesn't actually exist until runtime?

    In languages where code generation is idiomatic, such as LISP and its many imitators, it's fairly normal for programs to write other programs, then execute them whenever they want something done. Some LISP functions take other LISP functions as arguments, inspect their code, modify it here and there, then execute it, and LISP developers understand this and use it to great effect (although only when strictly necessary, since it adds a non-trivial layer of indirection between the code as it appears on screen and what it actually does in the machine).

    Translating a non-trivial LISP program to another language is usually only feasible by writing a LISP interpreter in the other language, because non-trivial LISP programs tend to rely on having the program code available as a modifiable data structure at runtime. This requires that the language, the language's parsed expression tree, and the language's intrinsic data types all be isomorphic to each other--a property that so strongly influences a language's form that it almost always looks like LISP, maybe with different-shaped brackets and renamed functions.

    Mumps is an example of Greenspun's tenth law in action--it's about half of LISP, specifically the half that allows you to generate and inspect code as a built-in data type. Unfortunately that data type is string, so doing the other half of what LISP can do in Mumps requires implementing a Mumps parser and code generator in Mumps.

    In MUMPS you can't do any of the following without removing most of the benefits of the language:

    - refactoring: IDE can't find code to refactor if it doesn't exist until runtime.
    - context highlighting: no better than LISP, questionable utility when data and code intermix freely--lots of falsely highlighted text if you are inspecting data instead of code, for example.
    - pretty printing: no better than LISP (in fact probably worse)
    - validation: only trivial cases are possible, some code may not even exist until it is actually executed on a production system or clone thereof.
    - nice lists to pick method/classnames, etc. - it's probably possible to build a mostly-working class browser but you won't be able to do things like right-click on variables and get method names, since the variable's types are all unknown to the IDE.
  • Zygo 2007-02-14 16:26
    iogy:
    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.


    MUMPS used to be the platform. You'd run it on bare hardware (e.g. your spare PDP-7) where we would normally put an OS today...
  • jesternl 2007-02-14 16:32
    MUMPS is alive and kicking, unfortunately.
    One of our programmers is just about done converting from MUMPS to Cache, another wonderful product owned by InterSystems.

    Many hospitals still use it as far as I know
  • ilovemumps 2007-02-14 19:47
    I don't think that much of this criticism is fair. I work for a similar company as Bryan (perhaps the same). I had a hard time getting a job out of college, even though I went to a good school and got good grades with degrees in math and physics. I am glad that this company hired me and has given me some programming experience, work experience, and a salary. There is no way that is a bad thing.
  • MUMPy 2007-02-14 19:57
    That's a funny story! Too bad it doesn't work like that. K ^<enter> won't do anything. Now, you can kill a global array by typing K ^gloname <enter> and you can easily wax an entire array of data, i.e. financial data, registration data, lab tests, etc. Better hope your backups are reliable.
  • MadCowCoder 2007-02-14 21:50
    Umm... where to start... I've been lurking on Daily WTF for years now... got many laughs and quite a few eye opening "aha" moments. I am in the military and thus will soon be the recipient of all this VA MUMPS mess. In todays modern environment of blazing fast computers (the modern cell phone is many times more powerful than the old mainframes of yester-year) it seems criminal that this botched abortion of a computer language is still around. I honestly believe that in today's world where HIPAA applies, *any* system written in M[UMPS] is a massive lawsuit waiting to happen (where's an ambulance chaser when you need one). I'm not a compiler guru, nor a super coder guru either... but this is horrifying! For starters, this language appears to have no type safety what-so-ever... everything is a string??? Does that mean when the program expects a number I can type "Delete *.*" and wipe everything? I'm assuming that multiple users are using the same system... what about thread safety? What about data integrity? How can a system ensure the integrity of the data it is using, when the integrity of the system itself is so suspect? Imagine if the code controlling the nuclear command and control was written in this language... would you feel safe? That this system persists is a marevelous example of ego, hubris and greed. Not only on the part of the vendor, but hospital administrators who are so short-sighted to not see the danger. I read this article and my I'm reminded of the emperor and his new clothes... Except it is my health data that is naked!
  • Ed 2007-02-14 23:16
    So I also got a job right out of college that does Mumps programming, and I find this a very interesting language, and not really interesting in a good way. I don't hate it as much as Bryon, but that could also have something to do with my job description. Luckily, I'm not locked into mumps, so I also get to work in SQL, Oracle, .Net, VB, ASP, and basically anything else non-mumps that my company seems to think I can just pick up at the drop of a hat.

    So one of my favorite things about M that the article didn't discuss is the Else statement (I didn't see if someone else posted something about this, but I couldn't make myself read through over 200 posts about how C++ is the best language ever). See, there is this system variable called $T. $T gets set to 1 or 0 by all sorts of operations, If sets it, opening a device sets it and I'm sure there are some other commands that also set $T. So Else is really just a short hand for saying If Not $T. So if you have a If statement that does some operation that sets $T, the Else statement following the If may also execute! Try debugging that one.

    But really, Bryon's horror story about the way the system was written is really no different that that SQL database where the tables had meaningless names such as A, B, C, D and each table had 50 varchar(255) columns all named A, B, C, D, ...

    Storing the code in a global, then executing the global is just poor system design. The XCECUTE command is really slow. If you just took that code and saved it into a routine, it would run much faster. The thing is, mumps is not compiled, at least not the same way C++ code is compiled. It is interpreted. So really what that means is that each client can have code that is easily modified and customized without needing to store the code in some global.

    There are some really cool things you can do with the X command though. You can have a global that defines where different pieces of information are stored. Basically you would store the global name and the indexes to that global. Then you use that definition of your data to find where it is stored in the global. So basically you can turn a heirarchical database into a relational database.

    M has a couple of advantages over relational databases. First, it uses disk space much more efficiently. If there is no data for an index of the array, then there is no empty space allocated for that index. The second advantage is in data access. If you know the indexes into the array, it finds the value in the array immediatly. In a relational database, the system has to use indexes or table scans to find that data.

    The disadvantages are many, but what M was designed to do, it does extremely well. And like anything else, if you put it in the hands of morons, you will get crappy code.

    Bryon should not really have a problem finding a new job if he is willing to do some work in M.
  • Ed 2007-02-14 23:23
    MadCowCoder:
    Umm... where to start... I've been lurking on Daily WTF for years now... got many laughs and quite a few eye opening "aha" moments. I am in the military and thus will soon be the recipient of all this VA MUMPS mess. In todays modern environment of blazing fast computers (the modern cell phone is many times more powerful than the old mainframes of yester-year) it seems criminal that this botched abortion of a computer language is still around. I honestly believe that in today's world where HIPAA applies, *any* system written in M[UMPS] is a massive lawsuit waiting to happen (where's an ambulance chaser when you need one). I'm not a compiler guru, nor a super coder guru either... but this is horrifying! For starters, this language appears to have no type safety what-so-ever... everything is a string??? Does that mean when the program expects a number I can type "Delete *.*" and wipe everything? I'm assuming that multiple users are using the same system... what about thread safety? What about data integrity? How can a system ensure the integrity of the data it is using, when the integrity of the system itself is so suspect? Imagine if the code controlling the nuclear command and control was written in this language... would you feel safe? That this system persists is a marevelous example of ego, hubris and greed. Not only on the part of the vendor, but hospital administrators who are so short-sighted to not see the danger. I read this article and my I'm reminded of the emperor and his new clothes... Except it is my health data that is naked!


    There is a lock command that is used to ensure concurency.

    If you try to use a string value as a number, it gets translated to 0.

    The real danger of these systems is that it's fairly easy to break in. You access M using telnet, so a simple packet sniffer is all you need to grab an account. Once you get on the system, you can just dump entire globals to the screen or to a file, and then you have all the data. Of course, you might not really know what to make of it all, but things like SSN, Address, and Name are pretty obvious. Dates are not obvious, so DOB would not just jump out at you.
  • Ed 2007-02-14 23:28
    jesternl:
    MUMPS is alive and kicking, unfortunately.
    One of our programmers is just about done converting from MUMPS to Cache, another wonderful product owned by InterSystems.

    Many hospitals still use it as far as I know


    Interesting thing about Cache, is that it's really just Mumps. You can write code in a VB like syntax, but it "compiles" that into M code.

    It certainly is interesting though. Cache is trying to be an object oriented database as well as a relational database as well as a heirarchical database all in one.

    The latest version of Cache does have a data adapter for .Net and has the technology to integrate with Java and ActiveX languages basically the same as connecting to SQL Server or Oracle.
  • Multi-Lingual 2007-02-14 23:37
    So I've read most of the comments on this WTF. The thing I find funny is how many of you think that the language or technology you work in is the "end-all", and should be used for everything. "They should switch over to .net technologies...WTF". "Man, they should use PERL...WTF".

    Let me ask you, WTF? Do you think that one tool is the perfet one for every need out there? If you do, you need to go back to school, kid. There's a reason that there are so many languages and so many technologies out there - it's because none of them are perfect. None are the right tool for every job.

    You might be the kind of guy that uses a hammer to pound in a nail, then decides that it's the best tool for every job. Hell, install a kitchen sink - just hit it with a hammer. Change the oil? Hit it with a hammer! Have sex with your girl? Hit her with a hammer!

    Truth is, you need to go look at what the job is and then determine what your best tool is. Maybe you'll learn something. Probably not.

    Here's what's really humorous: You have a successful company out there with a successful product. But who do the WTF'ers listen to? Brian - the kid 2 years out of college with no real experience who couldn't adapt, so he had to drop out. He's really good - so good that he still can't find a freakin' job! Yet, you trust his judgement of technology over that of a successful company. WTF?!??!!
  • Multi-Lingual 2007-02-14 23:47
    MadCowCoder:
    Umm... where to start... I've been lurking on Daily WTF for years now... got many laughs and quite a few eye opening "aha" moments. I am in the military and thus will soon be the recipient of all this VA MUMPS mess. In todays modern environment of blazing fast computers (the modern cell phone is many times more powerful than the old mainframes of yester-year) it seems criminal that this botched abortion of a computer language is still around. I honestly believe that in today's world where HIPAA applies, *any* system written in M[UMPS] is a massive lawsuit waiting to happen (where's an ambulance chaser when you need one). I'm not a compiler guru, nor a super coder guru either... but this is horrifying! For starters, this language appears to have no type safety what-so-ever... everything is a string??? Does that mean when the program expects a number I can type "Delete *.*" and wipe everything? I'm assuming that multiple users are using the same system... what about thread safety? What about data integrity? How can a system ensure the integrity of the data it is using, when the integrity of the system itself is so suspect? Imagine if the code controlling the nuclear command and control was written in this language... would you feel safe? That this system persists is a marevelous example of ego, hubris and greed. Not only on the part of the vendor, but hospital administrators who are so short-sighted to not see the danger. I read this article and my I'm reminded of the emperor and his new clothes... Except it is my health data that is naked!


    So you know nothng about M/MUMPS/Cache, yet you are ready to pick out its shortcomings? Hello? You don't KNOW the shortcomings. You readily admit that you are not a super coder or a computer expert. You certainly are not a healthcare expert. Let's see that leaves you.... not in a position to criticize, doesn't it.

    Hate to tell you this, but if you've been to a hospital in the last 30 years, received a bill, had lab tests done, etc., your data is most likely stored in a M database. Are you aware that any company working in healthcare knows a lot about HIPAA? Do you think you are the first person to think about data security in healthcare? Hello?!?!?!

    You can't just type "DELETE" at a prompt and have it delete your data. That is something you might see in a movie, but it is probably not happening in your hospital information systems.

    Good code is not inherent in any language. Neither is bad code. You write good code in M, you get good applications that are quite capable and quite quick. You write bad stuff and you get bad apps. It's just that simple. You write good code in C++, you get good apps. You write bad code, you get MS Vista.

    Quit making generalizations and stupid comments about something you obviously know nothing about. WTF?
  • cklam 2007-02-14 23:53
    me:
    Hank Miller:
    Saladin:
    me:
    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?


    WinVi is very good and has a very nice ability to handle very large textfiles.

    It also supports on-screen notepad-like editing - so you have the best of both worlds. I usually just dump the exe into %windir% and rename it to vi.exe.



  • Gnudiff 2007-02-15 02:11
    Okay. Let me get this straight before people start lynching me. Most of my programming experience is in newer languages like C++, Java, Python and (yes, also) PHP. I fully admire (some of) them compared to MUMPS.

    However, MUMPS was definitely way better back in even 80ies, than a LOT of stuff that was available! You could do stuff that was near impossible in those days Pascal or BASIC or what-have-you. Same with REXX (used on some IBM mainframes running VM/ESA) and some other mainframe languages.

    String+number based arrays? Wonderful stuff. Took years until any widely accepted programming languages started using them.
    Hell, arrays had to be FIXED size those days - in C, in Pascal, in BASIC, OK? There was no STL (not to talk of C++ in general), there was no VB, there was no Java, there was no OOP at all either.

    All that creep about having lots of subroutines, etc, - yes, those were rather abominable. However, an important point - those machines were running on resources that would make any present day programmer exasparate trying to squirm in a helloworld program!

    When I learned of MUMPS, it was WAY more powerful than the general purpose programming language implementations of those days.

    Okay, by now you can replace the indeed bloated code in any MUMPS application, with about twice as much bloatware in a language of your choice. You would be getting better maintainability, I suppose. Okay, I lie. You could probably use normal client-server and a decent RDBMS and not get a mess, however, as indicated by most of the stories here, up-to-date technologies don't provide any immunity to WTFs.

    I -would- definitely give serious consideration for taking on job a programmer who has spent 2 years working on a MUMPS app. If he has been able to make sense in there, he can do anything.

    Top Cod3r:
    First of all, for all you newbies out there, you want to store your code in a global array for performance optimization purposes. You see global arrays get optimized by the compiler making them as much as twice as fast as normal arrays.

    (...)
    The only WTF about this is why you guys all think this is a WTF. Maybe you just dont understand MUMPS.


  • Skroog 2007-02-15 04:23
    Top Cod3r:
    All MUMPS code was stored in a Global Array named ^ROUTINES. The only code that existed outside of this array was stored in “Application Startup” codefiles, each containing a single line of code: X(^ROUTINES("XSTARTGB")). The only difference between each file was the last two characters, or, the application identifier.


    First of all, for all you newbies out there, you want to store your code in a global array for performance optimization purposes. You see global arrays get optimized by the compiler making them as much as twice as fast as normal arrays.

    And the code in the Application Startup codefiles was probably put there for flexibility purposes, since startup code only gets executed once it doesnt need the performance boost offered by global arrays.

    The only WTF about this is why you guys all think this is a WTF. Maybe you just dont understand MUMPS.


    Muahahaha... OMG!

    From what I read in the FAQ-Link someone provided I mentally cried and shivers ran down my spine.

    Thanks for making me laugh again with your comment!
  • Asbjørn Ulsberg 2007-02-15 05:26
    What? No source code? I want to see this wonder language in action, dangit!

    CAPTCHA: "doom". O RLY? YA, RLY!
  • iogy 2007-02-15 06:05
    Skroog:

    Muahahaha... OMG!

    From what I read in the FAQ-Link someone provided I mentally cried and shivers ran down my spine.

    Thanks for making me laugh again with your comment!


    Yeah, it seems that all that bleeding speed and optimization is made worthless because you ruin programmer's minds with it.

    What's the use of having something that's "blazing fast" (when it's interpreted and you still have the human FUBAR factor) if you make your employees sad?
  • woohoo 2007-02-15 09:46
    asuffield:
    Much of this stuff is not new (sadly). And I say that in the full knowledge that MUMPS is from the 1970s.


    The primary design goal MUMPS was to create code that, once written, can never be maintained by anyone ever again.


    APL.


    CASE SENSITIVITY: Commands and intrinsic functions are case-insensitive. Variable names and labels are case-sensitive.


    Numerous flavours of BASIC did this.


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


    Not a WTF.


    LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.


    Many forms of BASIC did this, only without the ability to use string keys.


    Within each application lived hundreds of modules, and within each module lived thousands of routines. All of these routines shared the same environment. To ensure that global arrays and code didn’t get mixed up, a strict naming convention was followed. Each routine name was no more than eight characters, and consisted of a two-character application identifier, a two-character module identifier, and a two-character routine identifier.


    This one is right out of the system/360 playbook, and probably goes back even further.


    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.



    it's true that many versions of BASIC did similar things, but remember the meaning of the acronym?

    *Beginner's* All-Purpose Symbloic Instruction Code

    that is, no one in their right mind would use BASIC for large applications.
    oh wait, I forgot about VB.... no, just as I said, no one in their right mind! ;o))
  • NotARobot 2007-02-15 09:56
    Did anyone see this further WTF in the Wiki article?

    Reserved words: None. Since MUMPS interprets source code by context, there is no need for reserved words. You may use the names of language commands as variables. There has been no obfuscated MUMPS contest as in C, despite the potential of examples such as the following, perfectly legal, MUMPS code:

    GREPTHIS()
    NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
    IF IF=THEN DO THEN
    QUIT:$QUIT QUIT QUIT ; (quit)
    THEN IF IF,SET&KILL SET SET=SET+KILL QUIT
  • Ed 2007-02-15 10:29
    NotARobot:
    Did anyone see this further WTF in the Wiki article?

    Reserved words: None. Since MUMPS interprets source code by context, there is no need for reserved words. You may use the names of language commands as variables. There has been no obfuscated MUMPS contest as in C, despite the potential of examples such as the following, perfectly legal, MUMPS code:

    GREPTHIS()
    NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
    IF IF=THEN DO THEN
    QUIT:$QUIT QUIT QUIT ; (quit)
    THEN IF IF,SET&KILL SET SET=SET+KILL QUIT


    That code does not work. There is no THEN command in M. Also, the : is a conditional, so it says "do this command if this condition is true", so you don't need Q:$Q Q Q, it would just be Q:$Q Q.

    I'm not sure what $Q would return without giving it a parameter, it is a function after all.

    There are too many problems with that code here to list them all. It won't run. You will get syntax errors.
  • Ed 2007-02-15 10:39
    Ed:
    NotARobot:
    Did anyone see this further WTF in the Wiki article?

    Reserved words: None. Since MUMPS interprets source code by context, there is no need for reserved words. You may use the names of language commands as variables. There has been no obfuscated MUMPS contest as in C, despite the potential of examples such as the following, perfectly legal, MUMPS code:

    GREPTHIS()
    NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
    IF IF=THEN DO THEN
    QUIT:$QUIT QUIT QUIT ; (quit)
    THEN IF IF,SET&KILL SET SET=SET+KILL QUIT


    That code does not work. There is no THEN command in M. Also, the : is a conditional, so it says "do this command if this condition is true", so you don't need Q:$Q Q Q, it would just be Q:$Q Q.

    I'm not sure what $Q would return without giving it a parameter, it is a function after all.

    There are too many problems with that code here to list them all. It won't run. You will get syntax errors.


    I take that back, it does work, but the spaces at the beginning of the lines are important. THEN is a tag, so DO THEN goes to that tag and does not execute "KILL". I'm still not sure about that QUIT:$QUIT QUIT QUIT. Since this is declared as a function, the last quit needs to return a value, so something like this is probably what the author was looking for.

    QUIT:$QUIT QUIT QUIT ""
  • Multi-Lingual 2007-02-15 10:51
    I have yet to see a language where you can't write crap code. The code shown in the examples is pretty bad, but I'd venture to guess that we could come up with some pretty horrific code in any other language as well.
  • chuck 2007-02-15 11:12
    Sorry if I'm duplicating anything here guys, but I just now got to this one in my reader and don't have time to go through 200+ comments.

    It appears that a few people actually working as MUMPS developers have hit this thread to defend it a little. They have some good points: written well, MUMPS doesn't have to be a total nightmare. The "traditional" style is to use the one-letter abbreviations for everything, but there's no rule that you have to. The disk-resident global datatype is actually kind of cool -- it's basically a hierarchical-model database that you access as a native datatype in the language, without a lot of dancing around with making a database connection, etc. MDH (Multi-dimensional-hierarchical) database is a rather nice model for things that don't always fit neatly into the relational model. Many-to-many relationship tables? No need for them.

    The only reason I know as much about MUMPS as I do is that I actually took a course at university in which we used MUMPS to do full-text indexing. We used a MUMPS-to-C++ compiler written by the professor, and I have to say I was actually kind of impressed with how powerful it could be with a small amount of code. Said compiler makes use of an MDH library for C++ written by same professor, so there was the option of using C++ as well, so for anything that got particularly complex, it was feasible to do part of the project in C++ and have both MUMPS and C++ code able to access the same data. The final project for the course was to build a search engine for a library of medical research articles using a web front-end that ran our compiled MUMPS programs in CGI.

    That said, MUMPS is a weird, esoteric little language. To be sure, its quirks were probably less WTFey in the 60s and 70s than they are today. What's WTFey is that there are still companies using it almost exclusively. I rather think that MUMPS may still have a legitimate place in modern data processing -- it's basically a scripting language for a certain kind of database, so its usage today rightly should be more in a similar role as SQL, but operating on a different model. SQL can be pretty WTFey too, especially if you were to try to write an entire (or nearly an entire) application with it, entirely in stored procedures.

    Also, I'm a bit of a dead-programming-languages enthusiast. Me and a classmate from that course offered to maintain a Debian package for the professor's MUMPS compiler but nothing ever came of it. Anyway, for a pile of info about MUMPS (and lots of sample code!) for the curious, check out the aforementioned professor's page: http://math-cs.cns.uni.edu/~okane/
  • chuck 2007-02-15 11:18
    Oh, and I think you can download the compiler from that site too, for the guy who said he wants to "see this language in action." :-)
  • mumpalito 2007-02-15 12:26
    EPIC Systems is the MUMPS shop in Madison

    IDX (now part of GE) is the MUMPS shop in Burlington, VT

    Cache (what MUMPS has evolved too) developed by Intersystems is the only commercial MUMPS vendor any more

    Some large company's use Cache/MUMPS. Ameritrade for one.

    As an independent consultant I do okay by Cache/MUMPS. I bill out at about $100.00 per hour.
  • Mumpy McMumpster 2007-02-15 13:44
    Don't kid yourself. MUMPS is heavily embedded in alot of labs and hospitals...especially in billing systems.

    Don't think of it as a dead end job, think of it as an exciting way to insure you will have a job in the medical industry for decades to come!
  • A nonny moose. 2007-02-15 14:08
    Sgt. Zim:
    Edit: And in my experience, everyone that uses it either absolutely hates it, or has consumed the Kool-Aid and absolutely loves it, and will extol its "virtues" at great length. There doesn't seem to be a middle ground with this pile of crap.


    Hmmm... with the caveat that I have little formal programming experience outside of a data structures class and some intro stuff, but my primary job for the past ten years or so has been coding in some sort or another, I'll say that I neither love nor hate MUMPS. It's just another language with its own little peculiar quirks and syntax... another tool in the box.

    I've used Java, IDL, Visual Basic, C++, Pascal, and Basic for various and sundry tasks in the past. Sometimes I took advantage of objects when they were available, sometimes I didn't...

    Is everyone this picky about their brand of hammer?
  • Ornedan 2007-02-15 16:01
    A nonny moose.:
    Sgt. Zim:
    Edit: And in my experience, everyone that uses it either absolutely hates it, or has consumed the Kool-Aid and absolutely loves it, and will extol its "virtues" at great length. There doesn't seem to be a middle ground with this pile of crap.


    Hmmm... with the caveat that I have little formal programming experience outside of a data structures class and some intro stuff, but my primary job for the past ten years or so has been coding in some sort or another, I'll say that I neither love nor hate MUMPS. It's just another language with its own little peculiar quirks and syntax... another tool in the box.

    I've used Java, IDL, Visual Basic, C++, Pascal, and Basic for various and sundry tasks in the past. Sometimes I took advantage of objects when they were available, sometimes I didn't...

    Is everyone this picky about their brand of hammer?
    Yes. Because a rubber hamer really isn't that usefull a tool. Or, a more appropriate analogy for MUMPS, one with spikes jutting out of the grip.
  • Bill P. 2007-02-15 16:43
    You said:

    "MUMPS had some WTF's about it. The big one I remember is being told to keep comments to a minimum because they slow down the code's execution. "
    ----
    Comments are removed by the compiler and have no effect on executable code.


    You also said:
    "It also had some cool features. Being able to store code in a variable and execute it made it easy to customize the app for different clients. "

    ---
    The behavior your describe sounds like a function pointer to me. C/C++ both have this feature as do other languages.


  • Bill P. 2007-02-15 17:07
    My sentiments exactly.

    I'm ready for battle brother.
  • DrCode 2007-02-15 19:37
    gwenhwyfaer:
    Ebs2002:
    I feel bad for Bryan... because he can't find something else because he stayed for 2 years.

    I feel bad for Bryan because he's managed to land in the one so-called "profession" so abusive to its members that two years of hard-earned debugging skills in an esoteric architecture, from scratch, can be dismissed out of hand....

    I'm dismayed at the number of people working in the field who think that this is somehow acceptable. ... Sometimes I think the whole damn software industry behaves like an abused wife who insists that her husband has every right to beat her senseless, because she's headstrong and keeps stepping out of line.


    True dat.
  • menriquez 2007-02-15 23:27
    earl:

    Mumps doesn't declare variables. I don't remember the compiler name for this -- I do math now, not programming -- but all variables are just created on first use. So when you use a variable, there is some notion of the current set of known variables. If you use a known variable, you change it's value; if you use an unknown variable, a new variable is allocated for you.

    Sound good?


    Sounds like PHP to me, and oh yeah, in PHP all vars are represented by one data type...and isn't PHP one of hottest new languages around these days?

    WTF?
  • Eberhard W Lisse, MD 2007-02-15 23:43
    MUMPS was developed in the late 60' (before you hot shot programmers were born :-)-O).

    The whole VA hospital system was/is running (nicely) on it. And the source code is available under the FoI Act. I know of at least one hospital system in a developing country that is running it (successfully).

    I know of a hospital pharmacy system in Germany running a MUMPS based package for 30 years on varying hardware, and it is definitively not broken, so they ain't gonna fix that one either.

    So, it's not really a WTF. Other than being unemployed...

  • rp 2007-02-16 05:59
    aThe point of the "vi is modal" remark is that vi is user-unfriendly for that reason. What matters here is that in a modal application, the same user actions behave differently, depending on the application state in which they are issued.ESCa

    An application mode can be regarded as a maximal set of application states in which all user actions have the same effect.ESCa The original vi is modal in that sense: most of the time is spent switching between normal mode and character append modeESCa (some is spent in ex mode, and open mode I've never used.)ESCa The usability problem is that 1) many keystrokes have radical effects in normal mode, and 2) normal mode and character append mode aren't indicated visually. ESCaAs a consequence, one spends vast amounts of time undoing mistakes resulting from keystrokes having been typed in the wrong mode. ESCa

    A reflex I developed when working with vi was to press the escape key as soon as I stopped typing text. That way, I no longer had to guess which mode I was whenever I resumed working, and I no longer had to spend 10% of my time cleaning up vt100 control sequences resulting from pressing arrow keys in append mode.ESCa vim's behaviour may be more complex, but it effectively fixed this problem for me, and the reflex has ceased.


    ESC
    ZZ
  • the-moss 2007-02-16 11:05
    Bill P.:
    You said:

    "MUMPS had some WTF's about it. The big one I remember is being told to keep comments to a minimum because they slow down the code's execution. "
    ----
    Comments are removed by the compiler and have no effect on executable code.


    That is not true. See below, question 28.

    http://www.vmth.ucdavis.edu/m/m_faq1.htm:


    For normal comments, if they are at the end of a line that already has code
    on it - there is absolutely NO effect at all on performance, so comment to
    your hearts content.

    If the comment is all that is on the line, there is still a beginning of
    line token - which can be expensive, esp. in frequently executed loops. The
    reason is that the BOL token does a lot of work after every so many lines
    ,
    such as allow the next process to run (on systems like DTM), or check for
    ^C,RESJOB, or other inter-process communication.



    Bill P.:

    You also said:
    "It also had some cool features. Being able to store code in a variable and execute it made it easy to customize the app for different clients. "

    ---
    The behavior your describe sounds like a function pointer to me. C/C++ both have this feature as do other languages.


    Not really. In C/C++ you cannot take a line of code (be it a a simple executable line or a function call) into a string at runtime and execute it.

    While this certainly allows you to step on your own dick it is very powerful for customization.
  • Dave 2007-02-16 11:36
    Back to Bryan's problem, he needs to LIE!
    He was a VB programer for those 2 years.
    He can then proceed with a stress-free life in IT.
  • SeaTea 2007-02-18 16:02
    "My programming language of choice is better than your programming language of choice."

    SeaTea

    "While rock guitarists and programmers share a personality style characterized by arrogance, self-absorbtion. delusions of grandeur, and a tendency toward dogmatic absolutism, it is nevertheless the case that guitar players get more women." - C. Thomas
  • b0x0rz 2007-02-20 04:58
    love the google ad on the sidebar of this:

    MUMPS/Cache Programming
    InterSystems Cache Certified Expert Programming, Design, Conversions
    www.mumpsprogrammer.com

    LMAO
  • Tuomas 2007-02-23 10:05
    "They're just all trying to hook up with teenagers on MySpace. "

    And who wouldn't?

    Must be dead if won't even try. ;)

    "Age is a mental concept."
  • NoHayDeQue 2007-02-24 23:45
    gwenhwyfaer:
    me:
    VI is user friendly. Some are thrown off by the whole two-mode thing

    Someone made an observation once that stuck with me, because it makes a lot of sense. The observation was that vi isn't actually a modal editor. It's as modeless as emacs; when you type iSOMETEXTHERE<ESC>, what you're actually doing is beginning an insert command, typing the text to insert, and terminating it with the ESC key. Just like you would in ex, in fact - the only difference is that 'vi'sual mode gives you instant feedback.

    Of course, editors such as vim and elvis have complicated things to the point where you do now have two modes... but originally (and certainly on SunOS 12 years ago) vi wasn't like that.

    As for being user-friendly - very... but only to users of vi (or to those who've never seen a text editor before). It's pretty damn hostile to users of emacs or Wordstar, even though the interaction model is to all intents and purposes the same. The only difference is that printable characters are mapped not to a range of different commands, but to just one - "insert this character into the buffer".


    After 20+ years of coding offshoots of MUMPS, I took to vi/ex like a pig to mud. As a ham fisted typist, I like the way many commands sequence left, right, left. I particularly like how simply I can pipe and replace an arbitrary chunk of text through a filter (ie
    <esc>1G!Ggrep root
    will extract root processes from ps). It serves me very well as a motarboard for buttering bricks of code.

    Metaphor aside, I have no delusions that any code wrought by me will last or serve as well as the most out of plumb brick shithouse. Wrspt these cases of MUMPS, the best development langauge and tools will not make working for assholes a satisfying liveliehood I met some fine people coding MUMPS: I hope it did some good as long as it could.
  • anon 2007-03-01 23:09
    this bryan guy is full of shit. what's his real name?
  • AC 2007-03-05 18:09
    Last post!
  • M Expert 2007-03-13 22:04
    This is just a bad rap for Mumps (M). The language was once famous in the 70s and 80s. It is still used by many big companies such as VA Hospital, Ameritrade, etc... Almost every healthcare system in the US still uses some systems written in Mumps.

    Career in M also is not a bad choice. There are plenty of jobs in the market especially in contracting. It seems to me that you made a horrible case out of something normal in the business. Mumps is no longer popular as before but it's not a scrapy language. It's a structured programming language just like COBOL and FORTRAN. Many old programmers love to work with M. Younger programmers usually don't have patience to deal with old programming languages.

    InterSystems has done a great job in promoting M in its Cache database. The company is robust. It have been selling M products over 100 countries in the world.

    I totally disagree with your analysis because I am a M expert and I am still making more money than many VB programmers.
  • M Expert 2007-03-13 22:05
    This is just a bad rap for Mumps (M). The language was once famous in the 70s and 80s. It is still used by many big companies such as VA Hospital, Ameritrade, etc... Almost every healthcare system in the US still uses some applications written in Mumps.

    Career in M also is not a bad choice. There are plenty of jobs in the market especially in contracting. It seems to me that you made a horrible case out of something normal in the business. Mumps is no longer popular as before but it's not a scrapy language. It's a structured programming language just like COBOL and FORTRAN. Many old programmers love to work with M. Younger programmers usually don't have patience to deal with old programming languages.

    InterSystems has done a great job in promoting M in its Cache database. The company is robust. It have been selling M products over 100 countries in the world.

    I totally disagree with your analysis because I am a M expert and I am still making more money than many VB programmers.
  • Ex-meditecher 2007-03-23 13:49
    Lianne:

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


    WTF are you talking about? Meditech pays their DEVELOPERS low thirties in BOSTON, one of the most expensive cities in the country. When I complained that I was having to bring my kids snacks for lunch, I was told, and I quote "Well, you could always get a second job."
    Meditech is a sweat-shop stuck in the early 80s. It scares the hell out of me that they are in 25% of the hospitals.
  • Ex-meditecher 2007-03-23 13:57
    Jan:
    The silliest thing about this account is the fact that the developer left the job off his resume, leaving a blank. Any prospective employer is going to look at a 2-year gap and assume the candidate spent the years smoking dope and playing WOW, or in prison. Even a job in MacDonalds is better than a gap.

    Or they might just assume the person was looking for a development job in the software industry in the mid-2000s. It took me two years to get a job out of college, and that was at Meditech, because they'll hire anyone that can sumbit a resume without drooling all over the place. I had lots of interviews, but in case you didn't notice because you were secure in your comfy job, it was tough work finding a job in the last few years.
  • Current_Meditech_ER 2007-03-26 22:49
    Let me guess Ex-Meditecher ... did you go into consulting?

    Those who can't do attempt to prentend they know how to tell others 'how to', eh?

    OR are you simply bitter because the stock never went public?
  • Current_Meditech_ER 2007-03-26 22:53
    If you are scared by MEDITECH ... you should check out HBOC / McKesson.

    Well, at least they are publicly traded.
    (HA!)
  • AtomicClock 2007-03-31 12:38
    earl:
    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.

    Haha.


    What's really hilarious is that you are either stupid enough to believe that anecdote that you probably heard from some other charlatan, or that you're disingenuous enough to spout demonstrably false statements like this knowing that morons will lap it up.

    Assuming you actually worked there they probably fired you, which I suppose is the most pathetic thing in this whole WTF.
  • Ex-meditecher 2007-04-03 12:00
    No,current_meditech_ER, actually I got a job at a real company that develops real software using a real language and operating system with real, functional tools. And I even make enough to feed my family. Enjoy your free sodas though. I'm just here to gloat.

    FYI: A sign at McDonnalds in the Boston area announced they were hiring managers for 35k/yr. That is what Meditech starts the programmers out at. McD's is probably more selective about who they hire too.
  • Nahum 2007-04-14 06:44
    Thank you for the info. It just helped me to decide about the new job offer i got this week. I will say no to MUMPS...
    You are all welcome to visim my blog at:
    http://www.eastern-logic.com
  • Alexx 2007-04-30 06:50
    What was the first record of mumps? I'm researching it for school.
  • Tommy 2007-05-07 03:00
    MUMPS/M/Cache is not a dead language/database. It was developed for and is still in widespread usage in the healthcare industry. Many IT vendors including Misys, IDX, and Epic sell widely used applications based on it. The VA's system runs on it. Thanks to Kaiser's installation of Epic (the Madison/Verona company everyone's talking about), InterSystems (which owns Cache and predecessors Open M, ISM, DSM, and MSM) can say the largest healthcare databases use it.

    It takes getting used to but that's just like every other language or database. Once you learn it, it's fun to use and rather efficient in terms of keystrokes required.

    As for security, it's all in the implementation. I'm not sure what type of M is being talked about in the "horror story" but Cache provides API's for all modern programming languages.

    As for migrating away from it...there's no need to. InterSystems continues to develope and update Cache. It runs on OpenVMS (Alpha and Integrity), AIX, HP-UX, Solaris, and Windows.

  • David 2007-05-14 10:55
    Ahhh... Mumps. Happy days, I was never more productive.

    I am not sure what Bryan did for the three months it took him to learn mumps, there were only about 8 commands that I can remember. I was up and writing new functionality in about 2 weeks.

    According to the manufacturers of Cache it is still significantly faster than Oracle...

    http://www.intersystems.com/cache/whitepapers/warehouse.html

    It wouldn't surprise me, after I watched a large team try to replace a legacy mumps system with new fangled windows and SQL replacements for a number of years.

    Mumps is still used in the UK for a significant amount of healthcare records.

    Having said all that... I am glad that I will never have to use it again.
  • Me 2007-06-05 10:54
    I have to throw up now.

    CAPTCHA: ewww
  • Chris 2007-06-06 03:18
    Tommy:

    As for migrating away from it...there's no need to. InterSystems continues to develope and update Cache. It runs on OpenVMS (Alpha and Integrity), AIX, HP-UX, Solaris, and Windows.

    ... and Mac OS X
  • David 2007-06-06 21:14
    ilovemumps:
    I don't think that much of this criticism is fair. I work for a similar company as Bryan (perhaps the same). I had a hard time getting a job out of college, even though I went to a good school and got good grades with degrees in math and physics. I am glad that this company hired me and has given me some programming experience, work experience, and a salary. There is no way that is a bad thing.
    Exact same boat. I too got a degree in Math and Physics from the best university in the country. Sure I'm now using Visual FoxPro, but only plan to do this for a couple of years or so. And they are paying me heaps, more than I even asked for! Plus this is a great environment, in a very well recognised company.
  • Former Mumps Dude 2007-06-07 04:10

    Nope. "K ^" was a lethal combination as were such other "K ^*" situations. "K ^DD" was the killer that happened one day in our shop. Killed our entire data dictionary.

    Yes, AmeriTrade used Mumps up until fairly recently and they may still. Also, APAC bought a company and inherited a Micronetics Mumps implementation.

    I think there is some salvage yard software that is popular and written in Mumps too.

    I liked Mumps but I like the "newer" languages and technologies better. If Mumps had some SQL capabilities, it may be fun to play around with. I hear Cache may support that?

    You could get quite a bit done in a screen or two of code.



  • Saintly 2007-06-11 16:55
    Ed:
    Ed:
    NotARobot:
    Did anyone see this further WTF in the Wiki article?

    Reserved words: None. Since MUMPS interprets source code by context, there is no need for reserved words. You may use the names of language commands as variables. There has been no obfuscated MUMPS contest as in C, despite the potential of examples such as the following, perfectly legal, MUMPS code:

    GREPTHIS()
    NEW SET,NEW,THEN,IF,KILL,QUIT SET IF="KILL",SET="11",KILL="l1",QUIT="RETURN",THEN="KILL"
    IF IF=THEN DO THEN
    QUIT:$QUIT QUIT QUIT ; (quit)
    THEN IF IF,SET&KILL SET SET=SET+KILL QUIT


    That code does not work. There is no THEN command in M. Also, the : is a conditional, so it says "do this command if this condition is true", so you don't need Q:$Q Q Q, it would just be Q:$Q Q.

    I'm not sure what $Q would return without giving it a parameter, it is a function after all.

    There are too many problems with that code here to list them all. It won't run. You will get syntax errors.


    I take that back, it does work, but the spaces at the beginning of the lines are important. THEN is a tag, so DO THEN goes to that tag and does not execute "KILL". I'm still not sure about that QUIT:$QUIT QUIT QUIT. Since this is declared as a function, the last quit needs to return a value, so something like this is probably what the author was looking for.

    QUIT:$QUIT QUIT QUIT ""



    Or not...

    QUIT:$QUIT QUIT QUIT ; quit

    If the caller/calling function is expecting this function to return a value, return the value of the local variable 'QUIT'. Otherwise, exit the routine without returning a value. The last '; quit' is a comment.

    In MUMPS/M, you call a routine differently depending on whether you want a return value or not. If a function returns a value in a context where a value was not expected, that's a fatal error. So is not returning a value to a context where a value is expected.

    I guess you'd hope people would only call your function according to the published API. But the $QUIT function tells you what context your function was called in so you can behave differently. It evaluates 'TRUE' if your context is expecting a value.

    MUMPS functions & routines are never required to return a value.
  • Ray Lopez 2007-07-16 05:37
    Read this carefully. Be afraid, be very afraid... LOL.

    January 04, 2006 11:06 AM US Eastern Timezone

    GE Healthcare Completes Acquisition of IDX Systems Corporation; GE will Accelerate Global Adoption of Electronic Health Records

    BARRINGTON, Ill.--(BUSINESS WIRE)--Jan. 4, 2006--

    GE Healthcare, a unit of General Electric Company (NYSE:GE), announced today the completion of the acquisition of IDX Systems Corporation (NASDAQ:IDXC), a leading healthcare information technology (IT) provider. Together, GE Healthcare, a global leader in medical imaging, healthcare services, life sciences and information technology, and IDX will create a leading healthcare IT vendor with one of the most comprehensive suites of clinical, imaging and business information systems available.

    GE expects the acquisition to accelerate efforts to seamlessly connect clinicians from physicians' offices to hospitals with comprehensive, enterprise-wide electronic health record (EHR) solutions, creating a digital community that supports safe, efficient and cost-effective patient care.

    In 2005, the RAND Corporation, a non-profit research organization, released information indicating that America's healthcare system could save more than $81 billion annually and improve the quality of care if it were to broadly adopt computerized medical records.

    "The combination of these two companies positions GE as a leading provider of global healthcare information solutions and, by further enabling the integration of our customers' IT systems, enhances our ability to help them streamline healthcare costs, reduce medical errors and enhance and improve the quality of patient care," said Joe Hogan, president and CEO of GE Healthcare. "In addition, our expanded IT product offerings will provide healthcare practitioners with powerful new capabilities and tools, like comprehensive EHRs, to help physicians diagnose and treat disease earlier than ever before."
  • Turnip 2007-08-06 10:47
    Okay, I confess. I am a MUMPS (don't call it M, I hate that name)programmer, and have been for 22 years. I hate to be a me-too-er, but the rabid anti-MUMPSian drivel tha thas been spewing out here is more from ignorance and religious zealotry than anything else.

    Can you write bad code in MUMPS? Of course you can, and much has been written. Can you write good code in MUMPS? Of course you can, and much has been written. I haven't used a GOTO in probably any of the past 20 years (except maybe code that I wrote for my own personal stuff, like games, and the like). Scoping of variables (and by the way, that existed even in the earliest incarnations of MUMPS), block structuring, comments, non-obscure variable naming, etc. should certainly be used. Things like dynamic variable creation, non-existent variable-typing, sparse arrays, and so forth, are strengths, not weaknesses. Security? No problem. When I worked at the DOD (whose hospitals still use MUMPS, as well) there was no bare telnetting as some other poster here suggested was the case with his MUMPS shop. It was secure shell, and even the developer's accounts (which were protected by two levels of passwording) were automatically disabled at the hospitals each day, and you had to re-establish authenicity to have your account reenabled, which involved using DoD-issued CAC cards, which needed an electronic reader, thumbprint and yet another password. So security is what you make of it.

    As others have mentioned, not ony the VA and the DoD use it, but also Ameritrade. And why? Because even in this day and age, it's FAST, and completely scalable. Millions of transactions are handled, accurately and securely, every minute.

    People who think newness is better simply because it's new are the ones who need to get a clue. Yes, some newness is better (examples would be the Internet and cellphones), but other things are simply tools to drive the market economy which collapses if people stop buying new stuff (remember back in the old days when you didn't have to get a new car every five years, because the vehicles actually LASTED for 10-20 years with no problem? That was disaster for Detroit, since not everyone was buying into the "must scrap my old car each year or two, because this one has newer bells and whistles" mentality. So they started making cars that would fall apart basically as soon as their warranty expired.)
  • axarydax 2007-08-10 02:04
    Jeff S:
    I like the spec indicates (if I am reading it correctly) that block of code in FOR loops and IF statements must all be on one single line. And we argue over where to put the curly braces!!! Maybe you can use GOTO's to avoid this?


    According to Wikipedia you can use DO command to create new code block for FOR / IF..

    btw - this iz crazy:

    DOW D H S Y=%Y K %H,%Y Q
    DW D H S Y=%Y,X=$P("SUN^MON^TUES^WEDNES^THURS^FRI^SATUR","^",Y+1)_"DAY"
    S:Y<0 X="" Q
    7 S %=%H>21608+%H-.1,%Y=%\365.25+141,%=%#365.25\1
    S %D=%+306#(%Y#4=0+365)#153#61#31+1,%M=%-%D\29+1
    S X=%Y_"00"+%M_"00"+%D Q
    ;
  • jimjim 2007-08-10 07:43

    "While rock guitarists and programmers share a personality style characterized by arrogance, self-absorbtion. delusions of grandeur, and a tendency toward dogmatic absolutism, it is nevertheless the case that guitar players get more women." - C. Thomas


    but I presume there's more woman dating programmers than woman dating guitarists,

    without talking of the average pay check...
  • Armin van Harten 2007-08-21 04:47
    Hi,
    thanks to turnip for his words. I agree fully. Don't beat the sack if you mean the mule. And if there is something bad about M than it is the same, other languages have encountered over 20 or more years. Many problems come from the fact that MUMPS is OLD.... 1966... had its best times in the 80's and then happend what often happend to systems with a long history : the development of the system stopped, not because the implementors where not interested but the programmers did not want to change. Evolution of the language stopped in 1995 on a level compatible to 1988 (in some companies earlier, sorry about you McKesson folks)) ! That means even structured programming has been a 'wow' innovation for the established M programmer. Therefore M is one of the last languages where GOTO is still a style element (I style cann't stand it!) Since it is never a problem to get a M prog. running even the worst garbage is implemented somewhere in some old software. This is not because the language forces you so, it is because programmers choose it to do so!! There are lots of elements I would like to find in the language but the problems described above are not among them. A fool can write garbage programs in any language. I've seen it in C, C++, Java, Delphi, PHP, JScript etc. If you are stupid, the language won't help you anywhere! Unfortunatly M programs are usually abpout 20-25 years in service and accumulated a lot of stupidity (While a java prog only can acumulate just a few years of crap). Like the example:

    DOW D H S Y=%Y K %H,%Y Q
    DW D H S Y=%Y,X=$P("SUN^MON^TUES^WEDNES^THURS^FRI^SATUR","^",Y+1)_"DAY"
    S:Y<0 X="" Q
    7 S %=%H>21608+%H-.1,%Y=%\365.25+141,%=%#365.25\1
    S %D=%+306#(%Y#4=0+365)#153#61#31+1,%M=%-%D\29+1
    S X=%Y_"00"+%M_"00"+%D Q

    This is definetly 1977 style. Remember: you can even write a C program in one line, but nobody does, so why not write:

    DOW() ; -- function : unknown crap --
    N %Y,%H,Y
    D H
    S Y=%Y
    Q Y ; return Y for whatever reason

    DW() ; -- function : return current day of week --
    N Y,%Y,X
    D H ; calling a local label but it is not here .....
    S Y=%Y,X=$P("SUN^MON^TUES^WEDNES^THURS^FRI^SATUR","^",Y+1)_"DAY"
    S:Y<0 X=""
    Q X

    7 ; -- this label is never called --
    S %=%H>21608+%H-.1,%Y=%\365.25+141,%=%#365.25\1
    S %D=%+306#(%Y#4=0+365)#153#61#31+1,%M=%-%D\29+1
    S X=%Y_"00"+%M_"00"+%D
    Q

    Or better like this:

    DAY() ; -- function: return name of current day --
    N DAYS
    S DAYS="Thurs Fri Satur Sun Mon Tues Wednes"
    Q $P(DAYS," ",+$H#7+1)_"day"
    ;

    The basic problem seems to be MUMPS is different. When I started MUMPS my first impression was I encountered a post mortem dump. I applied simple rules of structured programming and it worked much better and so on. BUT I never understood, why all programmers start writing shit when beginning to write M programms??

    But I must agree to the original author: If you tell your employer, you're a Mumps professional, he most likely thinks, you are one of those stubborn diehard prehistoric species which still refuses any evolution of the last 25 years in IT development. But how can he know, that sometimes there are a few who are not??

    Since I am not usually here, you can flame me on my business mail at:
    info(at)ifmd-consulting//nospam//.de

    have fun watching them "modern" languages ageing ;-) !!
    Armin van Harten
  • grrrr 2007-08-29 04:09
    Ignorant ???. A lot of smart people thought about making programing languages,databases and methodologies better and if you ever really programmed in mumps cache object-script and are also aware of all that theory than your only conclusion can be that the theory is right and mumps is wrong. The real problem why there is still mumps/cache it is dishonesty and customers ignorance. You probably make more money if your customer has more problems.
  • grrrr 2007-08-29 04:41
    I like to remark that the most important thing thing about databases that gets almost never mentioned in this kind of discussions is database integrity. Is that customer id really a customer id is that id used only one time is that essential piece of data really there? what does a mumps database offer in that regard ? Nothing! That is the real important difference with relational databases.
  • Gringo 2007-08-29 10:37
    Sorry for picking your post out, but this is an example of how most of the people commenting here seem think these days.

    What this user expects are features from an SQL-RBDMS like primary keys, constraints, stored procedures and relations - and he expects this from a system which was designed way before anyone thought about something like SQL. He looks at it and sees that the features he is used to are not there at the first glance and thus the whole product must be bad. Preferably without researching what really is there:

    grrrr:
    I like to remark that the most important thing thing about databases that gets almost never mentioned in this kind of discussions is database integrity. Is that customer id really a customer id is that id used only one time is that essential piece of data really there? what does a mumps database offer in that regard ? Nothing! That is the real important difference with relational databases.


    M was created as an operating system aimed at rapid creation of stable, available, scaleable, concurrent, multi-user data storage, manipulation and retrieval systems - getting the most out of the available hardware as possible.

    The above comment is like complaining about C++ missing RDBMS storage, or word processing capabilities.
    Comparing it with a modern RDBMS also misses the point, alone because RBDMS only have a subset of the functionality of M.
    Additionally missing the point because the 'missing functionality' the user complains about is available for this language as a library (see below).

    M is basically exposing the low-level functionality (and more) needed for storage engines (eg the ones used by modern RDBMS) and virtual machines (such as java) to the programmer (and that since about 40 years) - giving flexibility to handle data and code in a performant and portable way:

    * You can build full SQL compatibility on top of M and have it run faster and more stable and scaleable then many other dedicated RDBMS on the market.

    * You can build an OODBMS with it, or a complete OO system (including typed variables if you really feel the need for and willingness to pay the performance impact of it).

    * You can use the included btree storage system as-is (and a carefully tailored storage structure in M can outperform RDBMS for quite some scenarios - because it omits many of the problems for wich stuff like referential integrity checking in current RDBMS burns way to many CPU cycles these days).

    * You can even dump the complete language by writing your own compiler and use M as a VM for the language you create.

    Or you can build something with it which gives you all of this at once.
    That has been done by intersystems - it's called Caché (drawback there is the pricetag, but compared with stuff like oracle it isn't bad):
    All the functionality they offer is basically library code running on a classic M system (except stuff for eg. IP connectivity which are implemented as Zfunction language extensions). And it's stable and very fast and scaleable.

    Should you openly look at what functionality they expose to the user (and keep in mind that all this is running on a 40 year old language construct) then maybe you will get a grasp of how powerfull MUMPS really can be given good coders who know what they are doing.

    Sure, you can create unreadable, unmaintainable or fucked up code with any language.
    And you're shafted with nearly any language available should you not have libraries (which contain solutions to the problems you encounter and make your life easier).
    Also you could dislike the syntax (which i liked when working with it because i had to type less to express the things i wanted).

    But please stop bashing something after a glimps at a very limited subset of it - when you don't have a clue about what's really there.
  • grrrr 2007-08-30 10:58
    Gringo:
    Sorry for picking your post out, but this is an example of how most of the people commenting here seem think these days.

    What this user expects are features from an SQL-RBDMS like primary keys, constraints, stored procedures and relations - and he expects this from a system which was designed way before anyone thought about something like SQL. He looks at it and sees that the features he is used to are not there at the first glance and thus the whole product must be bad. Preferably without researching what really is there:

    No You are wrong. I have firsthand experience with a legacy mumps application and I know some mumps.
    Gringo:

    grrrr:
    I like to remark that the most important thing thing about databases that gets almost never mentioned in this kind of discussions is database integrity. Is that customer id really a customer id is that id used only one time is that essential piece of data really there? what does a mumps database offer in that regard ? Nothing! That is the real important difference with relational databases.


    M was created as an operating system aimed at rapid creation of stable, available, scaleable, concurrent, multi-user data storage, manipulation and retrieval systems - getting the most out of the available hardware as possible.

    The above comment is like complaining about C++ missing RDBMS storage, or word processing capabilities.

    No your analogy is useless a better analogy is that it is like a car that is missing brakes.
    Gringo:


    Comparing it with a modern RDBMS also misses the point, alone because RBDMS only have a subset of the functionality of M.
    Additionally missing the point because the 'missing functionality' the user complains about is available for this language as a library (see below).

    M is basically exposing the low-level functionality (and more) needed for storage engines (eg the ones used by modern RDBMS) and virtual machines (such as java) to the programmer (and that since about 40 years) - giving flexibility to handle data and code in a performant and portable way:

    No almost all mump programs that I have seen are a lot slower then the equivalent sql query
    Gringo:


    * You can build full SQL compatibility on top of M and have it run faster and more stable and scaleable then many other dedicated RDBMS on the market.

    * You can build an OODBMS with it, or a complete OO system (including typed variables if you really feel the need for and willingness to pay the performance impact of it).

    * You can use the included btree storage system as-is (and a carefully tailored storage structure in M can outperform RDBMS for quite some scenarios - because it omits many of the problems for wich stuff like referential integrity checking in current RDBMS burns way to many CPU cycles these days).

    * You can even dump the complete language by writing your own compiler and use M as a VM for the language you create.

    Or you can build something with it which gives you all of this at once.
    That has been done by intersystems - it's called Caché (drawback there is the pricetag, but compared with stuff like oracle it isn't bad):
    All the functionality they offer is basically library code running on a classic M system (except stuff for eg. IP connectivity which are implemented as Zfunction language extensions). And it's stable and very fast and scaleable.

    I see that yuo have been reading the cache marketing fairy-tales. If yuo had real experience with that database yuo know that that are only fairy-tales.
    Gringo:


    Should you openly look at what functionality they expose to the user (and keep in mind that all this is running on a 40 year old language construct) then maybe you will get a grasp of how powerfull MUMPS really can be given good coders who know what they are doing.

    A coder who knows what they are doing would never code in mumps
    Gringo:


    Sure, you can create unreadable, unmaintainable or fucked up code with any language.
    And you're shafted with nearly any language available should you not have libraries (which contain solutions to the problems you encounter and make your life easier).
    Also you could dislike the syntax (which i liked when working with it because i had to type less to express the things i wanted).

    old fashion Mumps does not have the language features to write readable and maintainable code.
    Gringo:


    But please stop bashing something after a glimps at a very limited subset of it - when you don't have a clue about what's really there.

    My well informed conclusion is that mumps need a good bashing . It is a piece of crap.
  • Armin van Harten 2007-08-31 03:47
    Hi grrr,

    this is a harsch standing you take on one single programming language in a thousand. On what you say, I am very sure, you may know a few statements in M but you know nothing about M. Probably you started out in a very old fashioned M-shop with all your new neat libraries in C++ or java or whatever and finally recognized all that stolen, borrowd and sampled stuff other programmers wrote for you doesn't work here. All the common language stuff is suboptimal here, because algorithmic is very different in M. I am sure, that its people like you who are responsible for some of the worst lines in any M code and now complaining about the language, because they are unable of structured working.

    Nobody denies that because of some historic misdevelopments, this language has some shortcomings, but getting so upset upon this may have different reasons. I've met a lot of younger programmers who where very proud of knowing a lot of libs they can use. They where usually not able to implement a read command with some cursor control but believe themselfs great programmers. Well! OK. But see this: you are in a different department. M is not for YOU, M is for professionals. As far as I see, you ar not even able to decide a programming laguage from a databse from a operating system etc. I thi nk, it could be a good idea to acquire some basic knowlegde and then take a look again. Another point isd, that M is still the only language which allows complete algorithms in treestructured data and associative adressing (PHP has some small approaches but is mixed up). These two elements allow completely different solutions of given problems. Beyond all historic troubles, you will find new ways of thinking working seriously with a tool like this. In M DOM Models are old! But you will never recognize because you are still seraching for some flat tables and SQL add on's. N dimensionality is a was of thinking and ultimate freedom can cause trouble for those who need barriers to find their way.
    Reboot your brain, and answer yourself one quetsion: if this is so bad, how could it last so long?

    BTW : funny name 'grrr' What are you affraid of?

    Armin
    P.S. If you need any help with your M problems, let me know, I can support you-.
  • grrrr 2007-08-31 04:55
    I was not angry before but I am now . Your condescending tone and assumptions about me are totally baseless. Do not lecture about professionalism with your pseudo-technical-mumps-speak. Let me teach you something about dimensions instead. Lets take a simple cube of size 3x3 and put the corner points in a sql database and in a mumps database now come up with a couple of simple queries like what points make up a side what points make up a diagonal plane and then come back to and tell me what is the multidimensional database and what is the flat one. In a sql database all dimensions/rows are equal and can all be used to query. in a global one
  • grrrr 2007-08-31 09:11
    Also speaking of ^globals and mumps how about the TDIDT algorithm on a global show me maybe you impress me. You may chose how to do the attribute selection but not the selection the ^global tree dictates.
  • Gringo 2007-09-03 22:42
    grrrr:
    No You are wrong. I have firsthand experience with a legacy mumps application and I know some mumps.

    Read: You have experienced one application and know how to code 'Hello World'.
    grrrr:
    No almost all mump programs that I have seen are a lot slower then the equivalent sql query

    Seems like most of the M programmers whos code you have digested didn't have a clue how to write performant code.
    Or did you compare the legacy application running on legacy hardware to your SQL system running on current state of the art hardware?

    grrrr:
    I see that yuo have been reading the cache marketing fairy-tales. If yuo had real experience with that database yuo know that that are only fairy-tales.

    I actually used it.

    grrrr:
    old fashion Mumps does not have the language features to write readable and maintainable code.

    Old fashion SQL (which you seem to see as the best since bread in slices) is crap too - compared with todays SQL.

    grrrr:
    I was not angry before but I am now. Your condescending tone and assumptions about me are totally baseless. Do not lecture about professionalism with your pseudo-technical-mumps-speak.

    Why getting personal?

    grrrr:
    Lets take a simple cube of size 3x3 and put the corner points in a sql database and in a mumps database now come up with a couple of simple queries like what points make up a side what points make up a diagonal plane and then come back to and tell me what is the multidimensional database and what is the flat one. In a sql database all dimensions/rows are equal and can all be used to query.

    Your example clearly shows that you don't understand the possible ways to use the storage structure supplied by M.

    grrrr:
    My well informed conclusion is that mumps need a good bashing. It is a piece of crap.

    (plus)
    grrrr:
    A coder who knows what they are doing would never code in mumps

    Well informed.
    Yea, right.

    <*)))><

    Languages evolve. People sometimes not.

    Gringo
  • Ed 2007-09-25 14:11
    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.


    My brother went to Anderson Consulting out of college in 1994. All new hires back then went to Cobol class for months. Ironic how everyone (at least PHBs) practically revere Big4 consultants considering their roots!
  • grrrr 2007-09-27 16:09
    "
    Why getting personal?
    "

    You painting a picture of me that was a total your fantasy that is a shit thing to do. You can spin it now by just quoting what makes you look good but that is just a cheap trick of a typical technically incompetent person trying to get is his way by bullying instead of argument . I am a mathematician by training and I assure you I can see the how useless nonsense a data-model like that of mumps globals is without the years of mumps torture that made you so stupid.
  • jim 2007-09-27 16:39
    I'm a consultant (contract programmer) and MUMPS/Cache is everywhere.

    Here are some MUMPS/cache shops I've done work for:

    Quest Diagnostics
    GE Healthcare (IDX)
    Ingalls Health System
    TD Ameritrade
    Advocate Health Care
    Allina
    Unicare
    Providence Health
    St. John's Mercy Health Care
    SSM Health Care
    Northern Trust
    Thibodaux Hospital
    Unisys
    Department of Veterans Affairs
    The M-Plan
    Southern Illinois Healthcare
    Gottlieb Memorial Hospital
    McKesson (HBOC)
    Northwesterm Medical Faculty Foundation
    Humana (Michael Reese Health Plan)

    http://www.nwcltd.com
  • Jose Canseco 2007-10-01 01:17
    Why is Brian blaming his lack of ability to get a job on his previous company. Did getting experience outside of college worsen your resume? Nope. So if you hadn't gotten this first job, you'd have been unemployed just the same, so there's some other reason you can't get a job and it has nothing to do with MUMPS. Good luck, though.
  • Gringo 2007-10-24 18:15
    I may already handed out the fish, but i couldn't resist:

    grrrr:
    "
    Why getting personal?
    "

    You painting a picture of me that was a total your fantasy that is a shit thing to do. You can spin it now by just quoting what makes you look good but that is just a cheap trick of a typical technically incompetent person trying to get is his way by bullying instead of argument . I am a mathematician by training and I assure you I can see the how useless nonsense a data-model like that of mumps globals is without the years of mumps torture that made you so stupid.


    Maybe stick to math then and leave IT to people who are trained in that field?

    Gringo
  • Doug 2007-11-24 05:54
    As a DSM version programmer back in the 80's and 90's for about 5 years on a cluster of PDP 11/83. Then working on other flavours, I can sympathise with Bryan. However you cannot knock a programming language/OS that has the ability to be so flexible with such limited resources.

    Xrefing multi clusters with ^[uci,sys] and with proper control over your subroutine modules there's nothing (datawaise) it couldn't handle and I am sorry but all my programming was wel documented clear and maintainable!

    The only inherrant problem was the fact in the UK was steering group that didn't take tight enough control over the emerging plethora of backroom spun GUI's comming onto the markets.

    I still say if it was revisited revamped it could still be a goer.
  • macruadhri 2007-11-30 13:47
    Ooh. Mistaken.

    Cerner and HBOC both have MUMPS ( or M, as it's called these days ) based applications. Meditech is even worse since MAGIC is based on their previous proprietary language MIIS...which looks a LOT like M.

    MUMPS was actually the first ANSI standard language back in the early 60's. That's before most of the early work on programming styles was done! If you see any legacy code out there for ANY language that old you're going to see amazing things like GOTOs resulting in spaghetti code. The problem isn't M...or Intersystem's current version called Cache...it's the moronic use by the individual programmer. I've seen VB and C++ code that was far less supportable than M.

    In actual fact, Cache is a true object oriented programming language whose capabilities include SQL querries and a scripting language that is almost identical to C++ with the exception of the object library. Cache even comes with a feature called Cache Server Pages. Yep, web based support to compete with Active Server Pages at no additional cost.

    I don't know about any other programmer out there but I believe opportunities are what you make of them.
  • Billy Bathgates 2007-12-19 14:57

    You developers extolling java over MUMPS - Look at the deliverables from each platform. java is, or should be great in theory, but the kitchen sink libraries an 'infrastructure' it drags around with it result in crashing systems that must be hardware overspecified, which in this day and age is inexcusable. There are too many just average programmers writing shitty code that gets included as the infrastructure acretes. For a language as young as java, this is horrible. Someone needs to cut out the bullshit, or just start over.

    For the article writer, who was praising VB as an alterative - you need to stop drinking billy gates' white Koolaid! M$ is a cancer on IT. Time to throw away the 'IDE' that lets you produce reams of shit, and work on quality not just quantity
  • s. 2008-02-22 13:24
    Today, I saw MUMPS on freshmeat:
    http://freshmeat.net/projects/gt.m/?branch_id=3802&release_id=272308

    seems to be the same thing. I didn't believe this really exists when I read the WTF...
  • Neas 2008-02-24 14:15
    very interesting, the adage 'you can code in one language you can code in them all' might not always apply. If the skills you have are so esoteric you might be dependent on one company for employment. It might work out that you can hold the company to ransom if there's more jobs than developers but you're the company's bitch if it's the other way round.
  • Tony 2008-02-29 12:20
    Every programming language has it's advantages, disadvatages and quirks. That's the one fact that has been the most evident over my 25 plus years of programming expereience. I done COBOL, X86 Assemblr, C, Forth Basic (the Dartmouth version that precede M$), QuickBasic, TurboBasic, Pascal, Turbo Pascal, Delpi and Visual Basic.

    My introduction to MUMPS was with a "competitor called MIIS back in the early 80's. I also beta tested Intersystem's predecessor to Cache in the late 80's.


    I worked continously for the last 25 years inside and outside the MUMPS community. I've worked as a developer, programmer, techie, manager and supervisor.

    The point behind all of this crap? The programming language matters. The skills of the prorammer matters more. The standards, conventions, rules and coding philosphy are the keystone. It takes all three to develop and implement what the client really wants.
  • cod3_complete 2008-03-18 11:25
    After looking at those code samples I'm convinced that the programming language is named after the mumps disease and the acronym was made up after the fact.
  • nicki 2008-03-18 11:42
    I have about 4 years cache experience and im unable to land a job in any other language except for those "fresh from college" ones where i would be paid peanuts.
    studying java in my spare time now so that i have something to show when going for an interview
    1 year java =17k
    4 years cache (+csp server pages)=12k (after complaining to my boss)
    go figure
  • x^2 2008-03-20 01:41
    A horrible story indeed, but a lesson for any new programmer. Staying current with technology is essential if you want to continue to be marketable. There is no better leverage than to have options outside your current employer. I have seen too many engineers get swallowed up in high-paying grunt work only to realize that they've been effectively marginalized in the market.

  • Kevin Zelhart 2008-03-23 09:53
    I worked for a company that used one of the products. The vendor was in it every day trying to hold it together. THought MUMPS was fitting, as the program was more of a disease than a tool. After two days on the job as a domain admin, told them If it was a car, I would push it on the railroad tracks.
    poor Bryan
  • Kevin Zelhart 2008-03-23 11:16
    Can't comment directly on a lot of what yousay, as I am in IT support, and not programming. ANy programming I have done has been limited and vry specific in scope (I am an electrical engineer by training)

    >1) Fresh, young programmers don't want to work on yesterday's old-and-busted crap

    So true. And there are some who are programming the old broken crap that have never ventured outside of that realm to know there is something better.

    Snip>
    Heh. Kinda reminds me of the companny I did my internship for. They had this scary-ass VBA/Access program that was too much of a mess to port to VB/SQLServer. They even went as far as to implement multi-user access to the single-user Access app through Windows Terminal Services. I don't think this program ever worked properly.
    end snip<

    Gawd! I remember this happening when I was admin at a contractor for processing of medicare claims. Some one in one depart ment had the hammer of access, so they started seeing evry problem as a nail and writing a database for it( no programming experience involved). The other departments found some benefit in the resultant apps, so, instead of contacting the programming staff in charge of the SQL servers, the started using the original app in multi user mode. When it brought the network to a crawl, they came complaining to us. Luckily we had a couple of excellent managers from the old mainframe days that forced a development procedures on the departments.

    Any language can be a nightmare if applied without a plan. Unfortuneately, mot of the medical industry software I have seen (MUMPS programs are unfortuneately NOT the exception) Seem to be poorly written and require a lot more ongoing maintenance than one would reasonably expect. Much of that comes due to application of patches instead of using root cause analysis and correcting the problem once. It takes management dedicated to the latter to make it effective. However many of these companies make a large portion of their profit from the maintenance agreements, so there is no incentive to correct the issue permanently.
  • commenter 2008-04-16 19:43
    It's hilarious and depressing to see people defending this evident nightmare of a language.

    "Stop dissing the Whirring Blood-Stained Blade! The Whirring Blood-Stained Blade is blindingly fast and once you get used to the occasional disembowelment, it's possible to whittle things quickly."

    You can 'goto' from anywhere to any line in any part of the code FOR F*CK SAKE. And if you edit the code, the goto points to the wrong line!

  • Lamb Cannon 2008-04-25 18:04
    Please, for the love of god, all of you move to fucking India or Russia. Now.
  • J 2008-05-26 19:56
    I believe this is about Epic Systems. It misses many important points, though what it says is mostly true.

    There's some things I thought I'd point out...

    - M is a weird language but the integration between application and database is completely seamless. Makes programming pretty easy!
    - Contrary to the article, it's extremely fast. Oracle servers generally perform fewer than 10,000 transactions a second; Epic customers perform hundreds of thousands of global references (reading from or writing to a global array, i.e. the database) per second.
    - The telnet protocol is deprecated. It was replaced years ago by a TCP protocol which can be encrypted.
    - Security is not an extreme concern... all of this is on hospital intranets so the only people with access are the programmers and DBAs (who have UNIX access anyway) and end-users (who don't really have the knowledge or motivation to break into the UNIX server).
    - Most of what Performance does is benchmarking and proactive monitoring.

    There are other things, too. Plus MUMPS is used in EMRs other than Epic, as well as widely in the banking industry. It's just like COBOL... yes, it's ancient but it's still at the low levels of many systems used around the world.

    Did I mention it's fast as hell?
  • iogy 2008-05-29 19:36
    J:

    Did I mention it's fast as hell?


    The time you gain by fast execution is lost by having unmaintainable garbage that looks like executable line noise.

    If your software doesn't run completely smoothly, throwing a new server at it costs you $1000. Throwing a new programmer at it costs you a lot more than that.

    Stockholm syndrome at its finest.
  • Gordon Mott 2008-06-18 02:14
    This is what PICK was for, if you wanted to ignore what would eventually become giants of the IT industry.

    Released in 1978 as r/OS by MicroData Systems.
    http://en.wikipedia.org/wiki/Pick_database
  • MK 2008-06-18 09:18
    Yes, this article is definitely about EPIC software (Madison, WI). I was on the reactionary Performance Team from 7-2006 to 12-2006. Longest 5 months of my life.

    My recommendation -- avoid EPIC like the plague. Unless you like working 60+ hours a week and having a stain on your resume.
  • kent 2008-06-18 14:28
    I never worked for Epic, I worked for the Cancer Center as part of the UW in Madison. But the story goes that Epic was started around that time by people that had worked on the Cancer Center project. MUMPS was pretty bad, the originators had been assigned the task of creating a string handling library for Fortran and instead built a language with a couple of nice bits (pattern matching, B-tree arrays) wrapped in a pile of crap. They also developed an operating system to support it that clearly showed they hadn't ever studied operating systems. I wrote a charting program and presented a paper on it at the MUMPS user conference. MUMPS was the only language most of them had ever seen and they extolled its virtues for all kinds of programming, including AI. I left because my wife got a job elsewhere, but that being my first real job didn't hurt me getting the next. Most employers have never heard of MUMPS.
  • nulldevice 2008-07-08 16:40
    J:
    - Security is not an extreme concern... all of this is on hospital intranets so the only people with access are the programmers and DBAs (who have UNIX access anyway) and end-users (who don't really have the knowledge or motivation to break into the UNIX server).


    Boy, THAT assumption is just asking for trouble. Intranets aren't always secure, it just takes one unscrupulous end-user to learn what needs to be learned and...well, worlds of hurt there.

    The software in question does win a lot of awards. It's considered the best-in-class in the healthcare industry. But that's kinda like saying the fastest guy at tyhe Special Olympics.
  • levetzow_wolfgang 2008-07-21 05:31
    I like Mumps or M and a little the new cache, a object-oriented
    dialect of the old MUMPS.
    M ist the best and speedest hirarchical database
    and withe some equal syntax of PERL.
    also with the power of a interpreter but the speed of a
    un-beatable speed of MUMPS.
    cache tranlate any object...bla-bla and any relationals
    to the hirarchic or field -structur.

    It is not a accident that all the container-ligistic
    in the hamburg-port
    was made with mumps .

    If you like PERL and need a supersafety
    and net-able database with the natural feeld-structur
    of the real world
    than take MUMPS.
    Befor i liket also APL
    the statistic Database language,
    APL a-progr. Language.
    old , flexible but no save no strucure and nor string+number als fields.
    MUMPS can it all.
    It is very clear .

    But any Problemes are:
    the bad selfdokumentation
    no real grafic-struktur-visualisation.
    I AM looking for now !

    I think here in Hamburg / germany )
    that the G.E. Tool
    GRAPHVIZ ist a very good bidirectional tool.

    So

    learn more MUMPS
    but you get today only the complex CACHE
    withe the
    "cache-Basic" that is in real the old MUMPS-syntax
    and over it
    an object-oriented interface,
    Use visuallogic@hotmail.de if you hafe good ideas
    and experiece with
    the genial GRAPHVIZ.

    i like MUMPS as idea
    it is genial simple and speedy.

    Artificial Inteligents programms are made also with MUMPS
    The old but real working A.I. or Expertsystems-world.
    They know why.. and also the good MIT...
    .Make a better MUMPS with a bidirectional grafic structur-editor and you win the world...
















  • kacké the first 2008-07-30 06:20
    @levetzow_wolfgang

    Have you every tried something other than Caché or MUMPS? I don't think so...
    When Caché is soooo good, why do we invent new things(databases for example)? Move with the times dude...

    We should choose the right database as the right solution for a problem and NOT because other are using this database too.

    Btw: I know why you made so many blanks after your comment...it's a typically Caché-terminal-developer disease...
  • Chris 2008-08-18 14:29
    Welcome to the land of FUD. There is a reason why MUMPS is still around and so many others have failed. Rapid prototyping was practically invented with MUMPS. There is a reason why the Department of Defense only spent less than 3 billion dollars to implement all of their Army, Navy, and Air Force Medical facilities and spent ten times that much to replace it over the last 15 years, failing at every turn producing nothing of use except fat vendors. There are no penalties if the vendors do not deliver what they say they will on-time or ever. Completing the task means no more paychecks for the vendors.

    MUMPS and CHCS I is still running most of these medical facilities. Many banks and credit unions use MUMPS. It has been their corporate secret for many years. Where did the DoD get their base-line system based in MUMPS? They got their base system from the Veterans' Administration back in 1985-86. Why is the VA still running VistA in their hospitals in spite of similar efforts to replace VistA (which now contains 30 years of patient history, far more than any other on-line medical system except for the system run at Beth-Israel Hospital in Boston which is also MUMPS based and holds more than 30 years of patient history.

    Well, the VA's system was developed by subject matter experts at the point of care. They knew what they needed and could learn enough MUMPS to do the job and build off of what other programmers did to where the data sets are associated as a nervous system and the people who need the data can get to the data just fine and quickly, in a timely fashion. Most other systems, the folks are kept from the code and from the data to where the physician and the patient are at risk with lessor system than VistA or CHCS I.

    The Fear, Uncertainty and Distrust (FUD) you are reading here is from malice or ignorance. Want to try MUMPS?, download it from Source Forge (sf.net), or pull down a demo system from InterSytstems, or pull down a stand-alone configured VistA system from source forge by using the download form http://worldvista.org. There is a lot of documentation available on the 160 different integrated aspects (different department and task areas) of VistA that define a VistA system. It is built to be enhanced and does play well with others. Make up your own mind. But I have been working in MUMPS for over 15 years and only been out of work for less than 30 days in all that time.
  • Chris 2008-08-18 14:56
    There are lots of things that are capable but no thinking programmer in MUMPS would ever write code like what you are describing. Let me tell you from experience that the support of MUMPS code is so trivial as to be child's play. The system stores the line of code you were executing and the symbol table as it is at the time of the error and maintains the execution stack. It is possible for one to write self-healing code, but usually the error trap is sufficient with the stack list to figur out were the problem came from.

    When I first got into MUMPS, I had come from a FORTRAN and Basic programming history. I was amazed at the ability to have a programmer pop into a remote hospital and fix a problem in seconds and that problem never happened again.

    Oh, by the way, the guy describing the sparse arrays didn't quite have it right. You can subscript by character strings and numerics (floating point, integers, negatives, and fractions) and the system sorts them for you automatically. The time the traditional programming languages could learn a lot from MUMPS.

    The critics of MUMPS must be very frightened of their turf to spill this much venom. I am willing to bet that MUMPS code is far more portable than most other languages. We only have a single data type. The programmer doesn't have to worry about the casting of the symbols he is comparing. Context drives the way the string is evaluated. The same code that runs on a PC will run on a main frame with only OS interface adaptations if the application calls for it. When working on CHCS I, the DoD wanted to connect a lot of third-party application to CHCS I. Building the interfaces took far less time with MUMPS than it took for these system to build APIs for each other. CHCS I became the Rosetta Stone of all of these disparate systems. Read some of the other folks responses for more FUD. This is fun.
  • Chris 2008-08-18 15:23
    This code is part of %DT suite of VistA Kernel Routines and was written for speed. What you are not seeing is the rest of the routine. This snipete of the code displayed is actually 3 subroutines of the whole suite of date conversion subroutines, (DOW, Day of Week, DW, Day of the Week for output, 7 to generate the File Manager Date). If you took a similar hunk of code out of almost anywhere else in a traditional application, it could be even uglier.

    I dare say, if this code were to break, you would have the line of code that failed and the symbol table to identify the problem.
  • Caoimhghin O'Cathain 2008-08-29 23:26
    http:www.cs.uni.edu/~okane

    anything can be done wrong.

    most Bash script are a dread.

    see some scripts that actually work
    at ref above.

  • M-Lover 2008-09-24 17:12
    FYI, that is a horrible example of M Code. M does have its quirks but it can be made very readable.

    I could take a C++/Java program and kill it like the code above, but that doesn't mean C++/Java are hard to read.
  • M developer 2008-10-01 12:09
    Chris:
    I am willing to bet that MUMPS code is far more portable than most other languages.
    Given that MUMPS and its sequel MAGIC require specialized architecture to run, you don't sound like you know what "portable" means.
  • Ken D 2008-10-07 14:03
    Mumps is good where its good and bad where its bad. I have spent over 25 years with M(umps) in healthcare, retail and banking. I have seen very good easy maintainable code, and uncomprehensible code. Its what you make of it. It is still fast, and yes when it was developed hardware costs were massive. £500 for a 10 Mb disk... So space and sparce arrays were the thing. I would still take M(umps) over Orible (Sic) any day.
  • $M 2008-10-27 08:21
    Love it, or hate it, M (MUMPS) will be here a good long time and as the number of developers dwindles the consulting fees go up. I can thank M for the big boys toy collection, as well as the free time to play with all the really "modern" languages. Keep up the bashing, I'm smiling all the way to the bank...
  • m blau 2008-11-03 15:52
    At my first mumps job my boss said he researched all the languages out there and this was the best. When mumps go head to head with Oracle it is way faster. Whwn MGH created this language there were no database languages that could measure up to it. It is true that the ease of use can be abused. That is up te prgrammming department. It is the only language I know of that has been upgraded and imprioved on a regular basis by user feedback for over 30 years. In conclusion Bruce's shop was probably one of those that weren't doing the job correctly so it's probably a good idea to get away, but I would suggest he consudr a different shop that uses mumps, BTW my shop does not reccomed visual basic for lkarge databases, it's too slow.
  • Joe 2008-11-03 15:57
    Honestly it sounds like the reason Brian had such a crap experience was that he was working for a crap company. In reality Mumps is an enjoyable laungage to program in. It might not be in high demand like some languages but there are lots of good oppertunities out there to code in Mumps and make lots of money.
  • btv 2008-11-13 12:36
    After working with 'M' legacy code for several years now, I can say that some criticisms of the language are warented. Intersystems has tried to bridge all the gaps by moving to their "Cache Object Script". Though, legacy code is legacy code. It's hard for companies to want to change.

    As far as the 'M' or Cache environment is concerned, it's much easier to program a good solid transaction based application using it. Using another language with SQL is terribly prone to problems. SQL is kind of slow as well. It's hard to implement problems procedurally in SQL that are better solved procedurally.

    I worked in C/C++/Perl for IBM for years before this job. It's all about the employer. I much prefer my job now. What an unbelievable fit of idiocy IBM Microelectronics was. I preferred Perl and C programming (mostly because they are very hard to program in and make me feel more special), but you have to consider who you work for.

    The usefullness of 'M' experience could be a concern in the long run, however, I make it a point to seek out all new learning oportunities. I am in demand with multiple head hunters after me.
  • Danny Staple 2008-11-26 07:12
    I suggest people find out about Pantalk - perhaps not quite as unpleasant as useless, but getting there. Companeis are still cooking up and maintaining (for serious purposes) languages like this.
  • twelve_euro_dollas 2008-12-27 04:39
    That's just not even true.
  • HIT GUY 2009-03-26 22:47
    GE/Centricty/IDX, EPIC, Meditech, Misys/Sunquest and more use some variation on the MUMPS language. Meditech alone controls some 28% of the US and 40% of the Canadian healthcare IT market, and EPIC is among the fastest growing HIT systems providers in the world. On top of that Mr. Obama's stimulus plan throws tens of billions of dollars to that market to develop the individual electronic medical record (EMR). I say it may be an old clunky language, but lots of folks like me are amassing our BBTs servicing the users of these systems.
  • pavon 2009-04-24 19:33
    Okay lets compare some of these WTFs to some of the "darling" languages of today.

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

    Perl does this with it's scalar data type, as does PHP. Lua does this as well, although it has a separate boolean type and does not cast between number and boolean like you would expect.

    DECLARATIONS: NONE. Everything dynamically created on first reference.

    Perl, python, ruby, php and lua all do this.

    LINES: important syntactic entities. Multiple statements per line are idiomatic. Scope of IF and FOR is "remainder of current line."

    When combined with DO, this is no different from python, except you have to use "." for indention instead of white space. Honestly, it sounds like an improvement over python.

    LOCAL ARRAYS: created dynamically, any number of subscripts, subscripts can be strings or integers. Stored in process space and expire when process terminates.

    Lua also does this - the concepts of array, associative array, structures and classes are blurred into a single table data structure.
  • Re: A Case of the MUMPS 2009-06-22 18:00
    I wish I was an M programmer!! They make tons of money!! The guys at my work seriously make over 90k. They work from home, and have a secure government job.
  • Mumpster 2009-07-28 07:28
    I've been developing software in Mumps on and off for 22 years primarily in retail and banking. In between, I've tried COBOL, Basic, C, C++, Java, VB etc. etc. and have to say that Mumps is by far the fastest and most versatile of any of these other languages. I've never had a problem getting a job in Mumps and although I'm a "permie" at the moment, I have contracated in Mumps several times over the years and always at very lucrative rates. I believe that there are still enough companies out there using Mumps to ensure that the dwindling supply of Developers remain sought after and highly-paid. It's one of the best-kept secrets in the IT world and if anyone asks me in public, I'll tow the line - "yes, Mumps is a horrible language and I wish I could get a job using something cutting edge!". But now, you know different...
  • Jeremy Yorwarth 2009-12-22 11:27
    As a MUMPS programmer, I thought this article was awesome!

    But you forgot the best part, the fact that there is almost no information available on it except for the 2 books that are 10 and 20 years old. And good luck finding example code on the net.
  • Jair Nunes 2010-02-25 11:21
    MUMPS - separate the men from the boys.
  • George 2010-03-24 10:04
    I had a roommate post college and though, at least part of the time, I was forced (at Digital) to deal with BASIC and DEC's Pascal, he was sold a bill of goods that he was being "blessed" with an education in MUMPS as if he should work at a discount to pay back the learning in this vaunted language.

    He didn't last too long .. I'm recalling a little over a year. He did move to another medical place but I believe he was able to shed the dreaded decease.

    Although this story is old, I hope things worked out for our protagonist!
  • I hadthe Mumps 2010-04-06 10:54


    Back in 1998-2000, Citigroup had a project with codename Blueshift. Its competitive advantage was Greystone Mumps. The project's goal was to have 2 billion Internet banking customers by 2010. That meant 200 million customers a year! The posters touting this new millenium project were all over the walls at Citigroup's Long Island City headquarters and the data centers. The MBAs who thought of this obviously DOA chimerical, IT contraption, were clearly thinking outside the box--some box way out in the fringes of outer space. The project cost hundreds of millions of dollars and, needless to say, it went caput. A key contributor to its demise was MUMPS and its incredibly arcane interface and programming language (everything left justified, with weird caret-and-parenthesis combinations).

    Those who believe in a language that is obfuscated by design should give some thought to the following Edgar Dijktra's edicts:

    1. the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery.

    2. Elegance is not a dispensable luxury but a quality that decides between success and failure.

    MUMPS undoubtedly breaks edict number 2, with Blueshift’s collapse being another instance of MUMPS roadkill. It's highly likely that if you program in M you have fallen victim to a worse effect than BASIC has on the ill advised programmer.


  • Michael 2010-04-15 19:06
    And how many VB or .NET companies went "caput" at the time and since. Has nothing to do with the language. Your healthcare information is on a MUMPS database for sure. You're medical information is no doubt on a MUMPS database. Financial code and government apps were written in MUMPS. I've been in the M biz for 10 years and while VB 5.0 got replaced by 6.0, then .NET then the "cloud", M continues on.

    A hierarchical database that is faster than any relational database and cannot (w/out extreme difficulty) ever be converted. PLUS, Intersystems has turned M into a true OOP and get this. Once classes are mapped to the database it works like a true relational database searchable with SQL commands! BEST KEPT SECRET IN THE IT WORLD!!! Please, continue telling people to run from MUMPS. I become more and more valuable and my OOP skills transfer to any .NET shop! ;)
  • Michael 2010-04-15 19:23
    In ten years, I don't care how much you've kept up your skills you will be no match for the younger, faster, kids programming in .NET, Java, Perl, PHP, etc., who got nothing better to do than spend all night on a project for half your pay.

    Meanwhile, us old, archaic, MUMPS programmers will be learning OOP (yep! classes, objects, inheritence, etc) using Intersystems version of MUMPS with curly brace and white space syntax and laughing all the way to the bank.

    One MUMPS shop simply wrapped their legacy code with Cache (Intersystem's mumps version) then slapped on a .NET front end. Mapped their .NET classes to Cache classes which were mapped to the datbase.
  • Robert 2010-05-22 09:20
    This FEATURE MAP says it all ... the online documentation is an excellent reference, the FREE download can get you up and running WITH a comprehensible tutorial in 10(!!) minutes. Then deploy the database on a Linux server and connect to it with ANYTHING and from EVERYWHERE.

    Enough said.
  • ED 2010-06-22 12:25
    It's unfortunate that the author of this article referred to the language in its state more than 10-30 years ago. This is a prime example of immature developer bias. It is also unfortunate that the individual anecdote that was used as a generalization referred to a company that likely used an antiquated version of the product. MUMPS (or COS, as it is now called for anyone not in the OpenM camp) is an incredibly powerful language running on an incredibly fast database. It is fully object-oriented and no longer has the naming/string limitations mentioned in the article. This is the equivalent of saying Windows sucks nowadays because it only allows 8 character filenames. We all know that was true years ago, but has long since been changed.

    I highly suggest the author do a bit more research on this subject.
  • HP 2010-06-23 17:09
    Matt:
    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....


    This comment is unintentionally funny when read from here in 2010.
  • Perry 2010-07-11 22:54
    Just for grins, I decided to google MUMPS and I came across these entries:

    http://en.wikipedia.org/wiki/MUMPS

    Apparently MUMPS is a lot more wide spread then one would believe.

    It is even an ANSI standard ANSI X11.1-1995:
    http://www.techstreet.com/cgi-bin/detail?doc_no=ANSI%7CX11_1_1995&product_id=222902

    Docs:
    http://mumps.sourceforge.net/docs.html

    A news group:
    http://groups.google.com/group/comp.lang.mumps/topics


    ... who would have thought
  • Anonymous 2010-08-11 16:48
    The sad thing is, aside from the abbreviations, the "lines are syntactic entities" thing, and the necessity of function "chaining", Mumps could have been a great niche language: the "Create-on-first-reference", extremely weak data typing, and XECUTE procedure all have equivalents in PERL 5 and lower. In addition, the "super-globals" actually sound like an OK, if half-baked, database mechanism (although I pity the person who tries to port a super-global-based app to SQL.)

    Yeah, go ahead and flame me, I'm just pointing out that it could have been better, without changing too many design principles. And, I hate to say it, but THAT'S The Real Worse Than Failure.
  • D&G Ladies Leather Watches 2010-09-27 23:10
    unless you should concerning lAmid A smeach particular, certain equally discount Womens Watches though anyhow having the status of Jaquet Droz Watches Les Lunes, you surround come on the road on the road that the apposite stance. Cartier Watches Montres 21/Chronoscaph offers a deep get hold of of brin addition-name Audemars Piguet Watches Ladies Collection - Danaé at bizarre regards.we hope the so as topgreatest timbre of watch replicas friendly, in force type by the adjoining of side as well as the manufacturers to infer the most straight middling to repeat each one tyle, prepared of towering appraise equipment, afterward also species consideration. we retain crowd very inflexible quality stas well asards & material rudder to all suppliers.
    our Jaquet Droz Watches Les Lunes and Womens Watches are in effect the awfully as the primary ones having the status of including the welcoming price, high quality materials and imposing workmanship. sell Breitling Watches Aeromarine Collection - Colt Automatic is also publicized.
    our aim is to reserve you with first sort services as well as preeminent impressions watches, and issue your online shopping skill a wonderful one.9088232343002
  • lubaaronova@optonline,net 2011-01-15 22:12
    i need heip with mumps
  • Onan 2011-02-24 06:58
    Maybe see a doctor? It's contagious you know.
  • Onan 2011-02-24 07:01
    grrrr:
    ...Let me teach you something about dimensions instead. Lets take a simple cube of size 3x3...


    I see your problem!

    You do not know what dimensions are or how they work.

    You should read up on some geometry...
  • OldTimer 2011-06-11 14:49
    Say what you want about a dead language, but it's actually used all over the place in banks, insurance companys and brokerages - in addition to medical use.

    Check out the wiki on PSL MUMPS, a set of extension to the language that Sanchez created.

    They claim to have over 200 banks running on this stack.

    I know for a fact that ING/Direct uses itr world-wide for banking and so does Ally, Schwab, eTrade, ScottTrade, Ameritrade, Metlife etc. These are some of the most modern banks around.

    This technology just continues to show up in mission critical on-line back office applications.

    Must be a reason!!

  • DEEP Jones 2011-09-09 16:55
    I've worked in several languages starting back in the 80's and coming from a healthcare environment. My first real language was C combined with macro assembler. I learned Fortran, COBOL, Pascal in a school environment, but didn't hit pro programiing again until I did SQL then MUMPS. I started fixing problems for Fail projects where everyone though I was nuts for trying. Most failures come form the "Give a man hammer and every problem looks like a nail". First fail project was a hardware gen from obsolete hardware on a VAX 4100 running VMS 6.2 and OpenM. Problem solved using VB, C++, C, SML(VB like script language) and massive quantities of MUMPS. Going back from perl scripts and unix case to MUMPS case was a pain, but that's what the big bucks are for. Benchmarks -> MUMPS blows the doors off of EVERYTHING. Unstructured -> Maddingly so. With the advent of Block structuring and Cache Objectscript it's getting better, but hey. The real change and every MUMPS programmer should take heed. Java page running through JDBC to the MUMPS backend. Use discipline in programming because I for one can (and will) un-spaghetti your code and will gladly do so for a large sum $$$$. Then everyone will be able to maintain it, as I code MUMPS like a C programmer. Just because there are no guide ralis doesn't mean you don't have to stay between the lines and yes it can be done. So TCB guys and develop a better attitude and you'll realize that all programming languages both suck and are awesome. Match the tool to the problem and you'll be fine.
  • grepcat 2011-12-15 14:53
    Jesus God! I'd much rather work in assembler. At least you know WHAT is going with that.
  • Pete 2012-01-19 09:32
    luckily, MUMPS is patented, so installing it to run the ER of your local hospital will take a chunk of licensing cash.

    Naturally, the guy who designed and wrote the original MUMPS for MGH is a millionaire now.
  • penguinhowe 2012-06-19 21:06
    the point of mumps is that you can do random looks ups of small pieces of data really fast (ie grabbing a single patient's chart). its not good at doing reporting with lots of data like other database systems (ie sql).

    with the company this article is about, ALOT has changed since the "old days". performance is pretty big here now, we have to do performance testing on everything we develop. thank god we dont use the old text based editor anymore, we have a full (still homegrown) ide thats the best ide ive used so far.

    mumps is just like any other language, its gibberish until you get used to it and then you can read it just fine. although alot of our very old code is still hard to read because of all the crazy abbreviations used, but newer code is a breeze.

    we are also moving away from vb, we know its old but we have a very large code base so it takes time.

    funny thing is, as bad as this article makes the company and software sound (to be fair, this article was %100 true when it was written 5 years ago), we are the software used in about %40 of the US, and the most highly rated by a large margin. So if you live here theres a good chance that your health history is sitting in some globals somewhere.

    one last thing, the company has been around since the 70s. the name doesnt mean what you think it means. it was named long before the internet made what that word is today.
  • MNighmareShalaman 2012-06-20 06:20
    Chris:
    The system stores the line of code you were executing and the symbol table as it is at the time of the error and maintains the execution stack. It is possible for one to write self-healing code, but usually the error trap is sufficient with the stack list to figur out were the problem came from.


    Sorry but this is not my experience. I just spent hours wondering why my code was failing so miserably. It was your plain old typo problem. I had a variable with a case issue messageHTML obviously does not equal messageHtml... however, the syntax highlighting of Intersystems Studio was not good enough to point it out. The compiler was happy to let through an undeclared variable without issue and when I ran the code the error stack did not mention this undefined variable anywhere in its pages of useless error information.

    Every other language I have used would have either failed to compile, provided a compiler warning, highlighted the failed syntax and/or provided a simple error message about the undefined variable.

    My code would have executed hours earlier in any other language!

    There are 3 aspects that make a programming language good
    - error messages
    - documentation
    - large community

    Raw database/language performance come way after the ease at which it is to write and maintain an application.

    Yes I have worked with worse languages and databases, but Intersystems are certainly not the developers friends in terms of error messages and documentation, and lets face it trying to get good code examples is much easier in practically any language.
  • redacted 2012-06-21 15:09
    I worked at that company last year! I made it until the 1.5 year-hump (ask anyone who's worked there. It exists...) and got the hell out. It was a complete nightmare, and the example code is just the tip of the iceberg. I actually have PTSD from working in that hellhole...
  • city.wok 2012-07-16 19:56
    Brian had to have worked at Meditech. Retroactive enhancements retroactively to customer's needs. Not enough staff to be proactive.
  • city.wok 2012-07-16 19:59
    Brian had to have worked at [redacted]. Retroactive enhancements retroactively to customer's needs. Not enough staff to be proactive.
  • Robert 2012-11-17 17:36
    Haha... but the site having lousy standards doesn't make the language bad. In fact Mumps executed very fast (for its time) & I'vd never had more fun using a programming language. It's not quite 'out there on its own' though; I've used other interpretive languages and there are similarities... I only wish the companies had chosen Mumps instead of their home grown languages. Of course it's especially hard to read if you're not usec to it... and, to be honest, it never looks pretty, but its Mumps flexibility that allowed it to be abused. Nonetheless, I'm not sure it belongs in the 21st century.
  • Dave 2013-01-30 16:37
    I'm pretty sure I worked at that company.

    It really wasn't that bad. It was my first job, I left after 2 years (because I wanted to live elsewhere), and easily found another job. The MUMPs was way better than VB6.

    Sounds like Bryan is blaming others for his own shortcomings...
  • John 2013-02-27 16:53
    I'm looking for a better employment opportunity than my current one. I came across an advertised position for a Java+MUMPS developer the other day. Thank God I saw this post on The Daily WTF in the past so I could cringe in terror and not apply for that job...
  • A MUMPS programmer 2013-10-08 16:38
    It's easy to cast aspersions against MUMPS, and I find more often than not, it is people that are afraid of it, and have never even tried to learn and use it that have given it a "bad rap".

    It has it all OVER the "idiot languages" where you point and click at snippets of code to make your application.

    This is actual CODE WRITING - yes it requires an actual BRAIN to effectively write in it.

    Actually, I feel it should be embraced world wide instead of some of the point and click crap that is "of the moment" - that is until the next "something better" comes along.

    Try it you'll LIKE it! :)
  • MUMPS - Ugh 2013-11-10 12:37
    It is a large part of my job to write MUMPS, which I have been doing for years. I am as adept at is as one can get. I have been complimented on the clarity and quality of my code. After having just written a simply huge amount of MUMPS recently, I have to say I still hate it. It is simply, perhaps empirically, an awful language.
  • Noreen 2014-01-24 08:39
    If Brian is looking for a job still. Get in touch with me
  • not found anything better 2014-04-10 16:58
    I now code in Java, but used look back longingly at the MUMPS I used to write. It seems that Java is doing everything it can to make it work like MUMPS! Dependency injection, reflection, JPA! These things bring it to what MUMPS had innately. Big data is all about killing the RDBMS as being too slow. Client Server tried to kill MUMPS and failed, as we are now back at thin client and server side processing. Have you seen a badly written Java program! Crap programmers write crap code! I have yet to find anything quicker for developing in than MUMPS, although I use Python and PHP a lot now and they are close, but not close enough.
  • Mack Altman 2014-05-15 01:05
    Some of the biggest industries utilize mumps databases, particularly Intersystems Cache. These industries include the Financial, Health, and Transportation industries. Mumps is very versatile. The only reason it doesn't work is that programmers become complacent. Several are still programming in Cache 2010+ with deprecated functions from Cache <5.

    On a side note, I came from PHP thinking it was "so hard" when really it's just as easy to understand as Java or PHP.
  • Magic Man 2014-06-14 13:12
    What an entertaining read, I can't believe this thread started over 8 years ago, maybe Brian has found his bliss as a Walmart greeter. Mumps, M or Magic (proprietary mumps) technology are light years ahead of any of these new .NET Microsoft crap. Its called the FLAT OPERATING system that makes M so advanced, its something that will never be improved upon, take it from the Magic Man :o)
  • boz 2014-09-29 20:24
    Sadly, that made perfect sense to me! It's not even the worst I've seen :)
  • w.levetzow 2014-10-07 13:12
    From Hamburg-Germany
    We are thinking in Analogies and Hirarchies and Recoursions.
    With Mumps we can all.
    But we need more Mumps-Connections to other
    A.I.(Artificial Languages )-Languages.
    Ideas of Linux based Mumps from GT.M
    and better Installing Routines in LINUX is my Hope...


  • jim 2014-10-09 17:00
    Come to think of it, this probably explains a lot about the popularity of C++ or Java - anyone who's been using anything else for longer than six months is magically unemployable.


    I did java for 8 years, dropped out for 6 to practice law and then jumped back in with no problem at all.