Mumps: a fatal disease or a programming language?

Edward, I always enjoy your well written and insightful blogs. But what happened here? This rant is pure cobblers. Get a grip.

I was quite enthralled by Edward's "rant" about Mumps because several years ago I interviewed for a position with our local hospital (quite a large facility, considering it is connected with a medical school) and the programming language I would have been required to use was none other than Mumps. I suppose this is one of those occasions when you can look back and thank God for unanswered prayers (not getting the job). Of course it also underscored that as developers we tend to fall in love with the tool we know and become blind to its weaknesses. I am amazed at Edward's seemingly endless supply of energy transformed into text.

...and the "rant", which was not intended to be a rant, may be pure apple cobbler for that reason.

However, I believe that there has to be a space for someone informed about computer science and other languages to criticise a proposed paradigm from outside the circle of "expertise", for the very good reason that managers considering whether to adopt the paradigm need solid advice, and not just from proponents of this or that language, who are "experts" in this or that language, but also from people with no special investment in getting a position that uses their expertise.

My mentor Theodore Adorno has this to say on modern "expertise":

"But far from finding anything inimical in the prohibitions on thinking, the candidates - and all scientists are candidates for posts - feel relieved. Because thinking burdens them with a subjective responsibility which their objective position in the productive process does not allow them to meet, they renounce it, shiver a bit, and run to join their opponents. Dislike of thinking rapidly becomes incapacity for it: people who can effortlessly discover the most sophisticated statistical objections when it is a question of sabotaging a piece of knowledge, are unable to make ex cathedra the simplest predictions. They hit out at speculation and in it kill common sense. The more intelligent of them suspect the sickness of their intellectual powers, since it first appears not universally but in the organs whose services they sell. Many wait in fear and shame for their defect to be discovered. But they all find it publicly acclaimed as a moral achievment, and see themselves recognized for a scientific asceticism which to them is none, but the secret contour of their weakness. Their rancour is socially rationalized with the argument: thinking is unscientific. At the same time, their mental power has, in a number of dimensions, been prodigiously increased by control mechanisms. The collective stupidity of research technicians is not simply an absence or regression of intellectual faculties, but a proliferation of the thinking faculty itself, which consumes thought with its own strength."

In other words, "thinking" outside the box has collapsed into expert reflection and the problem Adorno points out, that we ignore as computists, is that we become biased by our need for a job.

With respect to MUMPS, my alarm bells went off at its weak typing because outside of this or that programming language, there is a computer science in which tenured faculty members of good schools (for whose authority I have to retain respect, for only a society with universities is anything other than barbarism and the will of the stronger) seem to believe that the compiler, for many applications (with life-critical applications being signal), should do as much work as possible.

A "critical theory of computer science" is to me PRECISELY that which allows us to criticise a language while not having some damn commercial or job-related brief for another language. If it doesn't exist, then what we are are all self-interested players whose capacity for judgement has been swallowed up in commodification.

In particular, I'd like to hear from you if you are a MUMPS/M developer or user.

Also, see the Wikipedia article on MUMPS and its Discussion page for details on my objections and insights from MUMPS experts.

Ed, comments like these:

"weak typing because outside of this or that programming language, there is a computer science in which tenured faculty members of good schools (for whose authority I have to retain respect, for only a society with universities is anything other than barbarism and the will of the stronger) seem to believe that the compiler, for many applications (with life-critical applications being signal), should do as much work as possible."

... seem excessively binary, even for you. Surely you don't expect us to believe that you're not aware that this topic is one that is hotly debated in academia? You imply a consensus here (whee! Thematic echoes! :)) that clearly does not exist in the real world. See the following, for example, to see both sides of the typing debate working vigourously to define their arguments:

http://lambda-the-ultimate.org/node/view/1012

http://lambda-the-ultimate.org/node/view/175

Note that I am not defending MUMPS here, by any means. Nor am I taking sides in the typing debate. I am relatively agnostic about it, myself. Taking a strong stand for static typing, as you seem to be doing here, simply denies the sheer brilliance of Smalltalk, for example, which I would deem folly. By the same token, those that argue (as I have seen some fanatical Rubyists do, lately), that having less information about a program at compile time is categorically better, are just as clearly foolish.

I am merely commenting because a) it seems a bit dishonest of you, to me, to pretend that the debate over typing is closed, and b) no one else seems to have pointed that out... :)

I have no reason to doubt your impression that MUMPS is a lousy tool. That cannot be solely due to "weak typing", however.

I'll reserve further comment on the typing issue until after Edward responds to Mark, but I will say that I am with you, Mark, in being neutral on the strong vs. weak typing debate. I can't pretend to be an expert in the deeper theoretical aspects of the debate (because I am not a language designer), but as one who has programmed extensively in languages of both types, I find that both approaches have strengths and weaknesses that come into play differently in different contexts.

We need things like scripting languages, weak typing, late binding, and JIT compilation for some classes of problems, and we also need strong typing and traditionally compiled languages. Sometimes dynamic linking is best, but static linking has it's place too. Drawing absolute lines in the sand around these kinds of things is to me counterproductive.

I sense in Edward's objections in his original post an difference in mindset that I have noticed seems to run along generational lines (and I think Dijkstra comes into play here), namely the need to be able to prove correctness in a rigorous mathematical sense. From Edward:

Weakly-typed languages cause unnecessary bugs because the compiler cannot prevent meaningless combinations of operations and data and the programmer cannot...foresee these occuring.

I share this desire to prove correctness, but (going back to the earlier C/Algol debate) I think many programmers of my generation, who have for their whole careers programmed only for business, where fudging things and imperfection is the norm, have a less intense concern in this area. If we had to prove the correctness of everything absolutely, nothing would ever get done. Ackowledging this, I don't think, necessarily needs to mean taking sides against the idea of "proving correctness." Too much of anything is likely a bad thing; too much insistence on rigor and perfection and your most likely not going to be useful to me in a business software development context; not enough and you're likely going to produce inscrutable crap that breaks all the time.

