• (cs) in reply to dhromed
    dhromed:
    The scene was a three-hour, seemingly unending procession of PowerPoint slides with enough laser pointers to take down an incoming ICBM.

    I am amused.

    I first read that as enough laser pointers to take down a 747. I'm a bad man.

  • (cs) in reply to PIercy
    PIercy:
    as for CC card numbers, thats a mistake a 12yo makes when creating scripts for people.
    I find it interesting that you've reviewed sufficient variety of credit card processing code written by twelve year olds to make that assertion.

    Glad to see there was something to laugh at in today's story.

  • (cs) in reply to Submarine
    Submarine:
    99,9% uptime means whole 8 hours of downtime per year P.S. Freights
    In this case there's absolutely no evidence whatsoever that the 8,754 hours of "uptime" serve any better purpose than the 8 hours of "downtime."

    Uptime? Status!

  • daqq (unregistered)

    This code was not written, it grew organnically.

  • (cs) in reply to Benanov
    Benanov:

    Bludgeoning with a hatchet is the real WTF.

    Damn, beat me to it

  • NotSoSure (unregistered) in reply to ContraCorners

    Not really. It's been greatly reduced in the first world, but is still very much a factor in the developing world.

    See: http://en.wikipedia.org/wiki/Mumps

  • Spider-Man (unregistered)

    Dr. Octo Barnett is behind the MUMPS? I have to stop Doc Ock before he infects the city!

  • (cs) in reply to Dirk Diggler
    Dirk Diggler:
    snoofle:
    Benanov:

    Bludgeoning with a hatchet is the real WTF.

    Not really; I have something - not really sure what to call it - that has a hatchet blade on one side and what can only be called an 8 inch spike on the other - you could easily bludgeon someone with it and then use the hatchet to ... well, you know ;)

    A hatchet with an 8 inch spike? Is it intended to be a tool or a fighting weapon? I'm looking at a fire axe right now, the spike is only 3-4 inches. You could put your eye out with that thing.

    If you rotate the "hatchet" side 90 degrees, he could be describing an ice axe. Rather fearsome-looking, but not too good for bludgeoning.

  • Alan (unregistered)

    And this is why the avegae punter ends up hating and dis-trusting IT types. If I was the manager there they would be changing. I don't care how much red tape.

  • (cs)

    The guys at http://groups.google.com/group/Hardhats?hl=en are really defensive if you say one bad thing about MUMPS.

  • N Morrison (unregistered) in reply to ContraCorners

    And even if you get it, you will be over it in a few weeks with minor side effects:

    Symptoms usually last about 10 days and may include:

    Swelling and pain in one or more of the salivary glands. One or both cheeks may look swollen. Fever of 101F to 104F. Headache, earache, sore throat, and pain when swallowing or opening the mouth. Pain when eating sour foods or drinking sour liquids, such as citrus fruit or juice. Tiredness, with aching in the muscles and joints. Poor appetite and vomiting. Swollen testicles or sterility.

    So as you can see it is much to be preferred to the MUMPS systems.

  • fdr (unregistered) in reply to dkf

    @dkf - are you sure you're not "tnc"?? ;)

    the whole price calc formula looks like tyson might have tried some code at some point that transferred the remainders of transactions into a personal account. ;)

  • (cs)

    MUMPS is a great example of how good marketing can sell a terrible product. I mean, I've never seen its marketing, but just the fact that people besides its creators are using it says enough.

  • adsfg (unregistered) in reply to seamustheseagull
    seamustheseagull:
    Our SAP system (cue: "TRWTF is SAP") has over 70,000 tables, with the vast majority of table names having five characters or less.

    I refuse to believe that you could gather any group of SAP developers who can tell what even 10% of those tables are for.

    SAP is old. Real old. It's so damn old, the dropdown was not invented when it was initially released. Neither was multiline textboxes. You should be lucky that you have table names with five characters. Do you know how much memory that uses?

  • Rob (unregistered)

    Surprise, surprise! It's possible to create a real mess in Mumps just like in any other language and database, and someone can be out of control in a department. I dare say that with a few minutes dregding I could come up with similar horror stories related to Java, .Net, PHP, Python etc etc.

  • (cs) in reply to fdr
    fdr:
    @dkf - are you sure you're not "tnc"?? ;)

    the whole price calc formula looks like tyson might have tried some code at some point that transferred the remainders of transactions into a personal account. ;)

    A good question. No. While it would have meant I'd have had the opportunity to get a lot of money, it would have also meant that I'd be completely mad due to MUMPS. (I reserve my madness for WSDL…)

  • Bas (unregistered)

    I want status! [image]

  • (cs) in reply to snoofle
    snoofle:
    Benanov:

    Bludgeoning with a hatchet is the real WTF.

    Not really; I have something - not really sure what to call it - that has a hatchet blade on one side and what can only be called an 8 inch spike on the other - you could easily bludgeon someone with it and then use the hatchet to ... well, you know ;)

    And which definition of "bludgeon" would this be, then? "A short, heavy club with one end weighted, or thicker and heavier than the other", "to strike or knock down with a bludgeon", or "to force, coerce or bully"? Anyone who's seen CSI at least once has heard the term "blunt force trauma"... I don't think either side of your hatchet thingy would qualify as a bludgeon, nor would the victim be "bludgeoned". Sounds more like you're looking for "hacker".

  • (cs) in reply to Rob
    Rob:
    Surprise, surprise! It's possible to create a real mess in Mumps just like in any other language and database <snip>
    Yeah yeah we know it. "There's no language that will prevent a bad programmer from writing bad code" et al.

    To which I answer "There is no way a good programmer will write good code if it is in MUMPS"

  • (cs)

    Having...Mandatory Fun Day...withdrawals...M...F...D...

  • mauhiz (unregistered)
    • this is MUMPS Madness
    • NO, THIS IS SPARTA
  • Worf (unregistered) in reply to Franz_Kafka
    Franz_Kafka:
    dhromed:
    The scene was a three-hour, seemingly unending procession of PowerPoint slides with enough laser pointers to take down an incoming ICBM.

    I am amused.

    I first read that as enough laser pointers to take down a 747. I'm a bad man.

    It only takes 1, actually to bring down an airliner. You just have to dazzle the pilot flying (not necessarily the captain - could be the first officer) with it and there may not be enough time to react or go around. Or to be doubly sure, do both pilots. More effective at night too, since the light will seriously screw with the night vision required to land.

    That's why it's not only dangerous, but the FAA takes a very dim view of people doing so at airports (I believe it's a criminal offense, even).

    Taking down an ICBM, though, takes more lasers since dazzling the "eye" of it will just make it go off course but it still will explode.

  • Lutikka (unregistered)

    So it's not possibly to create such a system with some other development platform, than MUMPS? Seems to me it was just a badly designed, not really the platform's fault.

  • iToad (unregistered) in reply to Steve
    Steve:
    I guess the question to ask after reading this horror story is: did the system work? And did it work any better after it was audited (modulo removing the credit card numbers, which is certainly a Good Thing, though, given the load of other personal information in the system may have been largely moot from an identity theft standpoint)?

    Sometimes, as ugly as a system might be, if it ain't broke, don't fix it.

    Just sayin'.

    Unfortunately, some systems are so ugly that if they do break, you can't fix them.

  • (cs)

    To give a little more “real world” example of the horror that is MUMPS, start by taking one part [[International Obfuscated C Code Contest]], a dash of Perl, two heaping measures of FORTRAN and SNOBOL, and the independent and uncoordinated contributions of dozens of medical researchers, and there you go.

    Well, there you go.

    A Real Programmer would have devised it to use the APL character set.

    Ahhhh, SNOBOL. If Edsger Dijkstra ever wound up as a programmer in Hell, he would be forced to program in SNOBOL, in which one of the five optional sections of EVERY executable statement is a Goto based on the Success/Fail rating of the statement's execution (Not a criticism -- SNOBOL was my favorite language ever, with APL a close second).

  • Rob (unregistered) in reply to Smash King

    Utter nonsense.

  • Rob (unregistered) in reply to Smash King
    Smash King:
    Rob:
    Surprise, surprise! It's possible to create a real mess in Mumps just like in any other language and database <snip>
    Yeah yeah we know it. "There's no language that will prevent a bad programmer from writing bad code" et al.

    To which I answer "There is no way a good programmer will write good code if it is in MUMPS"

    This is unfounded nonsense. Anyway for a somewhat more reasoned assessment see http://www.outoftheslipstream.com/node/125

  • Dredge Slug (unregistered) in reply to N Morrison
    N Morrison:
    And even if you get it, you will be over it in a few weeks with minor side effects: -------------------------- Symptoms usually last about 10 days and may include:

    Swelling and pain in one or more of the salivary glands. One or both cheeks may look swollen. Fever of 101F to 104F. Headache, earache, sore throat, and pain when swallowing or opening the mouth. Pain when eating sour foods or drinking sour liquids, such as citrus fruit or juice. Tiredness, with aching in the muscles and joints. Poor appetite and vomiting. Swollen testicles or sterility.

    So as you can see it is much to be preferred to the MUMPS systems.

    Hmmmm...programming hell or sterility. Being of the male gender, I'll opt for programming hell over sterility!

  • Duke of New York (unregistered) in reply to Rob

    [quote user="Rob"][quote user="Smash King"][quote user="Rob"]"There is no way a good programmer will write good code if it is in MUMPS"[/quote]

    This is unfounded nonsense. Anyway for a somewhat more reasoned assessment see http://www.outoftheslipstream.com/node/125[/quote] So the way to write good code in MUMPS is... not to write it MUMPS? You'll have to do better than that.

  • Duke of New York (unregistered) in reply to Rob

    Let's try that again...

    Rob:
    Smash King:
    "There is no way a good programmer will write good code if it is in MUMPS"
    This is unfounded nonsense. Anyway for a somewhat more reasoned assessment see http://www.outoftheslipstream.com/node/125
    So the way to write good code in MUMPS is... not to write it in MUMPS? You'll have to do better than that.
  • jt (unregistered) in reply to N Morrison

    Does MUMPS also cause "swollen testicles or sterility"? Or does it just make you wish that that was your worst problem?

  • (cs)

    If you follow the above links, you can see that an GPL Affero implementation of MUMPS is being touted as another "Internet-scale" database like simpleDB & AppEngine. It does make sense that, as a hierarchical (rather than relational) database it would be ideally suited to XML-style data. Whilst MUMPS looks like a horrible language to develop in, the excoriation delivered in these comments is probably excessive. I'm sure its no worse than its relatives of the same vintage.

    However,the WTF related here seems like just the sort of thing that can happen when large scale development is based on a tightly controlled closed-source archaic language.Any community that grows up can become like a group of high priests or magicians, invoking their "black arts" and "cargo cult" programming, trying to know the unknowable. I've never worked with SAP, but all those big old enterprisey systems look the same to me."Jehovah" would be a good name for one of those products.

  • Anonymous Coward (unregistered)

    To be fair; bad design, bad naming conventions, bad coding are hardly unique to MUMPS applications. All examples in the "interesting findings" part could have been picked up from any system which has evolved over the past twenty years - regardless of the implementation tools. It would've been interesting to see some MUMPS-specific problem examples of the implementation.

  • Random832 (unregistered) in reply to Mark
    Mark:
    If all table names are <= 5 alpha characters then that gives you 32^5 =

    What alphabet are you using?

  • Steve X (unregistered)
    Great. Now that they have a web server written in MUMPS, they can write a server-side MUMPS parser, so all of their web apps can be written in MUMPS as well.

    The MUMPS webserver is now the central core of the CASTLE application. Large quantities of badly-written MUMPS code that used to serve up screens of data via telnet now serve up HTML. Most of the functions that do so will both retrieve and print data, preventing their re-use in other parts of the application.

    did tyson murder steve after learning that steve had deleted his stolen credit card stash?

    Steve lives, cause Tyson is such a nice guy and all.

    The example given of the loop ....

    You're correct, it's not a loop. It's code inside a loop that was going through clients and notes. It was inserted right before the code that destroys the credit card number.

    I guess the question to ask after reading this horror story is: did the system work? And did it work any better after it was audited (modulo removing the credit card numbers, which is certainly a Good Thing, though, given the load of other personal information in the system may have been largely moot from an identity theft standpoint)?

    Sometimes, as ugly as a system might be, if it ain't broke, don't fix it.

    Yes, the system worked even though about 60% of it's tables were no longer in use. We're in the process of removing them from production. So far, about 50 tables have been removed without incident. We're still categorizing the rest of the unused ones to see what needs to be archived to CD before deletion.

    In a related analysis project, we discovered that over half the code isn't being used either. I removed 1300 source files that contained no code that was still in-use. Of the remaining 900 source files, it's quite likely that less than half the functions in them are used.

    There's absolutely no sense of reverence for the production system; neither the tables on it nor the code checked out onto it are considered carefully. In fact, it was common practice until a few months ago to create new tables on the production system and THEN copy them over to the test system to work on.

    I really don't see the point of analysing MUMPS "tables" as if they were structured like relational databases instead of B* tree's that they are.

    Although the database is technically stored as BTrees, the Fileman DBMS creates a relational database structure on top of that. Aside from some hacks that make use of the BTree structure to allow you to have some features that are widely available in other DBMS systems (cascading deletes, one-to-many relationships), it's still basically a relational database with tables.

    The Real WTF: Why was he not fired on the spot? People get fired for far less than that!

    Cause he's a really nice guy and all.

  • turnip (unregistered)

    In re: bad mathematics -- In the years before I was a MUMPS programmer (which is to say, before 1985), I had a co-operative education job with a company that made satellites. I discovered in the code (Fortran) a subroutine (called from all over) to find the difference between two signed numbers. How did it do it? It found the difference between the absolute values of the two numbers, then made the result positive if the two numbers had the same sign, negative if they were different. I couldn't believe it! This program would believe that -4-3=1! And this when Fortran is perfectly happy to subtract signed numbers. I triple-checked to make sure I wasn't seeing things, then brought it up to my boss, who agreed it needed to be fixed. This is a program they had been using for more than a decade. The purpose of the difference calculation? To see how far an instrument shifted pre- and post-(simulated) launch, to make sure things wouldn't, say, fall off. Fortunately, it appears to have never made a difference in real life, but it could have meant $$$$$$.

    The point is, bad mathematics and brain hiccups are possible in any language, not just MUMPS, no matter how many pairs of eyes are overseeing the code (and they, like my current MUMPS shops, had many).

  • Ponedonkey (unregistered)

    I would totally be down for some random programer in my company grabbing thousands of phone numbers and holding on to them forever.

  • Ponedonkey (unregistered) in reply to Ponedonkey
    Ponedonkey:
    I would totally be down for some random programer in my company grabbing thousands of phone numbers and holding on to them forever.
    Oh snap, I put phone numbers insted of credit card numbers. I need some sleep.
  • Chasmoe Brown (unregistered)

    I've seen this type of thing before, not just in IT, and I fail to see how MUMPS is the culprit here.

  • Joey Rukkus (unregistered)

    I'm not sure i understand how MUMPs is the part of this equation that sucks. It sounds to me that the programmers were shit. Same with "A case of the mumps" story. Both sound like the company and the programmers are a bunch of failures. If you are good enough to use MUMPs correctly then its fairly easy. I use it everyday for a large Medical company and I love it.

  • Chris (unregistered) in reply to N Morrison

    All programming languages have their upsides and downsides. The fact that this application was obviously badly designed is down to the application designers, not the programming language.

    MUMPS is an old language, developed in the 60s. That doesn't make it a bad thing in itself - Unix is about the same age, as are the protocols that drive the Internet, and we're not about to throw them out any time soon. It does mean, of course, that there are lots of applications out there that were build 40 years ago and have been added to piece by piece to end up with monstrosities like the ones described above.

    But let's put it in context. In the 1970s, technology was expensive. A lot of the atrocious features attributed to MUMPS date from a time when saving a byte or two of memory was all important. This led to one-character abbreviations, poor data design (repeating groups rather than a decent hierarchical design) and cramming several statements on one line (that saves a whole two bytes per statement - CR/LF). This lead to code that ran quickly on the hardware available (usually a PDP/11 in those days) but was difficult to maintain.

    Most of those features are still available for backward compatibility but it is possible to write efficient but readable code and implement good database design in MUMPS. Indeed, the hospitals my company deals with have been horrified on moving to shiny "new" hospital systems costing them millions of pounds (which often turn out to be poorly designed systems with some pretty front ends) that the six PCs that are currently running the hospital applications with a database of around a million patients quite happily and efficiently will need to be replaced with about four times as many servers at vast cost, and that processes that used to take seconds to run cause the department to grind to a halt when they "upgrade" to the shiny and expensive new system.

    Our data extract (pulling off all the data from a large system into a flat file format to be imported into the new system) took us about 12 hours to run under MUMPS running on a very old legacy Unix box. On a one-year old PC running Cache, it took about 20 minutes. The suppliers of the new system said they would need two weeks to load up the provided files, even though they were in the format that they specified.

    The fact is that MUMPS does what it was designed to do very well. It's a good, efficient database, and extremely scaleable - from one-user systems handling a few thousand records to vast thousand-user systems handling the entire medical history of over a million patients.

    It has some terrible features too - namely that database design is entirely down to the application developer. At least with any relational database you know what the fields are called (even if the names aren't very helpful). In MUMPS, you don't even know what the field delimiter is, let alone the names of a field - so maintaining old applications without any documentation is a nightmare: a patient demographic record may look like this, for instance:

    ^LCF(309887)=MN 2600314EINSTEINALBERT`906423

    The fact that the first character is the sex, the second the NHS status, the third a deceased flag, the fact that 2600314 means 14 March 1960, and that 906423 is a pointer to another global - none of that is inherent. That structure was designed years ago by an application developer, who if they forgot to document it (or more likely the documentation is printed out on 30 year old lineprinter listings and is sitting in a cupboard somewhere in the bowels of the hospital) means that trying to work out what is going on is impossible. It's very easy to knock up code in MUMPS, and very difficult to maintain it if it's not well written - and it's very easy to write BAD code in MUMPS. There's no database integrity either - the application is responsible for creating and maintaining indexes.

    As for Cache, I'm dubious. MUMPS is an efficent but old-fashioned green-screen programming language, and it's good at what it does - dealing efficiently with massive databases with highly variable length data (patient records are excellent examples - Mrs. Smith went to hospital once in 1989 and had a single blood test; Mrs. Jones practically lives in hospital and has had 30 operations, 1000 blood tests and a huge long history to be recorded). Trying to rebrand it as "post-relational" and sticking a load of clunky and unintuitive layers on top of it and pretending it's a web-based technology is disingenuous.

  • a mumps guy (unregistered)

    350,000 lines? That seems pretty trivial to me.

  • Iver Erling Årva (unregistered)

    I have been a programmer since 1984 and Mumps is by FAR the most effective, compact, easy to change programming language I have ever come across. People saying otherwise simply doesn't know how it is to program in Mumps. There is of course a learning curve and you need to get used to the abbreviated commands, but once you have this covered there's simply no contest. Typically one command in M(umps) is replaced by 10-20 in other languages. It is SO frustrating to have to remember all those commands. I have found myself writing libraries that emulates the M(umps) commands when using languages like C++, VB or others, simply to make my program code more compact and effective. So that! And the database speed... wow! Oracle and MS SQL go hang yourselves!

  • Roger Foco (unregistered)

    It is not the fault of the language or database that someone is an idiot analyst. The same guy or girl could have just as easily screwed up any other application in another programming language.

  • Roger Foco (unregistered) in reply to Iver Erling Årva

    I concur, I have worked with all of the above.

    Oracle and MS SQL databases are not even out of the gate and Global DB (MUMPS DB) is already finished, gone home, had dinner and is comfortably watching a movie.

    Nothing else comes close. That is why the largest banks and trading institutions in the world use it - for its speed, reliability and scalability. Additionally, here is another cost saver, the database is self maintaining, where the ratio of production databases to DBAs is 100 to 1.

    With InterSytems Cache (OOD/OOP there is no limit and no equal).

    Case Closed.

Leave a comment on “MUMPS Madness”

Log In or post as a guest

Replying to comment #:

« Return to Article