Talk:MUMPS/Archive01

DO NOT EDIT OR POST REPLIES TO THIS PAGE. THIS PAGE IS AN ARCHIVE.

Please note that some editors have chosen not to follow the conventions for WP talk pages, and, as a result, large chunks of htis page are essentially incoherent.

Critical comments re MUMPS and the NPOVness of this article

Sorry, I thought the discussion was about MUMPS, about which I am exquisitely familiar. I couldn't help myself and started tiding up the article - unaware of all this energy. An interesting aspect of the wiki process, I guess. I did not mean to step into a war, by making my changes. I would be happy to discuss MUMPS and FileManager and VistA with anyone who is interested in listening. --Kirt 12:53, 5 April 2006 (UTC)

This article is simply outrageous! How can this possibly be considered NPOV??? The only reason I don't get in and simply delete vast tranches of this advertorial bullshit is because there's plainly already a flame-war going on here. EmmetCaulfield 01:18, 21 December 2005 (UTC)

Spinoza1111 05:17, 22 November 2005 (UTC)(Edward G. Nilges)

[Additional note inserted, please go to to http://www.developerdotstar.com/community/node/279 for more information on this issue. I wanted to alert wikipedians to another man's comments on Mumps.

HATS OFF to long-suffering real MUMPS programmer Steven Zeck for blowing the lid off this turkey of a language; the situation is as I thought, if not worse: MUMPS encapsulates the WORST programming praxis of the Summer of Love, 1968.

That was my opinion, of course. But if what Mr. Zeck says is true, MUMPS alone explains the mistreatment of military veterans including long waits for care.

Again, I see where the REAL programmer, including the programmer who has to maintain all the pretentious dreck, speaks for the proletariat and deconstructs the illusions created by noncoding management and arrogant "developers" who can't maintain code.

Sorry, I'm off again. But I am serious. If what Mr. Zeck says is true, this is Congressional Committee stuff.

If Mr. Zeck is wrong, then point it out and be bold. But be aware that in the absence of a universal standard (universal in the sense of one compiler) your "ideal" MUMPS may not be the real disease.

Spinoza1111 12:00, 29 October 2005 (UTC)I will put further discussion in my blog at http://www.developerdotstar.com/community/node/279 to avoid further clutter to this discussion page.

All discussants are invited to come on over, and comment at this site. Unfortunately I cannot provide free beer and snacks. I would if I could.

Spinoza1111 11:04, 25 October 2005 (UTC)I understand, Mr. MacKenzie, that you were not advocating when you stated that Mumps variables are like Visual Basic Variants, on which the compiler can impose no type constraints. My objections are that phrases like "best-kept secret" and praising Mumps detracts from NPOV and in making my case I have to show from outside Mumps that it is probably out of date with respect to the discovery, not by companies or by programmers, but by tenured faculty in compsci that in computing, weak typing is a bad idea.

Dear Edward,

Please stop splitting apart my comments.

It is clear to me that you do not intend to make even the simplest effort at following Wikipedia conventions, particularly in regards to talk page messages. Your "flat earth" criticisms of the MUMPS article (and subsequent mangling of it) are absurd. You have justified your ridiculous position by implying that MUMPS (the programming language and database) is responsible for financial cutbacks at federal VAs. You have proposed that our tax dollars should be wasted instead on a inherently-inferior technology (that does not have specific applications written for the purpose) that would cost thousands of times more than the current implementation. As a military veteran and a taxpayer, I certainly do not want to see the complete collapse of the federal VA program. Following your absurd suggestions, the federal VA would collapse, due to political pork-barrel knee jerk conversion to hundreds of as-yet unwritten applications written on top of Oracle. None of your criticisms have chosen an appropriate target. None of your arguments even hold water.

Spinoza1111 13:00, 28 October 2005 (UTC)(Edward G. Nilges in reply to above two paragraphs)

On the contrary, I have gone out of my way, Mr. MacKenzie, to format the responses clearly. This is a free-form discussion page and I fear you are confusing personal standards and personal expectations with Wikipedia standards.

Unfortunately I see the same narcissism in the above defense of the continued use of MUMPS.

Your defense is here the existing applications written on top of MUMPS. I am not proposing a mass rewrite. You'll recall that my objection was to the non-NPOV of the article which excessively and in my opinion fraudulently promoted MUMPS. To establish this thesis I had to show from outside MUMPS why MUMPS might NOT be "the best kept secret in the IT industry".

To show non NPOV I do have to show how MUMPS may be one of those second-generation application that encapsulates older views that have been shown deficient such as the view that tree structure is the best way to represent data as opposed to tuples and sets of same.

I would certainly like to see eleemosynary public institutions like MGH and the VA emigrate from MUMPS. At the same time, I believe (as a citizen and a taxpayer) that this should ONLY be done in a sharply different POLITICAL context in which the goal of the rewrite would be the overthrow of the health-industrial context and a redefinition of health care as a human right as it is defined by the United Nations.

This would indeed mean a great deal of work and expense, I agree. However, today I see how the work and expense has been factored into exhausting projects on the part of poor and of veterans to acquire medical and personal records and to meet hard and fast deadlines for filing in order to access care, deadlines imposed in part by the structure of second-generation data bases.

These deadlines which deny care are a direct violation of a human right to care.

Furthermore, I see corporations, all the time, radically revising reporting systems for global profit opportunities and indeed bragging, as did Lou Gerstner of IBM, that they have "taught elephants how to dance". I think this spirit also belongs in organizations set up to serve not for profit human needs.

Furthermore, you may be ignoring the ability to simulate the MUMPS interface at a suitable level while avoiding its built-in limitations. In reengineering we are often told how the syntax of the legacy interface must not be violated only to find that by adding a layer we can indeed adapt the old syntax to new requirements.

In other words, the inflexibility is in our hearts and minds, and in the unwillingness of public organizations to serve their original constituents.

Spinoza1111 13:00, 28 October 2005 (UTC)(Edward G. Nilges ends his reply)

--Connel MacKenzie 15:11, 26 October 2005 (UTC)

Spinoza1111 11:04, 25 October 2005 (UTC)I also realize that my phrase "tenured faculty" is an unfamiliar appeal to authority in applied computing, whose practitioners tend to regard computer science as a sequence of fads. The problem here is that applied science needs a basis other than the opinions of people who may be too close to MUMPS to be objective or to write, without rebuke, an article about it.

As of 10-24-2005, Mr. Connel MacKenzie wrote the indented and my replies are not indented, down to the line with Mr. MacKenzie's name. This is followed by my original objection.

Spinoza1111 13:25, 23 October 2005 (UTC)(Edward G. Nilges): in light of the exchange below, I will attempt to tune the article with respect to RDB. I have downloaded a free Mumps to help a client and must perforce drink some of the Kool-Ade. I hope I don't end up howling at the moon, but I will need to learn some more about Mumps to tune the article, a fact which won't change my opinion overall about the use of weak type languages in life-critical situations.

Dear sir, please stop adding comments to the top of the talk page. As you add subjects of discussion, use the [+] button above to add topics to the end of the list.

Spinoza1111 12:47, 24 October 2005 (UTC)(Edward G. Nilges) This seems to be a matter of taste given that the gui does not enforce it. Can you refer me to a practice manual?

I have relabeled this section to be not about me. This section is based on my critique and it seems to me to make sense to add newer comments first for quick review. But if I am violating a documented rule, my apologies, I will fix next time I visit, and seek for grace hereafter, like Caliban.

Also, please keep in mind that you seem to have some pretty massive misunderstanding of just what is being used as a database by the VA. DHCP, AKA VA FileMan is the database (written in MUMPS) that provides all the data typing you decry as absent. This article is about MUMPS, the underlying langugage and database structure.

Spinoza1111 12:47, 24 October 2005 (UTC)(Edward G. Nilges) I rather doubt that FileMan avoids common mistakes. But OK, what is an integer in this superstructure? Is it 32 bits? 64? How about a floating point number? IEEE compliant or its own rules? Maximum string length?

You may be able to give sensible answers. But one problem is that the questions have to be asked from outside a knowledge community which is restricted to the Department of Veteran's Affairs.

Don't think of me as a Mumps expert (I know there is little chance of that). The problem I see with "expertise" is that expertise is constituted in the knowledge of constructed and administered facts themselves susceptible to manipulation at will, with the result (cf Chomsky) that the expert as insider constructs a cozy world in which to flourish. The problem I see today is in final service to real stakeholders such as FBI agents and veterans, therefore consider me as being like a particularly nasty, Al Sharpton-like Congressman getting into your face at a hearing. My experience in other areas of software has shown me that there is a computer science which can serve as a basis for speaking truth to power and interrogating what goes on in our daily lives.

Maybe in working with Mumps, I will either "drink the Koolade" or discover after all that it is the "best kept secret" the article says it is. In either case I shall come back here and retract everything. If I act strange, it is because I drank the Koolade: if I act normal, that will be a first for me :-). You get the idea.