Correctness is of huge importance of course. I love for exmaple, as I'm sure Edward does, that the relational model (when properly configured with foreign key relationships and other constraints) offers some level of assurance that everything is correct; it it wasn't correct the relational engine would not have allowed you to store it...unless you forgot the put a constraint somewhere, or improperly normalized your data structures. Imperfection everywhere...

Again, it's all about context, which is why I can share Edward's misgivings about wide-open areas for uncontrolled (even undetected) error when health care is involved. But I think it's also possible that a larger analysis might find that MUMPS had actually saved a net number of lives by making certain processes more efficient/responsive, whereas a more rigorous tool might never have caught on at all, or might have been adopted much more slowly. I'm not saying that's the case with MUMPS--only that it's conceivable to me that a tool's very imperfections are what makes it successful. For ultimate good or ultimate bad, who can say. This is not unlike the amateur technologist debate that has always interested me.

Thanks for raising the typing issue, Mark.

Dan

Mark, part of evolution has to be settling a question. In general, weak versus strong typing may indeed be an open question and I'd be the last one to deny that scripting languages are useful.

But what I claimed was not that strong typing should exclude typing, instead it was that in life-critical applications in a hospital, the programming language and data base should emphasise strong typing.

Dan, I am not looking for formal correctness, just the ability to informally assure correctness more or less such as is found in a strong type language.

It is an old claim that BECAUSE formal correctness proofs are a pain in the butt, THEREFORE we can ignore correctness ARGUMENTS including informal arguments. The Golden Mean, to me, is being able to produce formal proofs as preparation for informal correctness conversation.

But as it is, an informal use of recursion in a structured walkthrough ("I have shown you how my code works for 1 record: I have shown you that IF it works for n records THEN it works for n+1 records") is met in my experience with incomprehension and an equation of this type of talk with opinion.

Here is a simple example. Formal methods alone tell us a difference between the expression a+b where a and b are unsigned int, and a-b, and a-b are likewise unsigned int, and a>=b.

In the first case a+b can produce an overflow exception or NaN (Not a Number results) whereas in the second section, as long as we have strong types, the result of the expression is bounded.

Furthermore, the result is an "algebraic" concept which can be used in further expressions. If we use a-b we don't have to worry about its boundedness whereas if we use a+b we do.

The "complexity" of mathematical expressions in various programming languages is considered by programmers to be psychological and a matter of courtesy. But this ignores the fact that expressions also have mathematical features which can be used in reasoning about them.

The reasoning is learned by making formal proofs just as we learn geometry in high school by making "geometrical constructions" using an unmarked straightedge and a compass and then proving simple theorems. Based on this we become in my view better conversationalists when INFORMALLY making a case.

In particular we LOSE the ugly language I found in the Wikipedia article on MUMPS. We don't say things that irritate the sensitive such as "programmers enjoy" (who cares what they enjoy!?) and "collect" "up" (why not down or sideways?)

We instead say things that irritate managers and in general speak more truth to power.

However, I am well aware that early on corporations denied that they needed "mathematicians" by whom they meant not only professional mathematicians but also geeks with mathematical maturity that said geeks had acquired not in formal schooling for the most part, but by geeking out (as did Noam Chomsky) on books like Lancelot Hogben's Mathematics for the Million which, according to Chomsky and in my experience, actually teaches real mathematics which really includes doing proofs.

In a simple and strong typed language, you don't have to do proofs as much because the text of the program IS the proof.

But once you get into creating "objects" as is the case when the Mumps programmer can assign new data to a Mumps variable in such a way that the old value becomes a tree sibling of the new variable, my experience has been that you then are responsible for object sanity.

You've made something with a finite number of "states", only some of which are valid.

For example, suppose in a language like MUMPS, you create a variable and assign a customer name and address. If the address is in China, the phone number should have eight digits while if the address is in the US, the phone number should have seven.

I discovered while making complex GUIs in C that the heavy use of structs made me responsible for my OWN sanity for the sanity of the object and its ability to display state. This is in fact the origin of the “core methods” in my book.

While the general outlook of MUMPS seems to be in life-critical situations that it is an unalloyed good to enable the programmer to create new things in an unconstrained fashion.

It is true that VB.Net in which I wrote the compiler for Build Your Own did not force me to inspect and to serialize but at a minimum it took care of value objects which in turn freed up my time to add the extra procedures.

Actual MUMPS practice might be on an individual or small group basis, very good and attuned to the need to review code. The problem is that knowledge is in part a social thing which means that knowledge about Oracle is more widely disseminated and available than the knowledge about “the best kept secret”.

This gives me no assurance as a US taxpayer who is concerned about the LARGE number of men and women who are returning wounded from Iraq. As it was, I’ve seen WWII and Korea veterans living on the street, then Viet vets, then Iraq I vets. PART of the reason has been a steady decline in service to veterans, and in turn this is based on computerization in which the programmers select a language that preserves their jobs.

But don't get me started: you know how I get. I'd like to hear some more specifics on MUMPS.

QUOTE 1:

"Do you mean [[Edsger Dijkstra]]? I assume you're referring to his essay [http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html How do we tell truths that might hurt?] [[User:Dpbsmith|Dpbsmith]] [[User_talk:dpbsmith|(talk)]] 13:48, 28 October 2005 (UTC)"

Yes. In particular Dijsktra's recognition that MIS and file management are in general HARDER than scientific data processing and his consequent prediction of a collapse of organizations, which may be occuring now...covered up by the fact that the first victims are the poor and vulnerable.

