• Anon (unregistered)

    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.

  • (cs) in reply to gwenhwyfaer

    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 (unregistered)

    Brian, you poor poor bastard. Hold strong!

  • (cs) in reply to craaazy
    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.

  • (cs) in reply to CoderForChrist
    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 (unregistered) in reply to TomTheGeek

    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 (unregistered)

    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 (unregistered)

    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to Remco G

    I worked with MUMPS. I still have nightmares about it!

  • (cs) in reply to brunchboy

    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 (unregistered)

    I cry for this developer. And I'm working in a vb6 shop.

  • old mumps guy (unregistered) in reply to meh

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

  • not surprised (unregistered)

    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 (unregistered)

    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.

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

    1. 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 (unregistered) in reply to craaazy
    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 (unregistered) in reply to iogy
    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to earl

    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 (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to MadCowCoder
    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 (unregistered) in reply to jesternl
    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 (unregistered)

    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 (unregistered) in reply to MadCowCoder
    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?

  • (cs) in reply to me
    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 (unregistered) in reply to Top Cod3r

    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.

  • (cs) in reply to Top Cod3r
    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 (unregistered)

    What? No source code? I want to see this wonder language in action, dangit!

    CAPTCHA: "doom". O RLY? YA, RLY!

  • iogy (unregistered) in reply to Skroog
    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 (unregistered) in reply to asuffield
    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 (unregistered)

    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 (unregistered) in reply to NotARobot
    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 (unregistered) in reply to 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 ""

  • Multi-Lingual (unregistered)

    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 (unregistered)

    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 (unregistered) in reply to chuck

    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 (unregistered) in reply to TomTheGeek

    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 (unregistered) in reply to Top Cod3r

    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. (unregistered) in reply to Sgt. Zim
    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 (unregistered) in reply to A nonny moose.
    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. (unregistered) in reply to the-moss

    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. (unregistered) in reply to obediah

    My sentiments exactly.

    I'm ready for battle brother.

  • (cs) in reply to gwenhwyfaer
    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.

  • (cs) in reply to earl
    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 (unregistered)

    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 (unregistered) in reply to gwenhwyfaer

    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

  • (cs) in reply to Bill P.
    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.

Leave a comment on “A Case of the MUMPS”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article