- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I first read that as enough laser pointers to take down a 747. I'm a bad man.
Admin
Glad to see there was something to laugh at in today's story.
Admin
Uptime? Status!
Admin
This code was not written, it grew organnically.
Admin
Damn, beat me to it
Admin
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
Admin
Dr. Octo Barnett is behind the MUMPS? I have to stop Doc Ock before he infects the city!
Admin
If you rotate the "hatchet" side 90 degrees, he could be describing an ice axe. Rather fearsome-looking, but not too good for bludgeoning.
Admin
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.
Admin
The guys at http://groups.google.com/group/Hardhats?hl=en are really defensive if you say one bad thing about MUMPS.
Admin
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.
Admin
@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. ;)
Admin
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.
Admin
Admin
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.
Admin
Admin
I want status! [image]
Admin
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".
Admin
To which I answer "There is no way a good programmer will write good code if it is in MUMPS"
Admin
Having...Mandatory Fun Day...withdrawals...M...F...D...
Admin
Admin
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.
Admin
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.
Admin
Unfortunately, some systems are so ugly that if they do break, you can't fix them.
Admin
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).
Admin
Utter nonsense.
Admin
This is unfounded nonsense. Anyway for a somewhat more reasoned assessment see http://www.outoftheslipstream.com/node/125
Admin
Hmmmm...programming hell or sterility. Being of the male gender, I'll opt for programming hell over sterility!
Admin
[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.
Admin
Let's try that again...
So the way to write good code in MUMPS is... not to write it in MUMPS? You'll have to do better than that.Admin
Does MUMPS also cause "swollen testicles or sterility"? Or does it just make you wish that that was your worst problem?
Admin
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.
Admin
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.
Admin
What alphabet are you using?
Admin
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.
Steve lives, cause Tyson is such a nice guy and all.
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.
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.
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.
Cause he's a really nice guy and all.
Admin
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).
Admin
I would totally be down for some random programer in my company grabbing thousands of phone numbers and holding on to them forever.
Admin
Admin
I've seen this type of thing before, not just in IT, and I fail to see how MUMPS is the culprit here.
Admin
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.
Admin
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 2600314
EINSTEINALBERT`906423The 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.
Admin
350,000 lines? That seems pretty trivial to me.
Admin
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!
Admin
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.
Admin
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.