In fact, the collapse of public hospitals may have started long ago, in the 1980s, before which one did not see homeless families, some made homeless by lack of mental health facilities at public hospitals and lack of drug and alcohol treatment. This collapse may have been exacerbated by incompetent and as such uncaring use of inappropriate models of computation in which the only metric was speed and efficiency.

I do know that in Chicago, I did consulting for a conversion at a small Catholic hospital which had not, somehow, been eaten as of 1999 by a larger system, and I found that the programmers, who used IBM assembler and who I was training in Visual Basic, were dedicated to the core mission of the hospital. As such they did not make sillyass claims about "efficiency" as opposed to correctness (which is another word for truth).

Dijsktra's view on the unrecognized intellectual content of "simple" problems in business admin means that pragmatic arguments in favor of MUMPS ("oh well, it works, and it would cost jillions to replace") are worthless IF it can be shown that real stakeholders are victims of the pragmatic system.

Consider that my students in Hong Kong can go to the hospital under a model of care that is highly efficient in terms of time to care. This is the model (which also applies to child support in Scandinavia) that Job One is to TAKE CARE of the patient when he presents and when the care has been delivered, only then worry about the computer and the bill.

Whereas to me, the view that MUMPS is entrenched puts the apparatus first.

QUOTE 2

"I think M[UMPS] programmers would say that the whole point is that MUMPS is that is at "the '''right''' level," with traditional relational databases incurring a severe performance penalty for being at an '''inappropriately high''' a level of abstraction. Naturally RDB proponents will argue that the performance penalties aren't that high and the advantages outweight the disadvantages."

~~~~"Traditional relational databases incurring a severe performance penalty" committs TWO mistakes.

It calls a 1976 paradigm "traditional" with respect to a 1968 technology.

But more seriously, the claim is that the sets and tuples of relational data base necessarily (but in an unexplained way) incur a severe performance penalty for being at an inappropriately high level of abstraction.

This bit of data processing folklore stems from folk memories and folk psychology about a dreamtime in which because of the severe limitations of early computers (prior to 1980, an inflection point in the curve of Moore's law) occasional efficiencies could be obtained from software by lowering the level of abstraction.

The efficiencies gained were always exagerrated by programmer vanity in my direct experience and included, usually practices such as hard coding which lowered maintainability at a greater rate than they improved speed.

They also ignored efficiencies to be had by RAISING the level of abstraction as in the case where I wrote a single n-way comparision using best practice which replaced several hard coded 2-way and 3-way comparisions.

The efficiencies occured in a dreamtime, the Sixties, when in fact the lower middle and working classes in America were being downsized and destroyed by industrial developments from more intense automation to anti-union culture, but computer programmers as a class "learned" an illusion: that there narrow and specialized "skills" gave them permanent power. Within hospitals it appears that the steadily increasing complexity of the health-industrial complex (as it asserted private property rights in what was intended to be a public good, Medicare and Medicaid) enabled MUMPS and other programmers to create the illusion of efficiency but this illusion isn't, in my view, borne out by the personal experiences of patients.

The basic obscenity: the hospitals had to rapidly computerize because of Great Society programs contemporaneous with the DEC PDP-7 which required higher levels of reporting: but the apparatus created apparatchiks (of whom one example was Ross Perot, whose EDS was founded because Perot left IBM to steal IBM business in Medicare computing) who in the 1970s adopted the illusion that their financial and professional success as programmers and as entrepreneurs was Jacksonian or even Lockean, wrested from a virgin cybernetic wilderness.

With the result that the apparatchiks formed an emotional bond with the particular generation of apparatus which had ensured their success, and began, in the 1970s, to speak in blame-the-victim terms of the natural constituents of public hospitals and the VA...to differentiate their needs and goals as a New Class.

But underlying their success was the need to resist newer paradigms which would render their investment in existing systems incomplete and I have to regard the wikipedia article as issuing from this false consciousness.

For example, the article as written appears to contain a claim that a three-way JOIN involves, necessarily and for all time, the need to (1) go to the physical first key of table 1, (2) use this key to search table 2 in a linear fashion with average time n/2, and then repeat the linear operation for table 3.

Of course, the usual case is that the three tables are either physically all in sequence by the same key or indexed so as to be accessible in this way and the common data base operation is to pass through the three tables in a parallel fashion, advancing the table pointer(s) of the set of tuples with the lowest common key after delivering that set to the JOIN externals.

But I have a horrible thought. Given that the author of the article believes or seems to believe that the three way join has to be implemented using two linear searches, it may be that in the failed MUMPS to Oracle conversion, three and n-way joins were actually programmed, not using a single SQL select statement but by reading three recordsets and searching them! Which would explain the failure of the conversion.

Such abuses of data base technology happen frequently because all tuples can be indeed treated by unimaginative bozos and passive-aggressive creeps as "files".

The good algorithm is easily generalized for n Joins and its worst case performance is linear with respect to the size of the largest of the three tables. But it's as if the author never heard of it, and worse, common discussions of data base technology round de campfire often display ignorance of how data bases are implemented.

The crudest algorithms are thought to be necessary and the slowness of the algorithm is thought to be necessarily proportional to the sophistication of the facility, in an artifact of the division of labor...in which data base implementors are drawn from a different population from data base programmer/users.

The data base programmer/users feel a vague resentment at industrial overspecialization and the consequences of unequal access to educational opportunities and thus fancy that the implementors must not be all that smart and that the sets and tuples of the relational paradigm are a cover up for "inefficiency", an efficiency that seems implied by the complexity of "sets" as opposed to the more operationally understandable b-tree.

It is true that naive algorithms for sets are slow but the fact that in a relational paradigm, the operations are completely hidden (rather than divulged partly as is the case with MUMPS) means that there is no bound on optimization as long as the externals of the relational calculus are satisfied.

Whereas it appears to me (and correct me if I am wrong) that ANY representation which promises trees is bounded, efficiency-wise, by tree depth. IF the MUMPS programmer elects to represent "his" data by means of a deep tree, then it appears to me (and correct me if I am wrong) that the efficiency of the solution is bounded by the need to traverse the deep levels!

Furthermore, the author seems unclear on how OO technology works, and how a "set" represented as an object is an implicit cache either of the known elements of the set or the known paths to those elements.

The procedural mindset of the article is expressed in the clumsy phrase "collect up". This is folk Intuitionism (where real mathematical intuitionism is the requirement that sets be specified by an enumeration rule and not by reference to actual infinities).

In folk intuitionism, C. J. Date's "what and not the how" is disregarded because in an alienated spirit, all administrative requirements are viewed from the bottom as commands, to "collect up" "some data".

In data base code, folk intuitionism often surfaces as the making of static copies of record sets which in multiprocessor and network environments are frequently stale soon after creation as new transactions occur. I don't know whether this phenomenon occurs in MUMPS but IF the trees used contain nodes that are copies of data the problem is quite possible.

The basic alienation (which I must stress also occurs in Oracle and is not cured by the use of Oracle) is between C. J. Dates' vision of the ideal db user, who would be the actual senior executive, and the universal reality in which politicians and Senior Executive Service personnel in our society are selected from gamesmen and thugs, who then assign alienated MIS types the actual tasks of gathering data.

This alienation causes the latter group to seek what I think is an ersatz satisfaction in an artifact which (for all its faults) is cosa nostra, our thing, which gives the lower level types a reified satisfaction.

They can't actually serve patients or clients (troops sent to help people in New Orleans were directed instead to classes in sexual harassment: United Nations troops in Bosnia Herzegovina were ORDERED not to protect the victims of the Srebenica massacre: doctors in American hospitals themselves can't perform procedures in many cases without insurance company approval: and, of course, it would probably be a termination offense for a MUMPS programmer to interact directly with a patient). They can't set policy, only "write" policy in the circuits of the hospital's computer.

