• Kevin Zelhart (unregistered)

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

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

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

    Please, for the love of god, all of you move to fucking India or Russia. Now.

  • J (unregistered)

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

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

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

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

    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.


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


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

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

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

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


    anything can be done wrong.

    most Bash script are a dread.

    see some scripts that actually work at ref above.

  • M-Lover (unregistered) in reply to Flo

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

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

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

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

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

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

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

    That's just not even true.

  • HIT GUY (unregistered)

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

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

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

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

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

    MUMPS - separate the men from the boys.

  • George (unregistered)

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

    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 (unregistered) in reply to I hadthe Mumps

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

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

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

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

    Just for grins, I decided to google MUMPS and I came across these entries:


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

    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.

  • lubaaronova@optonline,net (unregistered) in reply to Robert

    i need heip with mumps

  • Onan (unregistered) in reply to lubaaronova@optonline,net

    Maybe see a doctor? It's contagious you know.

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

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

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

    Jesus God! I'd much rather work in assembler. At least you know WHAT is going with that.

  • Pete (unregistered)

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

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

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

Leave a comment on “A Case of the MUMPS”

Log In or post as a guest

Replying to comment #:

« Return to Article