logo
Published on developer.* Blogs (http://www.developerdotstar.com/community)

Mumps: a fatal disease or a programming language?

By Edward G Nilges
Created 2005-10-21 07:50

[In researching Mumps, an outdated software system still heavily used in American health care, for a client, I have learned some very disturbing things about the software in use in life-critical situations. In particular there is an inappropriate promotion of Mumps at Wikipedia [1] at which although apparently technically accurate about MUMPS/M and complete was written by a wiki contributor blind to the defects of Mumps and ignorant of relational data base. This is my opinion on Mumps as a part of an increasingly dysfunction health care system in America.]

This bad, non-NPOV promotion of an outdated language by someone who may be engaged in an inappropriate commercial promotion of Mumps is the worst Wikipedia article I have ever seen.

The author does not know relational data base theory. The relational model does NOT dictate, as the author seems to believe, implementation details such as a fixed length size for tables and records. The relational model is in fact completely independent of any one implementation technique whereas the b-tree internals of Mumps affect and are reflected in the externals of Mumps, which means that unlike a relational data base, a Mumps system, in all probability, cannot be re-architected using anything better than “b-trees”, a somewhat outdated technique which can generate slow response because the depth of any one b-tree is unbounded.

The author is irresponsibly recommending a weakly typed language for patient and clinical data in life-critical applications. Weakly-typed languages cause unnecessary bugs because the compiler cannot prevent meaningless combinations of operations and data and the programmer cannot (especially in the highly-interpretive, “powerful”, self-reflexive environment of Mumps where instructions can be treated as data) foresee these occuring. Mumps is that type of environment in fact in which latent bugs can exist for years and then erupt at a critical point (in a clinical trial where human life may be at stake) when, for example, a date reaches a certain value. Mumps is Y2K on steroids, it appears to me, trouble waiting to occur.

The language of the article is a sort of programmerese…while ignorance sometimes designates honest computer science argot as “programmerese”, actual English “programmerese” is something quite different.

It is a language which emerging from a necessary focus on detailed process arrives at half-literate ways of expressing the whole from a partial view inside the whole. It’s language which here systematically aborts the “what and not the how” promise that data bases will be programmable using sensible queries that (in C. J. Dates’ view, where Date is one of the founding fathers of modern data base theory) will express transparently WHAT is wanted and not HOW to get it, because everything in the language is “how”. And how…

Consider the phrase “collect up”, which occurs more than once in this article. The whole point of relational data base theory is avoidance of this ugly and unseemly phrase and its replacement by the logic of sets, so that there is a one to one correspondence between a concept as it exists in the mind of a responsible user (here, a medical doctor working 16 hours a day to save lives or a clinical researcher with the same mission) and the set of entities falling under the concept, and the end user (not some aliterate programmer who speaks and writes “collect ‘up’”, a meaningless phrase) can responsibly communicate his intent not only to the computer system but also to another professional.

The honest user of Mumps wants, I believe, to say to one of his peers, “the patients who have been tested under protocol A”, but the demotic programmerese intervenes and the doctor or researcher is forced to refer to shadowy and folkloric entities which have been “collected up” … in life-critical applications!

There are some real gems in this article, examples of the way in which overspecialization in programming and a profit-driven health care system in the USA rots the brain. Here are a few.

“MUMPS is different from now-standard programming languages which restrict the programmer from doing anything unusual”

Wow, tell this to the judges of the International Obfuscated C Contest. Any programmer is able to express, in a Turing-complete programming language, any Turing computation and there is an infinite number of “unusual” things he can do.

As to writing crap code which modifies executable code stored in strings in irresponsible ways, to the extent this does not enable the programming language to be Turing complete, it is a good thing that modern programming languages such as Bertrand Meyers’ Eiffel make such detours and such frolics inadmissable…especially at places like Massachusetts General Hospital or veteran’s hospitals, where human lives are at stake at the institutions, which have standardized around Mumps.

“Programmers enjoy its clean definitions and compact code”

How nice that must be for the programmers at the former Veterans Administration (now, the USA’s Department of Veteran’s Affairs), one of Mumps’ main users. Meanwhile, the waiting time for actual military veterans has increased to five years for life-critical procedures, in part owing to runaway costs that are not (see below) incurred in other countries, resulting from overinvestment in data bases created for out of date computers informed by the limitations of the PDP-7, which is forty years out of date.

“Programmers enjoy” is a species of alienated language that can be deconstructed (without apology) from two directions. As employees, programmers without false consciousness enjoy less work and more money and it is the company’s job to limit the fun in this regard. Furthermore, the language encapsulates an assumption, which is that white collar is and will remain “professional”, but not in the sense of medicine and law’s professional duties, but rather the professional perk of enjoying the content of the work.

A programmer who “enjoys” the “clean definitions” and “compact code” of Mumps is a species of false consciousness because in terms of today’s art the definitions are not clean, and compact but wrong code is useless.

“M has been called the best-kept secret in the IT industry. “

This is a completely inappropriate commercial promotion of Mumps, and, it is fraud. It is fraudulent because no company outside health care would seriously consider obtaining Mumps even though Mumps is free as a data base. If I mail a printout of the article to client, I commit mail fraud.

Any CTO that seriously recommended Mumps outside of health care would be fired despite the fact that Mumps as source code is free (its necessary intensive care in the form of support without which Mumps, as a legacy and bug-ridden product, is not at all free).

“During the early 1980s a number of vendors sprung up to market MUMPS-based platforms. “

This lets the cat out of the bag. Owing to the barbaric structure of American health care, in which since Harry Truman health care has been denied the poor and now the middle class as a human right, a vast health-industrial complex, as self-interested and entrenched as the military-industrial complex, has a vested interest in private health care and in soaking people least able to afford it. In software, this is the use of excessively privatized and proprietary approaches, focused not on accurate record keeping nor on patient care but on ownership, control, and profits.

This involves in the case of Mumps holding laboratories and hospitals hostage. Laboratories and hospitals are held hostage, it appears, to proprietary parsers and interpreters which are completely opaque, whose users now depend on erroneous behavior with the result that long-standing bugs are now features and cannot be fixed.

These systems are “maintained” by people who have specialized only in Mumps, where the features of Mumps are idiosyncrasies, a time sink which destroys opportunities for professional growth. As a result it appears from the Wikipedia article that the computing culture of Mumps’ compiler and interpreter developers has atrophied, and that they seem to believe that today, strings and arrays can be without special measures restricted to 1967 sizes, which forces the Mumps applications programmers to likewise become technically, culturally and in the last analysis spiritually stunted “experts” in a normalized-deviant paradigm.

[Note: see Diane Vaughan’s book The Challenger Launch Decision for an excellent account of “normalized deviance” in engineering.]

I am familiar with the language of these people, who in my view are in part the victims of industrial overspecialization, reification (the confusion of things and concepts) and moronization. It is a computing style which strains, and ultimately fails, to express logical and mathematical concepts in a clerkish fashion (collect “up”) and which all computing questions to one understandable dimension: that of “efficiency”.

In the 1970s, Herbert Marcuse showed how “man” becomes “one-dimensional” and part of this is the search for a one-dimensional scale to resolve the “important” questions posed not by mathematical truth, let alone elegance but by career, and here the scale is an efficiency which appears to mean wrong (or unknown to be correct, in other words wrong) answers at high speed.

“Oh, we converted to Oracle but it was so slow that we went back to Mumps”. What this may mean was that the employees who “converted” to Oracle were so filled with resentment at having to actually learn something new, so stunted as victims of the process, that they sabotaged the conversion or simply did not understand the relational model at all…as in the case here, where the Wikipedia author actually claims that one must implement SQL join by three separate “lookups”.

Oracle as a corporation is reasonably honest about what a conversion to Oracle involves. It involves re-engineering and removal of entrenched special interests.

One claim that indicates that conversions out of Mumps are being aborted by a part of the health-industrial complex is the author’s weird claim that a three-way Join must be implemented by three “lookups”, with the unstated implication being that these must be linear searches; this claim even changes, during part of this deliberately incoherent article, into the bizarre claim that the user must, in a relational data base, program these lookups!

Of course, in a Join in the real world, most of the time the Joined tables are accessed by primary key and hence in sequence, which means that a simple n-way match-merge algorithm which can be mastered by any computer scientist does the Join in linear time. I realize, however, that prior to SQL and in the era of tape merging, many so-called programmers could not master, in Cobol, the 2-way algorithm and wrote much code that dropped records on the floor or blew up when one tape was empty. The fact remains that knowing this algorithm’s existence is a minimal criterion of competence; that it was not met in the past was normalized deviance, as is the author’s imagined algorithm for a Join.

“One main difference between M and most other languages is that M has only a single data type, the string, which it invisibly converts into common data types such as numbers or dates.”

This fact alone should have disqualified Mumps from being used for life-critical health care and research at MGH and the VA. It means that Mumps is for script kiddies and is bug-prone. It means that the compiler cannot check type compatibility.

The IBM mainframe language Rexx died ten years ago because it shared this property with Mumps, and languages that insist that “everything is a string” are not fully compilable, are unsafe, and cannot easily be internationalized to “strings” expressed in languages other than English, which means that Mumps is culturally imperialistic. Its adoption by other countries will subordinate foreign language users to the USA’s health-industrial complex.

“The key to the M system is that all variables are automatically multi-dimensional”

OK, this is fairly interesting (but no innovation, and no “best-kept secret”) and what it means is that any variable is potentially a tree. You can at any time assign a new data segment, thereby complexifying a simple “scalar” item into a vector (a one-level series of scalars) or a multilevel, multibranch tree. I will assume as a layperson with respect to a false “Mumps expertise” that these trees cannot somehow backreference to higher nodes under any circumstances, which would transform them from trees to graphs and create all sorts of problems starting with loops…but given the multiplicity of profit-driven implementations, one cannot be sure, right?

But: Earth to Mumps. Every time you “add data easily” to a Mumps variable you are creating a new thing without questioning its need to exist in the first place, without documenting it, and without doing due diligence to see if you are not in the malign sense reinventing a wheel. It seems altogether too easy to create multiple “record types” which contain similar data, and this increases sharply the possibility of unknown differences…in life-critical missions.

Precisely because of this false freedom, each Mumps variable is potentially a new data type unaccompanied by any ability to make assertions about the state of the data type, and together with the inability of the compiler to detect bugs based on the real data type of strings, this is again a disaster waiting to occur, which has already occurred, in life critical applications.

“Another use of M in more recent times has been to create object databases.. By "flattening" objects into a string representation, like XML, M systems can be used to store objects. An M program then converts back and forth between the "real" objects and the string representations under it, and is able to do so much faster than similar object-relational mapping systems running over relational databases. This should be expected, if M can be used to make a SQL that's faster than SQL, making an object database that does't require conversion to and from SQL in the middle is bound to be even faster.”

This is a common lie: that “my” proprietary system does do objects. The lie is easily made because at the level of computing concepts (one level above syntax, the level that is formed by the intersection of our notions in a computing community), everything is an object.

In a sense, a string that is interpreted explicitly by a computing community of cardinality n>0 or ideally n>1, where n is the number of human minds in this community as an object, even if they do not use the English received terminology of classes and of objects, “is” an object. But this is the weakest possible precondition for a language being object-oriented. Real object-based systems are genuinely powerful, and more safe because the syntax has a better fit with the shared concept. Mumps’ syntax has nothing to do with objects and was developed when object design was in its infancy and restricted to the Fortran-like language Simula.

The above paragraph also expresses a mindset unable, in a life-critical mission, is unable to use any metric for quality other than “efficiency”, viz., wrong (or unknown to be correct) answers at high speed.

“In the traditional relational model”

Here, profit-driven software writing creates a false binary opposition between “traditional” versus oh, so very cutting edge.

This is unconscionable. The hierarchical model of data was thought by Codasyl (an outdated standards group) in 1968 to be the “best”, because in the relatively static corporation of that era, lines of control followed a hierarchical pattern: the org chart was mathematically a tree and not a graph, officially. C. J. Date et al. then discovered circa 1976 that the problem with the hierarchical model was that it cannot survive rapid organizational change, which in American business began with the Arab-Israeli war of 1973 and its oil shocks and which continues today.

Newer organizations have real org charts that are graphs and not trees owing for example to the need for feedback between levels (creating a loop) and for informal lines of communications and control. The relational model is a better fit with this situation because the relational model is agnostic about the nature of the org chart.

The relational model of 1976 and today was proven to be independent of any one implementation and unlike the Codasyl model could reverse hierarchical relations (for example, between product and customer on an invoice).

The key is that the same syntactical form is used for expressing “products” within “customer” and vice-versa, no matter whether the customer lists the products physically or vice-versa. Whereas the commitment of Mumps to a primitive bTree representation, a commitment that is evident in the enthusiasm with which the article mentions these representations, means that different syntax has to be used in a complex way when the relationship changes.

The relational model isn’t traditional. It postdates the b-tree hierarchical model and is more powerful, more expressive, and less dependent on implementation technology. A relational model can be implemented with tape sequential files, on up to modern disks: it simply does not change as a notation.

To call relational “traditional” is unconscionable and a fraudulent commercial promotion and this has no place in Wikipedia.
“In this example any row in ADDRESSES is "for" a particular row in PEOPLE. SQL does not understand the concept of "ownership" however, and requires the user to collect this information back up. SQL supports this through procedure, using the concept of a foreign key; copying some unique bit of data found in the PEOPLE table into the ADDRESS table.”
“To re-create a single "real" record for the address book, the user must instruct the database to collect up the row in PEOPLE they are interested in, extract the key, and then search the ADDRESSES and PHONE_NUMBERS tables for all the rows containing this key.”

SQL, of course, is not constrained to work in the way the least imaginative programmer thinks it works. And again, what does it mean to “collect up”? Dijkstra, a voice in the wilderness, knew that bad style means bad code, bad thought and in some cases low ethical standards; when will other “professionals” learn the ruggedness of truth expressed in good style, with as many words as needed?

SQL as based on the Codd and Date relational paradigm doesn’t “understand” the concept of ownership and this is a good thing. The concept of ownership is part of the outdated Codasyl model in which the Customer Services Manager reports to the Product Manager in the actual org chart, and in consequence, in the “hierarchical” model, the MIS people force the data base user to access the products by customer…or, vice versa. Whereas the same syntactical form is used for product access in SQL no matter how the data is organized.

The second paragraph is a lie. The SQL user constructs the Join operation without specifying how the operation is to be carried out. Then, in a way completely independent of SQL externals, the database finds the information. In 90% of cases, the Join is on primary key and the records are internally in order by this key, meaning that (again) a three-way merge occurs in linear time.

“In order to improve performance, the database administrator will place an index on heavily-searched columns, in this example the person_id columns.”

Nonsense, nonsense, nonsense. In the case of the primary key, no index is needed because the records, in most internal designs, which are independent of the relational paradigm, the records are physically in order by primary key. Modern relational data bases automatically index on other keys. Only by exception is the DBA charged with having to create “indexes”. Oracle and SQL Server alike provide 90% of the needed indexes with no intervention by a DBA.

“This provides another advantage over the relational model, as empty cells do not take up room as they do in the fixed-length relational table.”

Again. Again. AGAIN. The relational model is silent on implementation; the relational model’s strength is that it is agnostic on implementation. Some data bases may in current releases store sparse data by representing empty cells by long strings of blanks or nulls.

There may e a difference between clinical data processing and business data processing using Oracle and SQL Server. Perhaps as the authors of this turkey of a Wikipedia article claim, clinicians “need” sparse data because in clinical trials and medicine, perhaps data is not always available; patient has no name and is in a coma.

But, any db programmer worth his hire knows that invisible solutions exist to the problem of sparse data. Let’s say that ordinarily records, and within records, fields are accessed by calculating offsets. Simply add (independent of the relational model) a new type for storing data in which a prefix provides the offsets, and the prefix is accessed by essentially the same calculation!

The authors of this turkey don’t seem to understand that the genius of the relational model is that it is provably complete in a mathematical sense and for this reason can be silent on implementation details, such as the above. This is what I mean by the way in which profit-seeking in software, which is what is going on at MGH and the VA, destroys the ability to think.

Mere coders seek Euclidean paths to “fast” results because reification and moronization mean they think that the space in which they merely code is Newtonian. They create iatrogenic problems at warp speed because almost as a condition of employment, they are unable to see that “the end user” is not a disinterested actor. The end user may approve an array bounded to 32K while being ignorant of a merger which breaks this limit because the space in which both the end users and the mere coders exist is in fact curved by the fact that the actual conditions, in which the actual organization does business, are those of globalized capitalism.

“The results, published in the journal M Computing provide support for the claim by M afficionados that M is a highly cost effective application programming tool.”:

Excuse me, but what other “results” would have been published by a sponsored journal called “M Computing”? Excuse me, what is an “afficionado”? A bullfighter, or just a meaningless word in which the length of the working day and the brutalization of white collar work causes “afficionados” to love their own victimization and become damaged “afficionados” of a damaged tool? While the patients at MGH and the VA can rot in waiting rooms?

“Data types: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires. Like Visual BASIC "variant" type.”

FYI, the Variant in VB caused bugs and was dropped as of VB.Net.

It is true that in a sense the VB Variant was “powerful”. It could in fact contain a VB “collection” which like an M array could be accessed by strings as well as numbers, and the collection could contain collections, which seemed to “empower” you to build trees.

The problem was that if you did so without careful documentation and without writing a self-inspect routine to make sure that the resulting complex data structure conformed to assertions, the resulting code was unmaintainable.

Furthermore, a significant exposure with the Variant was that since it stored not the collection itself, but a reference to the collection, at any time the “tree” could (intentionally or unintentionally) become a general mathematical graph, and any traversal (unless coded with special checks) could become an infinite loop. A data structure that causes code to loop is a computer virus.

Now, I don’t know if Mumps stores references or the string form of objects in nodes, but of course, this is one more deficiency in this article. The author doesn’t say, may not know, and worse, the myriad of implementations may differ on this point.

“Booleans: In IF statements and other conditionals, any nonzero value is treated as True.”

Gee, what happens when either a or b is a string? Just asking. And you do error trapping how?

“Declarations: NONE. Everything dynamically created on first reference.”

Mother of Mercy.

Script kiddiedom.

Bugs waiting to happen.

In life-critical applications.

Words fail.

VBA (Visual Basic for Applications) was announced without the need to declare variables. It rapidly became a complete joke for developing Web pages and was abandoned, even by Visual Basic programmers of the stronger-typed compiler VB, in favor of Javascript and Java.

“No declarations” is criminal malpractice.

“Lines: important syntactic entities. Multiple statements per line are idiomatic. Scope of IF and FOR is "remainder of current line."

This was hot stuff, along with Balenciaga and the miniskirt, in 1968. Today it is nonsense.

“Local arrays: names not beginning with caret; stored in process space; private to your process; expire when process terminates; available storage depends on partition size but is typically small (32K)”: the 32K size limit is an artifact again of 1968. It is against this nonsense that the students of Paris raged in the streets and they were right: the one-dimensional life promised them by arrogant and limited mainframe computers. Gee, what happens when the clinical trial, the mission-critical clinical trial, exceeds 32K? And Mumps handles errors how?

“Very large globals (hundreds of megabytes)”: in terms of modern data bases this is quite small. You’re asking for trouble in the many clinical studies which track people through their lifetimes.

“Indirection: in many contexts, @VBL can be used and effectively substitutes the contents of VBL into the statement. SET XYZ="ABC" SET @XYZ=123 sets the variable ABC to 123. SET SUBROU="REPORT" DO @SUBROU performs the subroutine named REPORT. Operational equivalent of "pointers" in other languages.”: how? By reference? By value? By name? It seems to be textual, a by name macro substitution. So what happens when the variable contains a new level of at-sign indirection? Does this wiki author know? Does he care? Are the many profit-driven implementations of Mumps even consistent?

“Operators: No precedence, executed left to right, parenthesize as desired. 2+3*10 yields 50.”: oh great. APL, which in Dijkstra’s words created “coding bums”, lives on.

“ $GET(variable) tests value of variable, and if not defined, returns empty string”: and if variable contains an empty string???

“$ASCII, $CHAR text-to-ASCII-code and inverse”: so much for Unicode. No wonder they hate us, when we mindlessly recommend computer systems that force even data entry clerks to know English and are cultural imperialism.

“Some of the contention arose in response to strong advocacy for the name M on the part of one particular commercial interest, InterSystems, whose CEO disliked the name MUMPS and felt that it represented a serious marketing obstacle for InterSystems.”: this indicates what the health-industrial complex cares about. Not patient care. Not software quality. Instead, a marketing opportunity. Mumps deserves the name of a disease which in modern medicine is out of date for at least the upper-middle and health-insured segment in America.

“Relationships between MUMPS, Caché, MIIS, MAGIC, InterSystems and Meditech”

OK, let me sum up here. These relationships are a fascinating study in the capture of health care by the health-industrial complex which is extracting fat programmer salaries for fat and uncultured programmers, and huge profits for the companies involved, by the systematic and with malice aforethought victimization of the least well off in our society.

I have shown that Mumps is antiquated technology and no matter how blindingly fast it is at given wrong dosages, wrong patient temperatures, wrong blood gas ratios, wrong diagnoses of schizophrenia in place of manic-depression, to overworked nurses and stressed-out doctors, it is irresponsible for a professional computer scientist to recommend this turkey, and it is irresponsible for Wikipedia to carry this article.

I’d nuke the entire article but unlike some of the real thugs who invest the health-industrial complex I don’t suppress information, as some of the thugs do when clinical trials don’t go as planned. As it is I’m going to mark it.

In the New York Times for October 20th, Robert Pears writes “U.S. Gives Florida a Sweeping Right to Curb Medicaid”; as a favor to the President’s brother, Florida can now limit poor patients on Medicaid to a specific cash limit. This creates and affirms a class divide in American society where, according to agreed upon figures, 20% of us have gotten obscenely rich in the yacht sense, including many software “inventors”, while 80% of us, including many programmers too sick at heart to make money from outdated software, can no longer afford health care and are without coverage.

As a programmer, to get access to health care, you have to agree that some turkey like this is the answer to a maiden’s prayer. You have to sell your soul to weak typing and self-moronize.

The contrast affirmed by the Florida ruling is brutal and almost unprecedented in the developed world which the US claims to lead: in which, the US claims to be the model society. It means that only the 20% can through defined benefit and defined contribution plans save their lives and those of their children, while the rest of us (not just the feared and despised underclass) will rot in waiting rooms with screaming children.

They will rot in waiting rooms while programmers, protected perhaps by health plans which they obtain by holding their employers hostage to outdated systems, scratch their heads over Mumps and yammer about an “efficiency” which has no relation to human needs.

In the New York Times for October 18th, Richard Perez-Pena writes “At Clinic, Hurdles to Clear Before Medicaid Care”. These hurdles are manufactured by out of control computer systems that are not understood by the people who in the deliberately vague sense of the word, “support” them. Poor people receive from these systems verbiage deliberately designed to be not understood and when the verbiage says in effect that they must re-register for coverage, it is not understood.

The purpose of the complications in New York, studied in the article, seem inescapably to be quantitative and not qualitative: nobody apart from the geeks really cares if the system does not work: the point appears to be that the system is a useful tool for dropping patients from the rolls. The system is operated for an upper middle class and an elite with defined benefit plans that are only a memory, now, for many General Motors retirees to control the underclass, and the software to do this must in the logic of the system be as messy and legacy as possible!

The Department of Veteran’s Affairs (the current name of the VA) now makes real military veterans, who have bled for their country, wait five years or more for needed procedures. How much waste is created at the VA by standardization around a system built for a 1966 minicomputer that was a joke even by the standards of the PDP-8?

My grown son was recently billed about 5000.00 for a serious accident, a bill he is unable to pay, and owing to the deliberate rent-seeking of the three separate agencies (the doctors, the hospital, and the radiologist), the total is indeterminate: the slop of the software infects the bill.

Whereas in Hong Kong where I live, all emergency room visits are for legal residents, 100.00, and that’s Hong Kong money (about 13.00 US). The doctors and the radiologists work for a living and are obedient staff members of the hospital. They do not dream of wealth as do American doctors, only of being valued members of a community, respected in the Confucian tradition for their skills.

The “Harry and Louise” articles put out in 1994 to defeat the Hilary Clinton health plan by the health-industrial complex spoke of “choice”, and the message is that a national health will harm competition. We have to fork over the bucks to Mumps programmers for their hard work in showing up at 11 AM to limit arrays to 32K, and to health companies for finding ways to deny India the ability to manufacture a generic vaccine or cure for bird flu.

We’re told what we want by “Harry and Louise”; we’re told what we don’t want: we sit in front of the TV (after a day of wrestling with something like Mumps) and they tell us, over and over again, who we are, proud not to be Chinese coolies or living in an intrusive welfare state. It takes Chomsky to repeat the truth for as much as is needed:

“As in the past, large majorities favor national health insurance, most regarding it as a ‘moral issue’”. Eighty percent [a number that happens to coincide precisely with the ‘losers’] regard universal health care as more important than ‘holding down taxes’…but if these questions arise at all, the proposals are held to be ‘politically impossible’, because of ‘tangled politics’”. (Noam Chomsky, Doctrines and Visions, 2003).

The software creates in fact the same sort of mental confusion as is seen at the political level.

Hong Kong happens to be an “Asian tiger” which grew from a devastated city in 1945 to a thriving metropolis today. It survived SARS with less than 100 deaths and the Chinese handover. It has no minimum wage or unemployment compensation, but its colonial administrators, and the Chinese population, did choose to make K-12 education and health care a free good, outside the savagery of the free market.

A line of great beauty was drawn around the sick and the children. In America, we force hospitals to use languages for script kiddies and Security ejects the sick, and “los madres, et su hijos”.

One of the reasons why Hong Kong is competitive may be that its programmers don’t have to wrestle with a system which was made, deliberately, proprietary so as to assure the incomes of its compiler developers and the bonuses of the private companies exploiting Mumps. No effort is needed to ensure that clinical trials and medical practice makes money, because the model of care is simple and open to all.

Imbalances in Hong Kong, such as they are, can be corrected by soaking the megarich, who are happy to pay a government so otherwise devoted to their needs since the 1840s.

I have long suspected that there is a deep and hidden connection, in America, between crap code and crap “programming languages”, and fear and greed, and for me this is the purest example yet. The fact is that while I don’t want to make Larry or Bill any richer, it appears to me that given the wildly excessive ways in which Mumps encapsulates the mistakes and limitations of the PDP-7 (which was almost immediately outdated by the PDP-8), each and every Mumps installation should be replaced by Oracle or SQL Server.

Edsger Dijkstra back in the 1970s prophesied that organizations might collapse owing to the simple unmastered complexity of their data systems. September 11, which happened although “the system was blinking red” in the words of the official report, a system which included vast amounts of legacy software, may have been the beginning of this collapse in an America in which owing to panic about the End, the poor and sick represent an opportunity for exploitation, by programmers on up.

It looks from the Florida situation that the plan is to keep on using out of date code and through that code to keep exploiting the poor, the sick, et los madres et su hijos, and the mothers, and their sons.

Edward G. Nilges 10-21-2005 Lamma Island, Hong Kong

Revised (minor edits) 10-27-2005


Source URL:
http://www.developerdotstar.com/community/community/node/279