Their real stakeholders, their real "end users" become in many communities not the least powerful for whom the hospital was created but instead wealthy members of the hospital's board of directors and corporate financial angels who have to rescue the public hospital because wealthy people in America don't think it's cool to pay taxes, but do like striking eleemosynary poses when their tax avoidance creates mass misery.

It is understandable in this context that the mere programmer, denied the satisfaction of a common eleemosynary effort in the VA or at MGH, might turn inward and become fascinated with a technology such that his broader scientific awareness, never mind his political awareness and dedication to a common good, atrophies.

For a long time before Sept 11, I would sit around and listen to programmers talk about code and I heard strange, what I thought fanciful, echoes of politics in the discussion of code.

In for example the statement that it was "inefficient" to use a linked list as opposed to a bounded array I heard something of a scarcity model, in which "efficiently" using what were large virtual memories after 1980 was hypostatized as programming virtue.

I remained silent on these concerns out of humility, but then, shortly after September 11, I read Coleen Rowley's testimony, which I mention in my book, that she could not use Boolean searches.

Click.

I realized that the apparatus was out of control in the sense that a system (developed, I learned later, by IBM for the FBI in 1971) which, I learned later, actually did include Boolean searches had under the control of its apparatchiks effectively LOST the capability because of lack of documentation and because it somehow fell of the agenda.

More than this, it was a non-starter to add the capability (as a simple interpreter built on top of and in front of the old code) for this would make the apparatchiks look like damned fools.

Now, MUMPS has evolved better than this but the basic problem is the same. It's atrophied the broader scientific awareness of the sort of people who write about it for Wikipedia to the extent where they ahistorically refer to relational as traditional and b-tree as modern and imagine that a three-way join must be programmed as two linear searches.

"The big trouble with dumb bastards is that they are too dumb to believe there is such a thing as being smart."

- Sirens of Titan

See Nilges blog for extended discussion

See this link.

Here are Steve's comments as of today. I reproduce them since they may be altered or removed on Wikipedia.

Criticisms of the MUMPS Language
MUMPS has a number of features to recommend it; it can run with miniscule system requirements, non-programmers can easily learn its simple syntax, new programmers can see results very quickly. The language offers many native features that are available in other languages only though libraries.

The MUMPS community of programmers is very tight-knit and helpful to newcomers as well. It also staunchly advocates and defends the language from criticisms that it has become irrelevant, useless for modern projects or supposedly lacks capabilities of other languages. It's clearly possible to create large-scale, powerful and flexible records systems using M, so why wouldn't you want to use it?

If you have a large collection of legacy code, you don't have a choice. Objections to using MUMPS for new applications revolve mostly around long-term project maintainability.

The syntax and terms are dramatically different from C.
C is the most widely-known and widely-taught language. Even if a programmer doesn't use C, they are likely to use a language derived from C (or C++) with similar language constructs. MUMPS redefines the way some "standard" operators work in ways that a C programmer wouldn't expect. As an example, a variable is logically-true if it begins with a number (when a string is interpreted in numeric context, anything that can't be interpreted as a number is truncated). Thus the statement 'IF "20 DUCKS" ...' would be evaluated, but 'IF "DUCKS" ...' would not. Array-emulation or string operators like $PIECE and $EXTRACT number the first element '1' instead of '0'

No math or bitwise operations, no fixed-length variable types
MUMPS natively lacks any math operations like Sin(), Cos() or bitwise operations like XOR, AND or NOT. Vendors usually include a math library, but rarely bitwise operators. It's possible to interact with fixed-length records using $EXTRACT, but working with 'packed' C structures (that contain doubles, floats, etc.) is extremely difficult. This makes MUMPS generally unsuitable for interacting directly with devices, writing encryption algorithms, embedded systems and many others. Some vendors offer workarounds, but the lack of features in these areas rarely inhibit MUMPS from doing what it is designed for: medical-record keeping.

Spaces are significant
You may only use a single space to separate a command and it's argument. You may not use spaces for readability inside of arguments, nor can you 'continue' an argument on another line. It is very common to see lines 160 or more characters long in collections of code, especially where they use the $SELECT statement (MUMPS' equivalent of a switch/case statement). Dense lines of code are hard to read, understand and debug.