Furthremore, you seem to have some poisonously POV agenda in touting Oracle as the only viable Answer To Everything in your rant. The inflexibility of Oracle is well known in the healthcare industry. As is stated clearly below, your characterization of commercial promotion seems wildly misplaced. As for the banking industry and the legal industry, (fields I've been asked to use MUMPS in) your pointed misrepresentations seem to be completely unfounded.

Spinoza1111 12:47, 24 October 2005 (UTC)(Edward G. Nilges) Here is an elementary confusion. First of all, I have no special brief for Oracle per se. As a taxpayer, I would have preferred even SQL Server to legacy arcana. The key is in fact use of an RDB with a strongly typed language all the way down, not as a paint job.

But far more seriously, you are confusing the need for NPOV in a Wikipedia article with a demand that its users and its posters themselves be *tabula rasa*, with no opinions of any vigor of their own.

You bet your sweet patootie, assuming you have one, that I have a POV about Oracle, versus SQL Server, versus the claptrap at the Department of Veteran's Affairs which is ill-serving miitary veterans, as far as I can tell, as we speak and write. I think and more important I know that Oracle postdates the most important event in the history of software for file management, the rdb paradigm, and this isn't opinion it is scientific fact.

The most important event in the history of software for file managment was the rdb paridigm. Oracle postdates this event. Therefore what? Would it be possible for you to clarify your point here so that I can follow it please? 80N 15:20, 25 October 2005 (UTC)

And, as I have said, I don't "rant". Instead I have a POV and committment to the NPOV of texts. I am a taxpayer with a brother who is a military veteran and I am reading horror stories about longer and longer waits, by vets, for nonelective care, and I know for a fact that Mumps is in use. I conclude based on my knowledge of typeless versus strongly typed language that one major reason for the abuse of veterans is the use of an experimental language for script kiddies.

Part of the problem is that so many so-called professionals drink the Kool Ade and abandon their critical spirit when in fact their employer forces them to use a legacy system.

--Connel MacKenzie 14:54, 23 October 2005 (UTC)

Spinoza1111 12:57, 21 October 2005 (UTC)(Edward G. Nilges). I'm sorry, this is a bad Wikipedia article. It is non-NPOV and in fact an inappropriate and apparently commercial promotion of Mumps. The author does not know relational data base theory and as such is unqualified to compare Mumps to RDBs.

Please see http://www.developerdotstar.com/community/node/279 for my complete comments.

• I don't see the entire article as "bad." I happen to agree with you that it contains some MUMPS "advocacy." Your use of the word "commercial" seems unlikely since as far as I know there are currently no commercial vendors providing MUMPS under that name. The only significant commercial player, InterSystems, actually tries to conceal the identity of the technology underlying their product, named Caché. By all means tune the language in the portions of article that discuss MUMPS-vs-RDB, being careful not to go too far in the other direction. I had nothing to do with those portions of the article so I am personally not very emotionally involved in them.

P. S. The article, like all Wikipedia articles, has no "author." Dpbsmith (talk) 13:31, 21 October 2005 (UTC)

P. P. S. On second thought, on reading the rant at the link you posted above, I have to wonder how neutral you are, or whether you know about about MUMPS to be qualified to write about it. (For starters, the name of the language is spelled in all caps...) Dpbsmith (talk) 13:37, 21 October 2005 (UTC)

203.198.23.99 01:50, 22 October 2005 (UTC)(Edward G. Nilges)Your objection to the blogpost, that the name of the language is spelled all caps (of which I was aware) is an example of how a false and clerkish "expertise" in the trivial, coupled with disregard of the important, creates "experts" who in fact construct health-industrial as well as military-industrial complexes.

What is claimed is that one has to be a MUMPS insider to critique: but the paradox is, that once one has programmed sufficiently in Mumps, one has drank the Kool Ade of a false "expertise" and burned out critical circuitry: one has wasted so much time on a "learning" of a second-hand administrative "reality" that one's ability to stand (on a sensible computer science platform) has been destroyed.

Expertise in fact becomes only expertise at reproducing a material existence that is based on being able to work around silly limits.

The essay is not a "rant". Instead I believe that the intellectual content of computer science is sufficiently thin to allow it to be both mastered and used in a forensic context to identify systematic misfeasance at the Department of Veteran's Affairs which helps to explain why the REAL end users of this system, military veterans, are systematically screwed.

Spinoza1111 11:09, 22 October 2005 (UTC)(Edward G. Nilges)As to there being no commercial versions of MUMPS: this is correct for the very good reason that MUMPS is available for free, therefore no market in MUMPS compilers or interpreters can exist. However, the article does in fact do a good job in demonstrating that there is a large aftermarket in MUMPS "support", and it is my belief that this aftermarket depends on a flawed language, and puts its interests before that of doctors and patients.

Maybe patients are being poorly served by the VA, but I suspect this has much more to do with government policy than with the choice of programming language used to develop the applications which serve them.

Spinoza1111 13:16, 23 October 2005 (UTC)(Edward G. Nilges)The policy is self-reflexive and necessarily set by the apparatus including the known difficulty of supporting computer systems. The known difficulty, reflected for the senior executive service official in the high salaries of the MIS people, causes policy changes to be foreclosed, as in the case where FBI agent Coleen Rowley reported to Congress in 2002 that her field office could not search for terrorist information in data bases using Boolean queries.

The policy isn't fully determined, of course, by the technology. It is also determined by right-wing savagery in which military veterans up to and including John McCain are scapegoated for our policies of destabilizing other countries and for doing our dirty work.

However, the technical apparatus DOES reflect how self-interest and the lack of a service ethic drive choices including the choice to continue use of Mumps using only the metric of "speed".

MIS becomes in other words a convenient excuse for not serving the original constituents of an organization because the truth about any one case has become buried in an arcane and out of date data base.

This reinforces a tendency common to both major political parties in recent years: for members of the American *nomenklatura*, whether "liberal" or conservative, to take over public service organizations and run them in a self-serving fashion, gradually breaking off chunks to return those chunks, and constituents who depend on them, to the "free market".

A major, if hidden, way in which this was done was the replacement of low level clerical and manual operations by a "computerization" assumed more efficient...which in perhaps 80% of cases was late, buggy, and soon enough so legacy that overpaid specialists were the only ones able to maintain the system.

Have you noticed how members of the toplevel are in general proud of technical aliteracy and have different technical objectives? For example, the President's father expressed astonishment at something so mundane as a supermarket scanner, and Henry Kissinger has gone on record as saying that to him, the value of Xerography is that your secretary can falsify the record.

To them, the issue with Mumps is ONLY the pay scales of the aging Mumps experts. No matter their levels of intelligence, there is simply no way to properly explain to one of these clowns the rather simple point that in other industries, the availability of a security measure comparable to compile-time checking of data types implies legally actionable unconscionability when a civil or mechanical engineer does not use the comparable facility.

MIS people have in other words conspired with the senior executive types to carve out an opaque legal regime in which the former can disport themselves, using Fun languages like Mumps which produce the pleasant buzz of a false expertise.

This is not some wacked out conspiracy theory. Lawrence Lessig has shown that in the small, but with critical effect on people, code is law. I acknowledge that the drafters of laws in the current Congress are almost as bad legal craftsmen as many programmers suck in their way; the actual text, for example, of the Patriot act consists not of clear law but of almost unreadable alterations, reading like a diff file, to existing laws.

But this means that MIS and the Congresscritters are both engaged in the same project, which is making life very difficult for ordinary military veterans and other Americans in the name of their cozy sinecures. Doesn't it.

I don't think I've drunk very much MUMPS Kool-ade, having worked with it only in 1991 and 1992. I've actually spent more time working in Smalltalk. The bulk of my career has been working on C++, C, FORTRAN, and assembly language.

Spinoza1111 13:16, 23 October 2005 (UTC)(Edward G. Nilges) OK, point taken. Nonetheless, some languages in my experience can be fast-acting and addictive. Rexx and Visual Basic did a number on me from which I have to recover by reading Stroustrup. Hero computer scientist Edsger Wybe of blessed memory was quite definite on this point: I am of necessity not quite as extreme, but there is a learning which degrades.

Do you mean Edsger Dijkstra? I assume you're referring to his essay How do we tell truths that might hurt? Dpbsmith (talk) 13:48, 28 October 2005 (UTC)

I think some portions of the article are overly promotional. That's an issue with some other computer language articles in Wikipedia, and it comes with the Wikipedian territory.

Spinoza1111 13:16, 23 October 2005 (UTC)(Edward G. Nilges) Excuse me, it is my impression that NPOV is important. If wikipedia becomes some sort of sleazy set of ads, I will ignore it and go back to the Britannica or the Great Soviet Encyclopedia.

The capsule description (which IS mine) is not intended to be language advocacy, although you seem to be reading it as such. As it says, it is a capsule description, and leaves many details unexplained. The language has a full, formal ISO/ANSI description. To say that "Data types: one universal datatype, interpreted/converted to string, integer, or floating-point number as context requires. Like Visual BASIC "variant" type" is just an attempt to convey something quickly and by reference to something familiar. It's not as general as Smalltalk, in which everything, including integers are objects which can be subclassed. It's not a strongly typed language. It's roughly comparable to a VB "variant:" polymorphic from a small set of predefined types. The article doesn't say whether that's a good thing or a bad thing; that's a matter of opinion (and incidentally a matter of fashion, the fashion having undergone a number of changes in the last few decades).

Spinoza1111 13:16, 23 October 2005 (UTC)(Edward G. Nilges): science, including computer science, shouldn't be a matter of fashions and hemlines. We need progress in the direction of the compiler and system giving minimal preconditions for valid code and if the language has types, this is much easier to provide.

In VB, at least, you had strong types in addition to the variant. It is true that in most OO languages, you can declare a pure object and mess around with it. The problem in Mumps, and for that matter in Rexx, was that you could go no further in developing built in reliability, and Mumps as opposed to Rexx is used in life-critical situations.

It appears to me that in Mumps, type checking is not available. I will be relieved if I am wrong!

As for the name: MUMPS was created in an era when it was common for computer languages to have light-hearted names. It is an area in which the M[UMPS] community may be hypersensitive; InterSystems certainly is. Spelling it in all-caps shows that it is an acronym. I perceived its misspelling as "Mumps" as being an attempt to emphasize its similarity the name of the viral disease, and hence to be an attack on the language, but perhaps that was a misperception on my part .Dpbsmith (talk) 11:53, 22 October 2005 (UTC)

Spinoza1111 13:16, 23 October 2005 (UTC)(Edward G. Nilges)In the case of Jovial, these light-hearted names were a major embarassment to their developers: Jules Schwartz, who developed a subset of Algol for Rand and the American aerospace community, regretted the name, based on Jules' Own Version of the International Algebraic Language.

However, I don't have a problem with the name. The problem I see is that a CEO focused merely on the name, and this to me indicates the inappropriate foregrounding of a health-industrial marketing push when Mumps should have been replaced by Oracle by 1990 in life-critical applications.

Just wanted to interject that MUMPS met FIPS standards. FIPS is missing from the introduction I believe, but I do not know it's historical status to add this -- yet. --Bammon 03:48, 23 April 2006 (UTC)

Below are older comments from other folks.

Older talk page comments

I don't know if it was historically true in the past, but modern relational databases do not waste vast amounts of empty space (blank string data is compressed, no matter how big you state the varchar or char to be).

Dear 66.92.72.247, do you know enough about Caché "BigString" (handling of strings over 2K) to describe its compression of them? I've never cared to investigate, as it is a completely transparent internal DB function. --Connel MacKenzie 10:47, Dec 30, 2004 (UTC)

Am finding the opening statement(s) contradictory, first saying M is dedicated to databases, then ending with databases being a side-effect. Anyone agree? --Bammon 14:50, Jun 05, 2005 (EST)

The introduction has been rewritten and the contradiction gone. The opening statement is accurate but is awkward English wise. Much better than before though. --Bammon 23:14, Sep 02, 2005 (EST)

• I've never seen the M database described as a side effect of the language anywhere. No way is it a side effect - it is the whole raison d'etre of the language. 80N 20:59, Jun 6, 2005 (UTC)
  • It's not my sentence, but I think I see what whoever wrote it was trying to get at. I think it's specifically a contrast with SQL. One could have a relational database without SQL, and access it via some kind of API. SQL is layered on top of the database. MUMPS has a sort of bottom-up flavor to it. It is a language with a lot of efficiently-implemented primitives. Once you get the hang of it you can easily marshall those primitives to perform database-like data manipulation tasks. There isn't really any _database_ there, there are just those humongous string-indexed arrays. It's a construction set for very quickly building databases that are customized to the application. Or something like that. It's probably not a very good introduction to the article. Dpbsmith (talk) 00:56, 7 Jun 2005 (UTC)
  • P. S. I think that historically MUMPS kept adding richer and richer semantics to the same syntax. In particular, I don't think strings were allowed as array indices originally. If I'm right about that, then that's another way in which you can say that the language has some kind of primacy.... Dpbsmith (talk) 00:58, 7 Jun 2005 (UTC)

I agree that you have to look at historical MUMPS to validate whether the database became a side effect (because of relaxed memory requirements, etc.?), but globals subscripted by strings have been around for my lifetime of MUMPS. Just got a CPM version but never got to use it. I think if they talk from a historical standpoint, they may need to term it that way. There is a snapshot of the language in the article which looks 1995ish. From that snapshot we need to talk historically or futuristically or currently. Still my basic argument stands that the opening statement is contradictory, whether well intentioned or not. --Bammon 06:07, Jun 14, 2005 (EST)

Opening statement redone...great job. --Bammon 23:15, Sep 02,2005 (EST)

Correction, article does have a date stamp for language features. Should have a direct hyperlink to online book "Mumps by Example". --Bammon 15:48, Jul 31, 2005 (EST)

Came across a more detailed definition of a MUMPS database as a collection of b-trees additionally suited for sparse structures, but it was more complete. Remind anyone of a definition they have seen and can share? --Bammon 14:50, Jun 05, 2005 (EST)

Correction, article describes a b-tree structure in use. --Bammon 15:49, Jul 31, 2005

A few comments. I learned to program MUMPS-15 in 1974 on the University of Missouri’s home built RIS called MARS (Mo Automated Radiology System). Our DEC PDP-15 with 88 k words of 18 bit core memory and 30 MB of disk storage supported 25+ users with better than 2 second response time even at the busiest time of day. This pre-ANSI MUMPS used M trees and did not allow alpha global subscripts. I understand that later MUMPS products use self optimizing B+ trees completely maintained by the MUMPS system, not by human support. In the 1990 time frame this identical RIS – the only changes being for vendor specific I/O details -supporting 75 users was ported to 3 IBM Model 80’s running Datatree MUMPS. Is MUMPS outdated? At a medium sized hospital whose name I will not mention a recently installed, nationally known Oracle based RIS replacement for a MUMPS RIS is being uninstalled in favor of the previous MUMPS system. --OldMUMPSperson

"Higher level" layer?

I'm not very happy about this recent addition:

To be truly usable, M systems require a "higher level" layer to act as a database manager, and while M was well standardized, there is no such standard for these higher levels, and no governing body, adding to the confusion.

This seems to me to be expressing a reasonable point of view, but a point of view. It seems to assume that all database applications should be programmed in a general-purpose, high-level, highly abstract language that reflects the problem description rather than procedural details.

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.

I mean, it's just like the endless unresolvable religious wars about Java versus C++ versus assembly language.

As for "no standard for these higher levels," does FILEMAN qualify? Well, no, not really, but it's a talking point. Dpbsmith (talk) 16:35, 19 July 2005 (UTC)

History section restructured

Folks, I bit the bullet and had a go at restructuring the History section. I've tried to get all the significant events into near chronlogical order and to be more accurate about the order in which things happened. I also ripped out all the POV stuff and other irrelevant ramblings. I'm fairly happy with the start, but the section about Other Industries is clearly still inadequate. Feel free to add, change, or revert. 21n 00:20, 17 October 2005 (UTC)

Sophisticated techniques to manage caching, buffering...

The first paragram contains the following sentence. The system has very sophisticated techniques to manage caching, buffering, compression and sorting all intrinsic to the language.

While this may be true of *some* implementations it is not a necessary requirement of an implementation, and is certainly not intrinsic to the language. I propose this sentence be removed. Anyone have a proposal for a suitable alternative sentence? 80N 14:37, 17 October 2005 (UTC)

Not my sentence, but...

In a way it sort of is. One of the things about MUMPS is that it is an application language par excellence and comes with a bunch of fairly well-understood assumptions about how it is going to be used in practice and how well certain things need to be implemented in order to be a viable commercial product. This is not necessarily true of other languages. One of my gripes with C++ is that I have found through bad experiences that STL implementations vary enormously in quality and it is dangerous to rely heavily on STL because your program may work fine under one vendor's implementation and not another's. (For example... surprise, surprise... with Microsoft's C++ it is much safer to use the awkward crufty MFC classes for strings, etc. than the supposedly standard STL strings).

One of the things that books and specs don't make clear is just how languages are coupled with expectations of use. There is no law of physics that says FORTRAN is compiled, does floating-point arithmetic efficiently and accurately, and has the capability of linking to assembly-language routines... but it usually is. On paper there's no obvious reason to use FORTRAN in favor of C for numerical work. In practice there is.

With MUMPS you can rest fairly well assured that it is really e.g. "safe" to use huge globals freely. There's little danger of running into "toy" implementations that meet the letter of the language spec but not the spirit. Dpbsmith (talk) 23:16, 18 October 2005 (UTC)

Good points. I'm not disputing the need for a good implementation of MUMPS to have those attributes. I'm more concerned that this sentence implies that they are intrinsic to the language. I'd be happier with All good implementations of MUMPS use sophisticated techniques for managing, caching, buffering, compression and sorting of persistent data. These are normally intrinsic to the implementation and transparent to programmer. (Cache's $SORTBEGIN and $SORTEND functions are good examples of exceptions to this rule). 80N 11:01, 25 October 2005 (UTC)

Spinoza1111 10:40, 25 October 2005 (UTC)(Edward G. Nilges)This comment manages, for me, to be both illuminating and profoundly wrong.

First of all, if in fact MUMPS does large globals well and efficiently, this means that I have to withdraw my objection that MUMPS may not be able to handle data and data structures beyond built-in limits that made sense in 1968.

It is a fact that many implementations of MUMPS do indeed do large globals very well and very efficiently. For example: 2,000 tps on a database of 10 million bank accounts (see http://www.fidelityinfoservices.com/FNFIS/NewsEvents/20041108b.htm and http://www.fidelityinfoservices.com/FNFIS/Markets/IntlBanking/en/CoreBanking/Profile/). 80N 13:13, 25 October 2005 (UTC)

But you're saying that as an empirical language, one can be certain that MUMPS will be able to handle large data bases efficiently and well.

The very first version of VAX/DSM used the native RMS file system as a basis for its implementation of globals. This didn't meet the performance and scalability expectations of the target market and was quickly replaced by a solution that did. So, in practice one can be certain. 80N 13:27, 25 October 2005 (UTC)

I am troubled that you base part of your argument on the supposed superiority of Fortran to C "for numerical work". In fact, many large running Fortran programs in my experience have bugs so entrenched that the software cannot be fixed and the users must workaround those bugs or are ignorant of those bugs. They seem especially to have to do with uninitialized memory and the consequent random behavior.

The fact is that there was a chorus of dismay coming from the Algol community when Fortran was announced and predictions that Fortran programs would have many bugs, and this was fulfilled!

Which means in regards to MUMPS that MUMPS may be a social construction that seems to work for many people whose careers depend on its viability. At the same time, the bottom level stakeholders of the VA seem to be having, year after year, increasing problems in accessing promised services.

The question is whether the article is NPOV. The problem is that anyone who knows a lot about MUMPS has apparently drunk the Kool Ade.

Source request

Who in particular has called MUMPS "the best-kept secret in the IT industry"? -- Beland 05:05, 18 October 2005 (UTC)

Good question. I didn't call it that, but it is not phony (not invented by whomever put it in--it wasn't me). I think MTA used it in the days when they existed and were trying to promote the language. It's the usual promotional ploy for obscure technologies... carries implication that it's so good that the people who use it want to keep it a secret because they consider it a competitive advantage.

Spinoza1111 10:58, 25 October 2005 (UTC)(Edward G. Nilges inserted one para)A "competitive advantage?" At Massachusetts General Hospital??? At the Veteran's Administration??? This is part of the overall corruption of the language attendant upon computerization, in which the adoption of computers is strangely accompanied by a downgrade of a service ethic in favor, in the public hospital or taxpayer-supported governmental agency, of a silly form of gamesmanship and "competition".

Spinoza1111 10:58, 25 October 2005 (UTC)(Edward G. Nilges inserted one para)This competition, conveniently enough for the gamesmen, is nothing like a true market free-for-all at the public hospital or government ministry. Instead, it is convenient to set the patients, the low-level employees into "competition" with "the numbers" (whence the confusion, as regards Mumps, of efficiency with overall quality).

If you were thinking of snipping it, I for one wouldn't object.

The MUMPS community has always been concerned with overcoming the issues presented by its jocular name, by its traditional "medical" niche, by language snobbery (not a "modern" language), relational DB snobbery, and by the impression that it is "old-fashioned" like COBOL.

10:47, 25 October 2005 (UTC)(Edward G. Nilges inserted one para)Sigh...the concept of "snobbery" has NO PLACE in pure or applied science with regards to the concept of truth. I am as much of a grubby little clerk as the next man, at the same time, I regard it as knowledge and not opinion that the best way to describe what the boss wants is the what and not the how.

I haven't looked at the history but I don't like the current introductory paragraphs. Dpbsmith (talk) 09:31, 18 October 2005 (UTC)

Here's a current promotional marketing-ish claim that does NOT derive from the Wikipedia article:

MUMPS Globals : A Primer for the PHP Programmer "That’s the concept behind the m_php gateway: it provides a beautifully simple and effective union between the best web application database environment (PHP) and the most effective “best kept secret” database (MUMPS)."

And another:

M(umps) - Massachusetts General Hospital Utility Multi-Programming System "It is this capacity to easily and more importantly efficiently store 'sparse' data that earned MUMPS/M the title of the "best kept secret in the IT industry". Yet it all stems from the desire to offer implicit file-handling, rather than actual database concepts having been an integral part of the language." This source attributes the "best kept secret" to http://www.m21.uk.com/newtom.php .

In other words, it IS a frequently-used promotional description of MUMPS. Dpbsmith (talk) 09:31, 18 October 2005 (UTC)

10:47, 25 October 2005 (UTC)(Edward G. Nilges inserted one para): OK, the "secret" wasn't the author's own invention. However, there is something wrong with the idea that something being a secret is a strong recommendation. "Oh, we use a Secret database here so the military veterans have no way of criticising our computers' decisions to make them wait five years for care." Or, as Edsger Wybe Dijkstra wrote in the persona of the CEO of Mathematica, Inc., a fictionalization of Dijkstra's *betes noirs*: "when we were at university, we thought that only Truth matters: here at Mathematica, Inc., however, we now know that only Secrets matter".

Carl W. Olofson, of IDC, April 2005, ICD #33180, Volume 1 http://www.idc.com/getdoc.jsp?containerId=33180 and http://www.intersystems.com/cache/analysts/BestKeptSecret.pdf said "Given the scope of its capabilities and the users of Cache, the product and its maker qualify as the best-kept secret of the software industry". So, that's who, in particular, has actually said this. But it has been said many times before this. 80N 14:04, 18 October 2005 (UTC)

Just for the record, I think InterSystems would probably take umbrage at the idea that Caché is the same thing as MUMPS. (That's not what I think, that's what I think InterSystems thinks). Dpbsmith (talk) 23:10, 18 October 2005 (UTC)

Caché is not the same thing as MUMPS, but it is an implementation of MUMPS with plenty of extensions, additional features and functionality. The documentation for Caché http://platinum.intersys.com/csp/docbook/DocBook.UI.Page.cls?KEY=GCOS_intro says Caché ObjectScript is a functional superset of the ANSI-standard M programming language. InterSystems are quite coy about it but they do not deny it. 80N 11:09, 25 October 2005 (UTC)

In response to Edward G. Nilges' comment above:

• I happen to agree that "X is Y's best-kept secret" is a rather unoriginal marketing ploy, and one that I dislike.
• The article says M has been called the best-kept secret in the IT industry. This should be sourced but I think it is a factual statement. Just as "Reno calls itself the 'biggest little city in the world'" is a factual statement. It does not mean that Reno really is the biggest little city in the world. It means that this really is a well-publicized slogan that is one of the things people think of when they think of Reno.
• I believe that M is indeed underrated and this is a supportable point of view. It has been over a decade since I used M and I would say that not a week passes that I encounter some programming task in my work that I could have accomplished far more easily in M than in whatever language I'm using. It's very odd, because the M array/global is seemingly an inflexible "one-size-fits-all" model, yet it really does fit an amazing percentage of data modelling requirements amazingly well. I've done a lot of cobbling up of STL map objects and MFC containers and it just ain't the same. Dpbsmith (talk) 13:07, 25 October 2005 (UTC)

The MUMPS database (section removed from main article)

I've removed this whole section from the main article. While a good description of the MUMPS database is needed, this isn't it. There is too much advocacy here and not enough NPOV description of what a MUMPS database really is. This section also contains commentary by 63.200.56.237 which should have been put on the talk page in the first place. 80N 22:22, 31 October 2005 (UTC)

In the traditional relational model, datastores consist of a number of tables, each one holding records for some particular object (or "entity"). For instance, an address book application would typically contain tables for PEOPLE, ADDRESSES and PHONE_NUMBERS. The tables consist of a number of fixed-width columns holding one basic piece of data (like "first_name"), and each record is a row.

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.

The SQL syntax for joining tables may seem simpler to some programmers however:

SELECT * from PEOPLE p, ADDRESSES a, PHONE_NUMBERS n
 WHERE p.id = a.person_id
   AND p.id = n.person_id
   AND p.first_name = "Bob"

In this example the WHERE looks for all the a's and n's (addresses and phone numbers) that have the person's ID tag stored inside them, but only for p's named Bob.

This trivial example already requires three lookups in different tables to return the data, which, as you might expect, is very slow. In order to improve performance, the database administrator will place an index on heavily-searched columns, in this example the person_id columns. An index consists of a column containing the data to be found, and the record number of the matching row in the table. This is the reason that tables are fixed width, so that the database can easily figure out the physical location of the record given the location of the start of the table, the length of any row, and the number of rows to skip. Without this simplification, performance of the relational model would be unusable.

M's datastore stores only the physical locations. This means that records can be of any length, placed anywhere, and contain anything. Searching is not needed to find any record, a pointer directly to that record is easily retrieved and followed to the data in question. The physical data in an M is typically stored in a hierarchical structure of strings, arranged as an ordered tree. 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. M databases are therefore smaller and more space efficient than relational data structures. The caching methods used allow for multiple users to access the data simultaneously. This means that multiple users in the same data structures will by their use, increase the likelyhood that the data node being sought is actually still in memory. On an operational system that has been running for a while, the cache hit ratio is about 85%, which means that only about 15% of the I/O reads will result in an actual disk access. This is another reason for MUMPS' increased performance (less disk operations).

[Sorry, but this whole paragraph is wrong.]{So why doesn't the relational model do the same thing? Historical accident. At the time the difference in speed between storage and processor was much smaller than it is today, and the cost of having the CPU follow a pointer was expensive compared to the simple arithmetic needed for an index. Today the CPU's have grown many times faster than the storage, so this cost is effectively zero. This is the main reason why multidimensional datastores outperform relational ones today, something that was not true in the 1970s when the two models were in competition.} (Sorry, but this is not why. MUMPS was faster before and it is even faster now.)

[Please replace the previous paragraph, with this][So why doesn't the relational model do the same thing? Actually, some of the larger relational databases actually do relational structures behind the scenes. They got a lot of scalability out of this design change. But they have not been able to provide a logical schema to replace their physical schema. Most of the successful MUMPS-bases data management systems use a highly dynamic ]

M globals are, in fact, indexes. Each node in the global contains a pointer to the data. The actual method of access to the data structure is left to the implementor. The pointer system via the node reference is an abstraction which resolves to a string of data. Unlike the relational model, where indexes are a special-purpose object included as a necessary evil used in some lookups, under MUMPS, the data is accessed in the manner which makes the most sense to the application. The nodes are character and the indexes from the nodes to the actual data are never seen. It is because MUMPS is a logical binding rather than a physical binding that makes the MUMPS data so portable and readable. This is yet another reason for MUMPS's impressive error-time supportability as well as platform independence.

[[Where did this come from?? It may be correct for a single application, but certainly not the general case.] This makes M systems particularly well suited to looking up related data, as in the example above. The equivalent M statement would be something more akin to:

SELECT * from PEOPLE p, ADDRESSES a, PHONE_NUMBERS n
 WHERE p.first_name = "Bob"

Related information can be stored directly in the index, in p.addresses for example. In this case no lookup is needed, PEOPLE can point directly to the addresses and phone numbers. ]

The biggest consequence of this internal representation is that database operations are economical (in both disk space and execution time as well as portability). MUMPS is extremely well suited to real world data, which is often 'sparse' (ie has missing fields). There is no penalty in storage space if a defined data value is not present. This is an extremely helpful feature in a clinical context.

It cannot be overemphasized that real-world applications really do make heavy and unlimited use of these persistent, disk-resident "global" arrays, which can be of gigabytes in size. This is a notable difference between M and other languages (e.g. Perl) which provide "dictionaries," "maps," or other string-indexed dynamic arrays which are RAM-resident and hence limited in capacity. The ability to access string-subscripted multi-dimensional arrays, and to freely add and delete new elements, is not a theoretical capability. It is how the MUMPS language is intended to be used. Surviving M implementations are the result of heavy marketplace competition which was largely based on the ability of vendors to provide efficient and robust implementations of these "globals."

MUMPS includes almost no operating system specific command syntax, very few file system interface commands, and no machine specific commands. (Idiomatic M applications store data within disk-resident globals; the fact that these globals reside in operating system files is invisible to the application code). It is thus quite portable. Additionally, database manipulation code is extremely brief. A MUMPS routine implementing a complex database interaction might be a page or two of code. The equivalent in a less high level language (C, Pascal, Fortran, ...) is likely to be an order of magnitude larger. Several studies done in the 1980s and 1990s contrasted M rapid applicaton development with other systems including COBOL and SQL based systems. 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.

BizarreUnconventional Syntax

Pragmatic goals such as standardization, portability, and backward compatibility have always taken priority over niceties such as bringing its bizarre syntax into line with modern expectations.

This statement about bizarre syntax seems a bit POV. The syntax is very self consistent, much more so than a lot of other languages. I find SELECT DATE FROM ORDER to be a very reasonable SQL statement but bizarrely is not legal (DATE and ORDER being reserved words). NULL is bizarre. The javascript getMonth() method of it's date object is bizarre (it returns 0 thru 11). MUMPS is significantly different from most languages but it is no more bizarre. 80N 09:15, 1 November 2005 (UTC)

My whole paragraph flirts with POV, but I've tried to keep it balanced, truthful, and say something useful and meaningful. Feel free to tweak. I changed "bizarre" to "unconventional," which I think is fair. The one-versus-two-space thing and the colon-conditionals are quite different from anything else I've encountered.

I don't really think MUMPS advocates would quarrel too much with "bizarre," though, and would agree that some aspects of the syntax are an acknowledged weak point of the language. Surely the push/pop rules for $TEST, and the way in which ELSE works—or rather doesn't—can only be described as a kludge, retained only because nobody was ever able to figure out a way to fix it without breaking backward compatibility.

I personally belong to the school of thought that says code quality is almost entirely the product of programmer skill and management wisdom, and language design (or strong typing, or conventions like "Hungarian notation") really has a negligible effect on anyone but a novice. Dpbsmith (talk) 14:37, 1 November 2005 (UTC)

I like unconventional. Almost all languages have some bizarre elements to them but that doesn't make a whole language bizarre, and compared to Perl, to pick just one example, MUMPS isn't all that odd. 80N 17:39, 1 November 2005 (UTC)

"Best kept secret"

I've found a source. A long MTA promotional blurb, based on The Gartner Group's 1992 MUMPS Assessment and Opportunity study, says:

Gartner Group characterized the M market as "one of the best kept secrets in the world of information technology."

The "secret" here was, however, not the effectiveness of M technology, but the size of the MUMPS-using market. The blurb says that Gartner estimated 1991 worldwide M revenue at $976 million; "Hardware revenue accounts for nearly half, $482 million, while applications total $407 million." Gartner predicted it would be a $2 billion market in 1992.

So that might be one source for the "best kept secret" meme.

(As for the rest of it, I never have much trusted Gartner. I recall very vividly a 1990-or-so study of theirs with a graph showing the relative market share of MS-DOS, Windows, and OS/2, showing OS/2 overtaking Windows by about 1992 and becoming overwhelmingly dominant by the mid-90s). Dpbsmith (talk) 00:40, 12 November 2005 (UTC)

Revised, with Criticisms

The page was lacking any discussion of the negative aspects of MUMPS. I attempted to add them using as neutral a tone as possible (they're at the bottom). These are only objections to the language itself, not any particular application or implementation of it. I also tried to point out that many vendors offer workarounds for many of the problems. I apologize in advance if I misunderstand your objects, Spinoza1111 (I tried to include the language-specific ones in the 'criticisms of Mumps'), but some of your objections are to poor programming practices. Globally scoped variables, for example, are available and used by script kiddies in C too. A poor programmer just has more "help" from the MUMPS language for creating poor code. It's important with MUMPS to hire a self-disciplined, conscientious programmer who keeps an eye on future maintainability, but this is important with EVERY language.

• Seems pretty good and reasonably fair. I think it can and should be boiled down to about 1/3 its current length by reducing each paragraph to a pithy sentence or two. I don't like the formatting. I assume you know that you can create

subsections within sections

like these

by using

three, four, etc. sets of equals signs, e.g.

===this creates a third-level subsection===

Dpbsmith (talk) 21:06, 18 November 2005 (UTC)

Criticisms Update

Thank you, this was my first Wikipedia entry, so I didn't know about section headings.

I've shortened many of the sections to reduce the overall length of the criticism section. Hopefully it still makes sense and is still something that even die-hard MUMPS programmers can agree on. I can put some arguments and explanation back if there are now sections that sound like I'm making a bunch of ungrounded assertions.

The criticisms cover only the "major" objections to the use of MUMPS. I don't know if it's appropriate to put them there, but there are a number of just "annoying" MUMPS limitations. I feel like putting them there would make the arguments against M seem petty or spiteful. Here is something like what I'd go with:

Annoyances

These are fairly trivial "problems" that MUMPS programmers are used to working around, but will annoy someone who is more familiar with another language.

• You can't create/scope a variable and assign a value to it at the same time (like 'function x() { var y = 5; }')
• You can't create multiple array elements simultanously (like 'var Array = [ 1, 9, 16, 2 ];')
• There's no 'while' or 'do/while' statement
• There's no easy way to put large chunks of text to be printed into the code
• You can't return anything but a simple value from a function, so if you want to return an array or structure the calling function must pass it to you. You have no way of telling whether they passed you a structure unless you set up semaphores.
• You can only use top-level variable names when passing variables to be modified (or to have an array or structure created within them). This makes it hard to limit a function to creating or accessing just part of your structure. (like 'var x=document.getElementById('selectionBox'); edit_option(selectionBox.options[5]);' to have the edit_option() function access only option# 5 and it's sub-properties).

Perhaps these are best left on the discussion page since the 'criticisms' section (even with edits to shorten it) is still quite long.

if you want a while statment in mumps is very simple

for quit:not(condition) do . stament if condition

Updated criticisms

Some people had responded to criticisms by saying that their specific vendor supplies a non-standard language extension to fix the problem. Rewrote some criticism sections to make it more clear.

M-Global Mumps History

--AGlassman 04:23, 10 February 2006 (UTC)

My name is Alan Glassman. I worked with Dave Brown at M-Global in Houston TX on the PC, Mac, and IBM CS-9000 Mumps. The Mac was far and away the most interesting project. Dave had the binary code from an older Motorola 68000 Mumps, so to save time, we made that the "runtime" engine for the Mac version. I wrote a wrapper around it (in Mac Assembler no less) to handle the interface to the Mac GUI and I/O devices but all the core Mumps work (language interpretation and global processing) was done by calling into the old binary code.

Removal of entire criticism section?

Lol, A POV-fork? To "shorten the article"? I agree, the article did need to be shortened, but sanitizing the article of anything but MUMPS-glorification probably wasn't the way to go. You left in the cite of a 1980s DEC-sponsored study that showed that DEC's version of MUMPS ran faster than Oracle? Even though it ran on totally different hardware too? I'm sure *that* was totally objective and needs to be left in.

Okay, the criticisms were taking on a life of their own, but stripping out all but a single-line reference that anyone thinks MUMPS isn't the greatest revolution in programming technology since Assembler seems a bit much. And we nearly had them so that both MUMPS fans and detractors could agree on them...

It's nice to hear how MUMPS "solves" the inability to use whitespace for readability by letting you break up one statement into smaller statements that do the same thing in chunks on subsequent lines.

I put back a short summary of criticisms, left the link to the POV-Fork page and cleaned up the entire article.

- No other language's wikipedia entry lists every command. At most, they list commands that offer unique language features. Unless this article was intended to be a desk-reference for a MUMPS programmer (and it was far too incomplete for that), this is just dead weight. Created external link to Ed de Moel's 'MUMPS by Example' which does all this for anyone who is starting out with the language and wants to see how all the commands work.

- Outdated studies, opinions, advertisements for Cache, an entire section on MIIS (that duplicates a lot of what's in History) and various undocumented claims were banished to appropriate sections.

- Extremely long "abstract" at the top of the page shortened, most of it moved to the new 'Overview' section. Overview expanded a bit for clarity to help non-MUMPS programmers (presumably the people who will be reading this entry) understand why MUMPS is special.

- Attempted to tone down or cite the source of lots of unsubstantiated hype.

Hopefully the page is now much more acceptable to both diehard MUMPS fans and diehard 'SQL is teh ubar awesomeness' as a tone-neutral entry on a fascinating language.

Saintly 21:29, 14 February 2006 (UTC)

Your slanted POV speech is not helpful.

Your statement "we nearly had them so that both...could agree" seems incorrect on many levels.

This article MUMPS is about the language MUMPS. Your article MUMPS (criticism) is about your criticism of it. It was left perfectly intact. I do not understand your complaint? Is it that your POV no longer occupies over half the article? Your POV is reflected untarnished in 100% of the criticism article.

Your total rewrite here is certainly not the way to go. None of the edits you made were in any way neutral.

--Connel MacKenzie 05:52, 15 February 2006 (UTC)

A point-of-view fork is not the right way to go, either. The criticism section, now an article, is (and always has been) overly long, rantish, and way too much in the nature of personal opinion and original research.

The article on MUMPS should neither boost nor knock the language.

It should cover cultural aspects as well as technical aspects.

It should state the obvious-to-anyone-familiar-with-MUMPS (it's old, it's not mainstream, and therefore has the same real world problems as languages like COBOL or FORTRAN. It survives both because it is a superb tool for a significant number of real world applications, arguable better than mainstream "modern" approachs like ORACLE. And it survives because in real world one does not lightly cast aside legacy systems; business systems may need to last much longer than the typical five-to-ten-year-cycle of language fashions. A business system that had been converted from, say, MUMPS to PL/I would be in no better shape today than if it had remained in MUMPS). It should state these things succinctly and each statement should cite a source. It should mention both positive and negative features without trying to evaluate how positive or negative each of them is, or to make any overall judgement. Dpbsmith (talk) 14:31, 15 February 2006 (UTC)

Please don't feed the critic's paranoia by calling it a "POV fork" (as it is called by the brand new user account) when it is no such thing. That section was simply the least applicable to MUMPS, therefore the most likely and most logical to be split off; the section is a self-contained unit that doesn't relate particularly well to any part of the main entry. While it is true that it is overy long, rantish and personal opinion (refering back to the author's web site as the only apparent citation) the topic it covers simply is the least relevant to this Wikipedia article. That, combined with the size of the section, makes it the best candidate for splitting the large article. --Connel MacKenzie 14:52, 15 February 2006 (UTC)

It's not overly long. 32K is just a guideline. It makes much more sense to keep everything in one article. If there were going to be a breakout at all, and I don't see any reason for it, the new article should cover "Pros and cons of MUMPS," not just "criticism of MUMPS," and certainly not A long criticism of MUMPS which is not a very encyclopedic topic title. Dpbsmith (talk) 16:22, 15 February 2006 (UTC)

Reverted without reading?

I know I have opinions about M[UMPS] that disagree with yours. I know that the criticisms section (which I started) was getting so long that it took up over half the page. I also know the article was getting too long.

Nevertheless, I try to the best of my abilities to keep my POV in the opinion/criticism section, or discussion page, not the article. I didn't even mention the many things that are annoying lack-of-features of MUMPS in the main page because that would have been petty.

I didn't remove large chunks of information from the article with my "rewrite", nor do I believe I inserted any POV-ness in. If you could review the changes, I think you'd see:

• There were two "history of MUMPS" sections. One was about MIIS and the first several paragraphs duplicated information in the History. It is logical to link these two together, especially since (according to the article, not me) MIIS is really just an offshoot of MUMPS that was never used outside of one institution.

• Only the MUMPS article (out of many different language articles) tries to list every single command in the language. If you're looking to reduce article size, why are you retaining information about 'GOTO', 'IF' and dozens of other commands that are in EVERY language. I left the commands that make MUMPS unique. A full listing of commands is appropriate for a desk reference, separate wikipedia section (maybe) or book, but just clutters up the main article.

• There was a long, MUMPS-jargon-filled 4-paragraph "executive summary" (which is the thing that's supposed to precede any section headings as the info for people browsing) at the top. In other language pages, the long description of the language is put in the first section ('Overview') and the summary is kept as short as possible. I attempted to keep MUMPS jargon out of the overview.

• There was an entire paragraph detailing the exact results of an 15-year-old vendor-sponsored study that showed the vendor's MUMPS product was faster than some other vendor's product

• There are several POV-statements by MUMPS advocates.

I didn't restore the entire criticism section. I created an 'Opinion' section to highlight both the PRO *and* a super-quick-summary of CON arguments for MUMPS.

Please point out how the changes you reverted reflect an "anti-MUMPS" POV or make the article less clear or more misleading. Or point out why you feel the two separate "history" sections (with one tacked-on, so it's separated by a gap of non-history information) or why the old structure was better.

I apologize that my account is new. I've read wikipedia for years but haven't seen any topics I've cared to edit until this one. I also don't agree with many of the things Spinoza has to say. Neither my account age nor my differing opinions are worth reverting a page.

Calling the removal of an entire section filled with POV and Forking it off to its own article a "POV Fork" may have been a bit drastic, since I gather that that term is used as flame-bait on Wikipedia. I agree that it had grown like a cancer till it was nearly as big as the rest of the MUMPS article. It still seems a bit dishonest of you to claim that you "removed it to reduce article length". Why just that one section? Why not the other gobs of outdated information? Why not reduce the noise by trimming paragraphs that repeat essentially the same information in two unnecessary sections? I did NOT add it back in with my changes, I attempted to actually shorten the article down to size by removing sections of redundant information and adding clarifications to things a non-MUMPS programmer might not understand. You'll note that the article is NOW no longer complaining about being too long.

Please be kinder to a newbie and explain to me why you feel something I added is non-neutral POV, or harms the article (or even why it doesn't HELP the article). Don't associate my clarifications with Spinoza's bizarre claims that MUMPS is ruining healthcare for veterans.

Saintly 16:06, 15 February 2006 (UTC)

Discussion of specific changes:

Lest you think I removed sections of useful article, here's what's changed and why.

-- All good implementations of MUMPS use sophisticated techniques for managing, caching, buffering, compression and sorting of persistent data. These are normally intrinsic to the implementation and transparent to the programmer. Historically, portability, standardization and run-time performance have been priorities at different times in the long history of MUMPS. --

As compared to databases that use the bubble-sort? What "sophisticated techniques" are these that everyone doesn't use? Portability and standardization have been priorities of the MDC (every vendor wants you to use their special extensions so that you never leave). Run-time performance is a "priority" of virtually every application ever written. Are these worthy of being in the 'executive summary' of MUMPS?

-- MUMPS is traditionally an interpreted language although ... --

The interpreted-vs-compiled is not specified by the standard, and the Overview points out that vendors have gone all three ways with this. Not Useful for the executive summary. "Despite being interpretive, most implementations have very good run-time performance characterstics". Not cited, uses lots of "weasel words" ('most','very good') and offers nothing you wouldn't expect. Are there interpreted languages optimized for slowness? This is an unsubstantiated claim.

-- Culturally, MUMPS is a very pure example of an application programming language ... --

For starters, this is history. Second, to be accurate, it's designed for creating applications that work with databases, not general-purpose programs. Instead of deleting this, I clarified that MUMPS was designed to make writing database-driven applications easy.

-- Richard G. Davis commented that "Where economics has been a primary consideration... the MUMPS language has distinguished itself." --

Sorry, who is Richard G. Davis? Ah.. he's a member of the MDC and works for the Veterans Administration as a MUMPS programmer? Why are we presenting unsubstantiated quotes from 1989 by a MUMPS advocate as if it were an article of faith today?

-- Overview... --

This entire section was added, and if there's anything inaccurate in it, I'd like to see it pointed out. Despite my personal feelings toward the language, this seems to be a very positive summary of the GOOD features of MUMPS. Although you may take them for granted, I assure you that non-MUMPS programmers will be impressed to see that every variable implements both hashing and uber-arrays for free, and additionally keeps the keys in sorted order. I don't think any other language allows you to have negative floating-point values as an array index, and most other languages that implement hashing don't keep the keys sorted automatically.

-- History... --

Left essentially untouched. Some sentences edited for grammar and clarity. MUMPS 'is' an interpreted language becomes MUMPS 'was' interpreted (I know that GT.M at least is compiled), and 'incorporates' to 'incorporated' to fit the tense of the sentence.

Note added that Intersystems is a middleware vendor, and the extra information about Intersystems that was in the MIIS section moved up to join the rest of the paragraph about Intersystems

The tail end of the MIIS section (the first two paragraphs repeated information that was already in the history) moved up to the history section. MIIS and MAGIC are not MUMPS, and the interesting thing about them (they are offshoots of MUMPS developed by the creator of MUMPS) should be a part of MUMPS history. Interestingly, the MUMPS history says that MIIS was "an implementation of MUMPS" and the MIIS section said it was an in-house derivative that never got submitted to ANSI or standardized. I left that part in because I'm sure it makes sense to somebody, just not me.

-- The VA, other industries --

Moved into their own section called 'Major MUMPS users'. Sorry, the claim that "Given similar hardware, multidimensional databases like MUMPS are typically about six times faster than SQL for transaction processing" is something that I can't find anywhere on the net but the wikipedia article. It's also mentioned offhand in the MUMPS FAQ, but no source or study is cited. It apparently is based on the DEC study (that is also unavailable on the net, I searched for TCP-A, MUMPS, etc.. and even the website that was linked to is down) that found that DEC outperforms their competitors. "They are also particularly good at looking up related information in other data stores "for free", a task that requires an expensive JOIN operation in SQL systems" also reflects a poor understanding of other databases. This is not necessarily true of SQL, though it may be true of a poorly-set-up relational database. " During the 1980's..." The study is over 15 years old, the link to the study is broken, the website is down and DEC no longer makes this claim. In fact, there don't seem to be ANY independent benchmark studies that compare MUMPS to anything else. Nevertheless, I moved this study down to the 'Opinion' section.

-- Description... --

Renamed to 'MUMPS language syntax' since it's about the language syntax. It restated the fact that MUMPS may not necessarily be compiled or intpreted, mentions that whitespace is significant in the middle of the first sentence and then repeats it in the next. Clarified.

"build up" changed to "create", "collect up" changed to "find" (no need to invent phrases when there are simple words for the concept).

-- Summary of language features... --

It is not useful to MUMPS programmers to have a partial listing of core commands and intrinsics described in the article (there are far better resources for this, with discussions of commands and examples to explain the half-dozen ways some of them can be used). Listing all of them is not a "summary", and such a listing is unhelpful to someone who is interested in MUMPS but wants to learn about it (MUMPS by Example is a much better place to start).

Unless you have a really good reason to leave this in, it just bulks up the article and makes the reader gloss over the large sections of fixed-width language examples. There are no other articles on other languages that do this.

-- Criticisms of the MUMPS language... --

Renamed to 'Opinion' and broken into Pro and Con sections. I listed all the criticisms in one paragraph, and then pointed out in the next paragraph that your favorite vendor probably offers a workaround. The 'Pro' section is longer, and I moved some of the more egregious glorifying bits into it.

I apologize again for the inflammatory tone of my 'Lol, a POV-fork' discussion entry. I was a bit annoyed that you broke out all the criticisms and then said it was "to reduce the article length". I may be new to wikipedia, but I understand that a POV fork is usually what one person does when they want the main article to reflect one (non-neutral) POV and want to silence the criticism. I can't presume to know your motives, and it was inappropriate for me to claim you were forking the criticisms for that reason. Content forks may be appropriate for some articles, like where the vast majority of scientific opinion says that the earth is round (so the Flat-earth theorists get their own page instead of presenting them as if they had equal weight). In this case, the MUMPS community is the "minority opinion" that claims that their language is the best, despite the fact that the vast majority of the public has chosen other languages. I don't see how this entitles them to have an article that makes lots of unsubstantiated claims that their language outperforms all others.

I should probably have also logged in to make large changes to the article. I assure you that I don't even *own* any sock puppets and wasn't trying to hide the fact that it was me editing the article. I posted a discussion page immediately afterward and used the four-tilde thing to sign it after explaining the changes I made.

Saintly 17:50, 15 February 2006 (UTC)

MUMPS the amazing XML Parser

I removed some advocacy claiming MUMPS was "ideally suited" to generate HTML and "quite powerful in reading and parsing html pages and xml pages to extract the content as well as understanding the structure".

Can you clarify that a bit? PHP is a language actually designed for both database interaction and creating web pages. Javascript has expressions and objects to let you create dynamic web pages without using any actual html tags. Even C will let you write long strings of text without having to precede every line with whitespace + a write statement.

If your MUMPS vendor supplies you with a DBMS, you'll hopefully be able to generate XML representations of database objects at least.

As for reading and parsing... MUMPS lack of regular expressions makes it frustratingly difficult for me to read any sort of file other than extremely simple delimited text files (UNIX password files, or exported excel documents). If I want to extract an HTML tag in javascript, PHP, Perl or any other modern language implementing regular expressions, I can just say '/<(\w+)( .*?)>/' and immediately have access to the entire tag's contents, including the tag type and any arguments.

In MUMPS, a pattern-match can tell me that a tag is present somewhere in my string, but finding it means either using $F (which tells me where the tag starts ONLY) or parsing the whole file line-by-line. If I want to find out what's in between two tags ('/<body.*?>(.*?)<\/body>/') in some other language, that's a 1-liner. In MUMPS, I'm again forced to go word-by-word and line-by-line and push what I've found into a temporary variable (or more likely; subscripts of a temporary variable to get around memory limitations on strings)

Even splitting text apart (something MUMPS is actually designed for) is difficult if the text is irregular. 'var pieces = text.split(/[\s,\.]+/);' would break up some text into parts based on spaces, commas OR periods without destroying the original text. I don't see a way in MUMPS to do the same thing. You can separate a string by a single delimiter (spaces OR commas OR periods) and work with it in-place, but not all at the same time. MUMPS programmers I've seen would accomplish the above by duplicating the string, translating all characters to split on into one character, then using $P.

I can see how MUMPS can be bludgeoned into becoming an HTML or XML parser (There's a freakish looking MUMPS syntax highlighter here that runs out to 3 routine files- thanks to routine file size limitations in the early days) but I can't see how it's good at it, or especially how it's better at it than one of the half-dozen other languages that have showed up in the last decade.

Saintly 18:29, 5 April 2006 (UTC)

Talk page getting large

It would be nice to archive some older discussion (some of it is several years old) on a Talk:MUMPS page #2, but I wouldn't do this without discussing whether this appropriate and what should go/stay.

Saintly 18:28, 5 April 2006 (UTC)