No multi-line comments
The 'comment' operator ';' turns everything till the end of the line into a comment, like C++'s '//' operator. There isn't a way to add a large amount of documentation to a routine other than by prepending a ';' to each line. This isn't a huge drawback, but it conspires with other language features to encourage terse documentation.

Unusual control constructs
Functions are collected into files, called routines. However, the definition of a "function" is fluid. It is essentially just a label. You can jump right into the middle of a function by calling it as label+3 (to skip the first three lines). Unless your function explicitly returns at the end, it falls through to the function below it. This can make debugging difficult, and trying to understand collections of old code very time consuming.

Variables are created by default with "global" scope
Variables created in one routine are automatically visible to all other routines unless you rigorously take steps to hide them. The 'new' command lets you create variables that are visible/modifiable only by the function that used it and any other functions that it calls. New'd variables are destroyed when execution returns to a higher calling level. There is no way to create tightly-scoped variables that only your function has access to (and not functions you call), or "class" variables that are visible to functions in your current routine, but not other routines.

Globally accessible variables are frequently used in place of parameter-passing in old code collections. Sometimes it is how you are supposed to interact with Fileman (by defining a variable called 'X' and having a variable called 'Y' defined for you when the Fileman function exits). This can make debugging difficult since you have a difficult time determiing where a variable is defined and used. Even if 'new' is used, you cannot know that other functions a routine calls aren't expecting to use that variable unless you check them all. It is not uncommon for loop-control variables (typically named 'i' or 'j') to be overwritten by some other loop in a function you call.

Length limitations
The language standard specifies that variable names must be able to contain 8 characters. Some vendors offer non-standard implementations that allow longer names, but your code is not gauranteed to be portable to other M implementations. Otherwise, your routine names and variables must be kept to 8 characters or less. Which is more readable, 'surgeryApptDate' or 'srgAppDt'? Can you decipher 'RGCLFht'? The amount of data you can store in a single node of the database on disk may also be limited. It can be anywhere from 4k to 32k. This means that if you want to store large amounts of text or data in the database, it must be split up into manageable chunks. Some older implementations even limit the size of your routines, forcing you to split up your functions into separate routines like RGCLFht1, RGCLFht2, etc...

It's not object-oriented
Object oriented code was introduced in response to growing program complexity. MUMPS is unable to take advantage of OOP's benefits to large projects, like abstraction, inheritance and information hiding. These benefits are debatable for small scripts and trivial database applications. Large non-OOP projects will usually be much harder to maintain, debug and understand. Programmers stuck with MUMPS can attempt to create an OOP-like system by storing code that is intended to be executed in the database itself (this is what Fileman attempts to do) but it requires discipline to avoid trying to access the database any other way.

MUMPS is a language, not a DBMS
Although MUMPS lets you directly access the database, the language itself doesn't offer you any management features. Lookups, Indexes, Relations, Field Typing and other features you may take for granted if you use another database are not available in MUMPS by default. The answer to this problem is to use Fileman. Fileman is a free DBMS system for MUMPS created by the VA. It's written entirely in M and is EXTREMELY difficult to understand. It makes frequent use of GOTOs, executing code thats contained in a variable, passing values through global variables instead of parameters, single-character variable names and obscure, short function names. It has documentation, although even that can be hard to understand at times. Learning MUMPS is fairly easy compared to learning the ins, outs and hidden 'Gotchas' of Fileman. On the plus side, once you understand it, it does offer many of the features of other DBMS's.

Large MUMPS projects outside the VA may be written by people who don't understand Fileman very well but use it anyway. As a result, you'll see people re-implementing their database access from scratch, often rewriting the same low-level access/write functions again for similar routines! It can be very difficult to implement access controls, field format changes, data transformations, etc... after the code has been written for a while, unless your highly disciplined programmers avoided using basic language features in favor of abstract routines from the very start.

No access limitations
By default any MUMPS program has the capability to read, write or destroy any part of the database. It is easy to destroy data accidentally, or worse; make the data get out-of-sync of the indexes so that lookups return records that no longer exist. Some vendors offer non-standard workarounds to allow programmers to work on their parts of the database without worrying about destroying data in someone else's part.

Skilled programmers are hard to find and even harder to replace when they retire
If a would-be MUMPS programmer uses the features of the language that are easiest to use, they will create poor code. It requires self-discipline to use parameter passing, good information hiding, readable blocks instead of unreadable lines, long comments, self-contained functions and avoiding GOTOs (or worse; GOTOs that jump into the middle of a function). If a new programmer isn't trained in programming style or experienced enough to have been bitten by badly written programs in the past, they are going to create festering mounds of unmaintainable spaghetti code.

Since MUMPS was marketed to programming novices, its unsurprising that vast sets of example code (like the Fileman libraries a MUMPS programmer is likely to be using) all teach terrible coding practices. You are quite likely to end up with code that is extremely difficult for anyone but the original author to understand, extend or fix. If that author gets hit by a bus, a replacement programmer will need to learn:

• MUMPS the language (it's not common to find new programmer applicants who have even heard of it)
• Fileman the DBMS (or the ins-and-outs of your unique in-house DBMS)
• The old programmer's programming style
• The old programmer's code

If you had chosen a SQL database, you could expect to find experienced programmer applicants who already have the first three parts down, and just need to learn the code. This is perhaps the main reason why MUMPS is often rejected after consideration by an organization.

I am not an expert in MUMPS, but that Nilges's blog entry is highly unconvincing and emotional. Most statements are untrue, e.g. that "weakly-typed" is the most deadly sin. Type checking is no the thing that make language or code reliable. Most reliable and bug-free codes in the world are written in typeless languages (e.g. satellite control -- most expensive hardware).

Hi'n Edward. M-M-M-Multi-dimensional DB-s is a step forward as to relational ones, theoretically (as you refer to relational DB theory). So'p MUMPS is not too "fatal". :)

Gee, is the absence of "type checking" in satellite software the reason why these things have been known to crash on our heads?

And golly, is this absence also a feature of Space Shuttle software and is that why the crews died in Challenger and Columbia?

And gosh, why is it "emotional" to connect the dots?

It would seem to me that applied science would by virtue of being applied have an ethical dimension, and one of the features of that dimension would be: IF the compiler can provide SOME assurance that the types of operations do not collide, producing nonsense known to be nonsense *apriori*, THEN the programmer has a fiduciary duty (in MIS) or a straightforward ethical duty (in mission critical applications) to prefer the type checking language and compiler.

And, with regards to MUMPS, I regard getting an operation as mission critical for the veteran.

If not using a type safe language where possible IS NOT a "critical success factor" technologically and ethically for software, then what is?

Intelligent design? Ouiji boards?

Given that raw speed isn't a consideration at the VA in all probability, then to use a language without type checking is misfeasance.

Providing a programmer with more ways to get into trouble is a bad thing unless you attain to a new level of functionality in a provable, coherent, mathematical sense...not in vapid sociological terms (which happen to be truly "emotional" as opposed to an ethical theory of applied science) of "programmer convenience", all too often translated as "I gots me a cozy job at the VA so don't mess wif me".

A critical theory of computer science is in part the realization that, in Adorno's words, "all scientists are candidates for posts", all the time (reflect on the way in which programmers track their careers according to a hypostatized "job market"). Therefore, a critical theory would bracket out the empirical facts and ask what is TRUE and FALSE, and, since computer science is no science unless applied science, would connect truth and falsity with right and wrong.

Date showed in a coherent mathematical sense that relational algebra and calculus can do "everything" parallel to the way Turing showed that a computer can to "everything".

All else is syntactical sugar and in large doses bad for computing health.

I have to reply to both of these posts, which I appreciate despite my tone here, which is hurried, at greater length later because I need to "sort out" a genuine token/type difference between code and mathematics.

It is interesting.

A question occurrs. Perhaps MUMPS development workflow makes much less bugs as comparing with popular type-safe languages? It hapens quite often. E.g. Python, it even has neither debugger nor type-safety, but probability of a bug is much less comparing to C++ or Java. In contrast, the productivity is much higher. Personaly I don't like Python. But clarity, simplicity, interactive environment may kill more bugs then type-safety.

Another thought is following. Yes, apriori type-safety defend us from some evil. But what are the existing languages, we can use in the life-critical situations? Industrial strength imperative languages like C/C++, Java? They have much reasons to get badly dangerous bugs, hard-to-detect faults, cases of hidden twisted logic. And even if such a bug found, we need to wait when the bug will be fixed by developers. But if we have scripts which are open (all can check the code) and they could be fixed withoud compilation. So is it possible, that the script (or declarative like html, xml, xsl) languages are more suitable in those life-critical situations?

OK, I understand that a weakly typed language might actually be more transparent than a strongly typed language and thus more understandable to the actual maintenance programmer!

I understand that Python may be a better choice than C++!

But...MUMPS is completely unknown outside its user community!

Precisely because it is this "best-kept secret", then it is "clear and simple" ONLY for ... tada ... the programmers at the VA who have worked at the VA since 1968 and who pelt anyone who suggests that 1968 praxis might suck with colostomy bags.

The worst result of the structured programming revolution was an ignorant counter-revolution LEGITIMIZED by Dijsktra's genuine concern that good code could be explained and could be justified.

Dijkstra, like Kant, assumed that there was a normed Subject who was truly fair and wise to a sufficient extent to sit down in a structured walkthrough.

In 1968, this only barely made sense, however. The students in Paris were in fact engaged in tearing this normed Subject a new rear end, because they believed that the calm, administrative voice of a Charles DeGaulle or Alexandre Kojeve only concealed a set of white, male, middle-aged interests in place and in position.

The result in programming was an instance of what Ortega y Gassett had long prophesied: the revolt of the revolting Masses.

I have long been of two minds about this phenomenon to the point of mild schizophrenia. I didn't catch it from Nash.

On the one hand, having been placed in the junior position, I can well identify with the Visual Basic programmer who educated himself in the programming art at East Jesus Community College, and who resents, to put it mildly, being told by an Oracle salesman that he don't know Jack.

I graduated from Roosevelt University, after all.

On the other hand, I learned through direct experience in real "structured walkthroughs"that intellectual interaction, to be productive, DEMANDS agreement on a set of core principles and meta-principles. This agreement includes a large amount of knowledge. This knowledge can be acquired outside of the university, but usually is not.

A friend from India recently said that in India, they all learn English, not because they liked Britain, but because they all mildly despise other tribes and religions, and the British are only a memory, so, what the hell, let's speak English.

Thus to insist that Mumps is clear and simple BECAUSE it is weak typed is to commit a mistake, because there isn't even the ghost of a chance that developers outside of the VA, and medicine, will even have heard of MUMPS.

It's like insisting in India that all proceedings take place in a Hindu spirit of tolerance, which, in India, is a stick of shitfire with a wick on it.

Like it or not, there is a canon in computer science and it INCLUDES strong typing.

For example, I use C despite my reservations about C, simply to be able to communicate.

In a global sense, we're in danger of a new Dark Age in which everyone insists on his own version of the clear and simple truth. The model in computing are programmers who in place of learning real computer science become language cultists.

By 1981, the phrase "structured" was a management and programmer catchphrase and in my experience meant boo hoo, I don't understand this code in the case of programmers eager to escape work, and boo hoo, I cannot manage this employee in the case of incompetent managers.

What it continues to mean canonically is that the code is restricted to the Bohm-Jacopini primitives.

Now, the danger here is that I define the Canon as the stream of books and journal articles I have read since 1971.

Ich bin der Kanon, in other words?

Where do I get off?

All I can say is that the stream included some serious bullshit and some good stuff. I could for example discern that the data processing consultant James Martin (who published several inferior books on MIS in the 1970s) wanted me to give him business.

I could see that Edward Yourdon was concerned NOT ONLY with the truth content of Dijkstra's work BUT ALSO becoming so wealthy that his New York flat was featured in Architectural Digest.

But how?

In the case of Martin, I could see that his "facts" were Utopian in the strict sense.

In Martin's book Security, Accuracy and Privacy in Data Systems, I could see that Martin was saying that by G-d, you get Security, Accuracy and Privacy by adopting secure, accurate and private principles.

Martin NEITHER discussed the philosophical issue, security for whom, accuracy for whom, privacy for whom, NOR did he show how to CODE a CRC algorithm. Today's systems are more secure than those of 1971, but this is thanks to Whit Diffie who was philosophically concerned with the issue of "for whom" (Diffie testified against FBI restrictions) AND actual algorithms.

Likewise, Yourdon's accomplishment was only to teach good classes on Dijsktra's results.

I am NOT saying that because Martin and Yourdon got rich, they should be disregarded. What I imply is more troubling; that to succeed, you have to restrict focus to the interest of powerful stakeholders, to the extent that you leave the hard work, whether philosophical, or technical, to others.

Mumps is a micro-case because the ENTIRE case for Mumps seems to be based on the interest of institutions and corporations that use it, and Mumps vendors.

There were actual algorithms in his work, but presented in such an offensively anti-programmer spirit that one doubted whether they would work.

Martin consistently adopted the CEO POV (point of view) that programmers and programming are necessary evils.

Which diminishes for the reader the trust factor, and the trust factor is important in programming since we cannot always be sure a complex program or algorithm works.

Whereas the Open Source community today is for all its defects peer to peer, and you end up liking a guy who produces actual working CODE.

For example, I consistently angered people on the Internet until May 10th 2004 when I posted the code for Build Your Own .Net Language and Compiler. Despite the fact that I remain the same offensive person, I found that people who'd downloaded the code sorta liked me, perhaps because the code didn't erase their hard disk.

I don't like the phrase "rough consensus" but I do like running code, and many of his here at Developer Dot Star have had the experience of solidarity with another developer half a world away who sends us something Cool.

But, perhaps owing to the primitive state of technology in the 1970s, all James Martin could produce was words, and in these words was a consistent bias towards the needs of CEOs. He wrote with toplofty horror of a barefoot programmer who was the only programmer able to maintain a bank's data systems while being a voluble Marxist, without taking into account the fact that it was the bank who'd adopted the software, not the programmer, and that the programmer had something of a right to say what fools these mortals be.

This is because the bank management had in a paradox abandoned the mission of management by reifying it and turning it into labor.

In the 1930s, a bank manager would think it part of his job to add up columns of figures if that's what it took, but by the 1970s, for a good reason, management was adopting, in fact, a principle first noted by the Chinese philosopher and technologist Mencius.

This is that the best managers does nothing and manages everything.

The bank management had removed entire tasks from the plate of top and middle management by encasing the business rules in code, but then discovered, after the fact, that the planned exit from the concrete world entered not a world of pure capitalistic abstraction but a "postmodern"world of concrete code.

Martin's horror at the barefoot programmer was his resistance to the necessity of labor.

That is, "management" is an abstraction, and a limit case. Mencius did note that wise emperors in China hired effective and virtuous viziers like Confucius' Wen Tzu, who although he got fired from three jobs, documented each one after his termination so his successor would not have trouble understanding the job.

But things just change once you hit the limit case, whether it's a black hole or the realization of the manager's dream that the physical employee be replaced with something that looks like, but is not, an abstraction.

Last night, at an interesting little cafe, the People's Coffeehouse in Causeway Bay, in Hong Kong, a coffeehouse dedicated to the highly nuanced and highly ambivalent way Chinese people think of Mao, I was reading the Thoughts of the old monster.

I came upon the passage that insists that true revolutionaries always think concretely.

Mao was a monster (perhaps you need to be a monster to lead a state of millions in physical collapse in 1949) but monsters like dragons can be wise.

What marxists mean when they rave about the abstract versus the concrete is that NOTHING is ever fully concrete nor fully abstract: the terms mean NOTHING except in relation.

Management wants, legitimately, to make data processing less concrete and more abstract. It doesn't want some camel driver in Tashkent to control the enterprise with an abacus, nor does it want to see the organization collapse when the Last Mumps Programmer in America retires to Boca Raton.

Therefore management LEGITIMATELY desires to approach the ideal state of full abstraction by such principles as "compiles and runs on all platforms" and the use of open standards, just as in 1971, management legitimately increased productivity by moving manual and punched card data processing to mainframes.

The concrete, embodied accountant was replaced by Autopay, and this was a good thing even if he was an Old Dear, because statistically he probably wasn't, and in significant cases was using his knowledge of the books to embezzle a retirement to Boca Raton (nowadays, only top managers can do this).

But concrete facts (such as today, the company's need for Java experts) never go away, which is why Mao said that the revolutionary always stays abreast of things like troop strengths and rice.

Martin's genre of MIS business book was based on a lie in this view, for it promised full abstraction. The actual reality was that the barefoot hippie weirdo programmer retired to Lamma Island off Hong Kong on Social Security, and his kid is now the company Java expert. The company doesn't like his kid's tattoos but is unwilling to give the kid enough health insurance for the removal operation.

So, did anybody see Proof?

I'd agree that MUMPS is an outdated turkey of a language. Nobody uses it for new applications, so its use is confined to places that had a need for a cheap DBMS in the 1960s.

Regardless, I dont see how you could go from deficiencies in the language to explaining poor service for military veterans and the Challenger disaster. MUMPS, C and SQL are all tools. Regardless of how poorly a tool does its job, a dedicated operator can eventually accomplish (roughly) the same tasks as an operator with a better tool. Consider that arrowheads made out of flint are often as sharp as steel ones, even though machined steel ones can be cranked off an assembly line thousands of times faster.

MUMPS *applications* have a significant age advantage over apps written in C/SQL. The apps that drive the VA's records system are over 30 years old and have been in continuous development throughout that time. As an example, MUMPS-based records systems were allowing more flexible searches and interactive forms a decade before mainstream database apps started adding those features. Extending these apps may now be difficult and it may make new programmers hired by the VA cry themselves to sleep, but they definitely do their job well.

The ancient-looking interface running on the monochrome monitors is still just as capable of retrieving a veteran's medical record as one driven by a more eye-pleasing windows GUI. If you experience delays with your service at the VA, I doubt it's because the database server was down or took a month to come back with your reply.

MUMPS applications are likely to remain in place simply because it would take a very long time to create solutions that replicate the 30 years worth of features. At best, it would probably take 5-10 years of *transitioning* between MUMPS, a MUMPS/SQL hybrid and then SQL-only to achieve a pure SQL solution. During that time, few new features or extensions would be able to be added to the application since the developers focus would be on transitioning. The end benefit would be a system that new programmers could immediately start working on and in a language that offers modern features. Future development from that point would be faster and more efficient. Still, the administration is unlikely to back this scheme since they won't want to pay a team of programmers 5-10 years to "run the red queen's race" and the programmers won't want to do it since they'll see it as an effort to make them replaceable.

The major problems (if they are going to be encountered) are still down the road. When the programmers who have been at the VA for 30 years retire, are the new programmers going to be able to understand and maintain what they have written? It's quite likely that at some MUMPS shops, each long-time programmer there already has a hard time maintaining or fixing code written by another programmer.

...thus the analogy may fail.

The reason why a rewrite would take a long time is that it would be a scene in which various stakeholders would fight each other for a piece of the action and the right to be the User.

Whereas if a kick-ass administrator took over at the top with a clear mission of service to military veterans, the rewrite would using today's technology take months. The trouble with this scenario is that it won't work under the Bush administration, or any Republican administration that is loth to spend the tax dollars of the wealthy on chumps...who aren't rich and fought for their country.

I'm deadly serious here. Ever since the Bonus March of 1933, in which tanks and dogs were unleashed on WWI veterans by Douglas MacArthur because those vets were demanding money due in 1945 in order to feed their families in the Depression, the mission of eleemonsynary government institutions has been to assume first that applicants have nothing coming, and start from there, and work up slow...with computer technology being "strategic" in providing excuses to slow things down.

This moral incoherence results, in my view, in overly complex software and slow delivery of same.

I am well aware that the software needs checks to avoid fraud but the trouble is that the bureaucratic culture that uses the software makes the assumption of fraud the "default value".

Mumps doesn't cause the problems but IS enmeshed in a feedback loop with the problems, and a similar admixture of an idealistic purpose with cynical self-dealing operated in Challenger and Columbia.

The cynical self-dealing is not the fault, for the most part, of the low-level "bureaucrats", whether at NASA or the VA, but of Washington administrations whose constituency is the rich, unwilling to see "their" tax dollars "misspent" except on military defense and offense, or, at NASA, on the "conquest" of space.

The Social Security Administration was set up during the 1930s with singleness of purpose (take care of the old) and during a decade when the rich had less influence on DC. As a result, working with IBM, early data systems were set up with primitive punched-card equipment on schedule and they've worked ever since...without the problems that have plagued the IRS (which has never decided theoretically whether or not those "tax dollars" are yours or theirs, which means, of course, that the tax system is unnecessarily complex and any given return, mathematically undecidable).

Sure, we can use older technology in an effective way; but MUMPS is an old system being used ineffectively as far as I can see. If veterans were not being subject to continual cutbacks (partly to pay for support of Mumps by aging Mumps guys) and longer waiting times, I would not ask whether or not Mumps is in a feedback loop with the overall problems.

Thanks for your comments. Yes, you can kill game with Stone Age weapons, but only in the exceptional case.

One of my correspondents in the newsgroup Neighbors for Peace based in Evanston Illinois has relayed the following article about the VA.

It is tangential to MUMPS because it describes a cover-up, not of the deficiencies of a computer system, but of the scientific fact, it appears, that the widespread use of depleted uranium munitions by Allied forces in the first Gulf war causes Gulf War Syndrome.

I'll post it because I find that global claims, from outside "expertise" about the science of MUMPS, are treated exactly the same as global claims, from experts but also outside the circle, about the effects of the use of DU munitions.

The psychological crisis endured in my experience by generations of programmers is a scientific crisis, because they expect to be able to maintain the dedication to truth of a natural scientist while dealing with a socially constructed world in which self-reflexivity (also known as "cover your ass") has to be a part of the equations.

Spare me any claims that I think that depleted uranium caused the VA to commit to MUMPS, or vice-versa. I am claiming that we have to know what is the common epistemological source of these syndromes.

http://www.sfbayview.com/012605/headsroll012605.shtml