Talk:MUMPS/Archive 2

Archive 1

Archive 2

Untitled

• Archive 1 - (Through April 2006) POV "Flamewar" discussion, Criticisms, Bizarre/Unconventional Syntax, the MUMPS Database, "Higher Level" layer, Older Comments

Remember: All comments should be added to the bottom of the page unless a response is particularly well suited to inclusion immediately after an existing comment. When this is done, always insert a space and indent one level in addition to that of the comment being replied to. Sign all comments with 4 '~' in a row at the bottom of the comment. Please...

Mumps in the modern world

I have experience with a mumps database and mumps programmers. I think it is funny that a article about mumps can have a "pros" paragraph it is clearly more effective end efficient to just start over and use a relational database and put your mumps database in a museum. You wil get a more logical and understanable database. You can use a real modern structured or objectorientated programming language so you get a lot better code.

• Not everyone with experience in both relational databases and with MUMPS agrees with you. (Could I hazard a guess that you learned about relational technology in school, and then unwillingly landed in a situation where you had to deal with an existing MUMPS-based system?) Dpbsmith (talk) 15:30, 27 June 2006 (UTC)

• you guessed right ;-) but I like to add that the state of this database is terrible by not enforcing constraints. Automatic processing of the data (for reporting) is extremely difficult. I guess this problem is a problem of the design of the database management system because I never saw a relational database that was this bad. Also the design process is not as disciplined as in the relational world and documenting the database is also more difficult. I also see experienced mumps programmers having real problems in delivering what was promised.

• I would also like to point out. I've been a DB admin and App developer (C++) for about 8 years now. I find that the biggist problem with database applications is not the technology used but the use of those technologies. And from my experience M[UMPS] is no different in this regard. DragonLips 21:18, 15 October 2006 (UTC)

• I suggest the section "Major users of MUMPS applications" have a link to EPIC Systems included. For the past several years, this company has used MUMPS/Cache as technology to support their very popular EMR (electronic medical record). More US people might already be "recorded" using their EMR than those DoD/VA people recorded with VistA.

• I'd like to point out, that since all the "criticism" paragraphs are gone, there were left only pros of the language. Even the syntax is claimed to be readable "by expert developers" (I don't know what's that supposed to mean). Since there are lots of solutions superseding MUMPS right now, I highly recommend putting a section which will make it clear that's its significance is purely historical (and applications are only maintained as legacy). I can't see any company creating anything new in MUMPS; it might not be clear to the reader, as all the comments in the article are extremely positive; it might actually seem a bit biased.Bananu7 (talk) 08:02, 3 September 2012 (UTC)

Predates BASIC? Not that old

"Because it predates C, BASIC and most other popular languages in current usage, it has very different syntax and terminology." Actually, BASIC came out in the early '60s while the article says MUMPS came out in the late '60s, so BASIC predates MUMPS, not vice versa. It's certainly possible that BASIC wasn't very widely known yet when MUMPS was developed, but that's not the same thing. -- CWesling 03:42, 13 May 2006 (UTC)

Removed merge suggestion

Someone tagged this to be merged elsewhere. Cute. No discussion and suggested the wrong direction. Rolled back. --Connel MacKenzie - wikt 20:29, 13 December 2006 (UTC)

Did I tag it the wrong direction? OK, maybe I did, couldn't you have fixed that instead? --Regebro 20:41, 13 December 2006 (UTC)

Readded merge suggestion

Comment unecassary, really. The MUMPS (criticism) is a POV hate-article with no counter, and bad arguments. The good arguments (if any) should be merged into this article. --Regebro 20:45, 13 December 2006 (UTC)

Vote to remove 'Merge' suggestion, and delete 'MUMPS (Criticism)' article

Although it's hard to find in the disorganized 'Talk' page, you can see that the 'MUMPS (Criticism)' section started out being part of the article. It started somewhat small (each heading was just a bullet point) and then grew into a giant section as people raised various objections. Then it was forked off into its own page. Then the main MUMPS article was revised and a paragraph representing all the major criticisms from the page was added to the main page in the 'Opinion' section.

I don't know how to delete the 'MUMPS (Criticism)' page, but you can see what became of the content on it:

 Old Page (with full criticism)
 Page after merge

I personally don't think the main article needs more expanded criticism. Most people using MUMPS have no choice but to continue using it, and most people starting new database applications don't need a wikipedia article to help them rule it out. Saintly 02:48, 31 December 2006 (UTC)

I agree that any merging needed has already been accomplished, and that MUMPS (criticism) serves no purpose now and should be deleted. I think here on Wikipedia that is accomplished with {{AfD}} or {{prod}}? --Connel MacKenzie - wikt 03:22, 31 December 2006 (UTC)

Asking on IRC, I was told to blank it and replace it with a redirect (such as #REDIRECT [[MUMPS#Opinion]]) with an edit summary comment pointing here. --Connel MacKenzie - wikt 03:27, 31 December 2006 (UTC)

Replaced MUMPS (Criticism) page with redirect to Opinion section

• Removed merge link
• Replaced criticism page with a redirect
• The 'overview' was a bit convoluted in places, I tried to separate some dense topics and provide examples.
• Removed some vague language (MUMPS was based on 'advanced structures'. -- perhaps someone can say what these were or why they're so advanced. Do they use Ninjas?) and how it is 'quite efficient' in lots of areas (again, does it use Ninjas? Perhaps a link to an efficiency study of MUMPS vs. Oracle, or someone explaining why having dense, abbreviated source code is important today?)
• Linkified some stuff (Interpreted, compiled, etc..)
• Banished terrible code example 'hellohtml()' to its own section called 'sample program'. Perhaps someone can come up with a better sample program? The functions in that program all print stuff directly rather than returning it (limiting their usefulness and demonstrating that you often CAN'T do things you'd like in MUMPS thanks to string-length limitations). Anyway, 'Hello World' is just where you show off the simplest (readable) program possible, like on the article pages for other languages.

Saintly 21:01, 5 January 2007 (UTC)

Many external links in article.

I've removed some of the external links. Others remain as references. I'm leaving those in hopes some eone familiar with this page can look at them and move them to the reference section where appropriate. Cheers, :) Dlohcierekim 22:38, 14 September 2007 (UTC)

MUMPS is killing US veterans and this article is aiding and abetting!!

Goddamnit, this article is written POV, probably by some clowns who know only MUMPS and are desparately afraid that their stinking, rotten, filthy little jobs, delaying care to military veterans with their goddamn outdated technology, might be lost. Men and women are returning burned and blasted to shit and sit and rot in hallways for "paperwork" to catch up with them.

Where does this paperwork come from? Why is it late?

This article DOES make it clear where it comes from and why it is late. A bunch of contemptible little programmers who care only about their cozy comfortable jobs actually believe the ABSURD claims in this article.

I've removed one such claim: it was logically contradictory, and the person, probably a MUMPS hotshot, who posted it didn't see the logical contradiction because he or she is STUPID. It literally claimed that "structured programming" reduces development time AND that it makes programs difficult to debug.

Hey, Ace. Hey Hot Dog, what the HELL do you think you're claiming?! That you're done developing when you stop typing the code?

My uncle, a personal physician of Lyndon Johnson, is probably DEAD because of MUMPS. He died alone in a military hospital at the age of 78 because Job One in an organization with dysfunctional-dogshit computer systems is the fascinating "intellectual challenge" that paperwork presents, which health "care" bureaucrats seem today to prefer to looking after men and women who've served their country.

As I have posted, last month the OIG of the Veterans Administration has reported serious problems of the type that emerge from clownish data systems celebrated by buffoons for their wonderful GoTo statements, their fascinating limits on string length, and overall, their replacement of transparency by an opacity, that allows data processing bureaucrats, most of whom with serious addictions, usually to food, to sit on their fat asses "thinking" about stupid things.

The article violates wikipedia NPOV and it needs to be rewritten from top to bottom. NPOV is NOT NOT NOT agreement with the local boys who colonize an article. MUMPS is a dysfunctional system: this is FACT.

Edward G. Nilges —Preceding unsigned comment added by 203.198.250.69 (talk) 10:58, 23 September 2007 (UTC)

EGN, The personal attacks here against other editors are inappropriate, however strongly you feel about the quality of their work. It is a non-collegial approach.

Your comments are obviously strongly felt, but are largely inappropriate for inclusion in a Wikipedia article. Comments should be neutral and without personal animus. If you want to include this material or something similar, you should recast it into encyclopedic form. As for the Office of the Inspector General report you mention, if it is the one noted below, it does not reflect the content you claim for it. The OIG did not identify MUMPS as a cause of the problems which stimulated the investigation and did not identify any aspect of the software used at VA as a finding to be repaired. Reading the report will make clear the problems were due to sloppy administration, failure to follow procedures, and inappropriate administrative actions, not faulty software. These are administrative issues, not software deficiencies, inherent or otherwise, in design or implementation. ww 18:12, 15 October 2007 (UTC)

removal of contentious POV text

The following text was removed from the article for POV and for inaccuracy. The cited report is not about the deficience of any programming language but rather about administrative and personal failures, combined perhaps with physical security issues. There may be such a report excoriating MUMPS for the reasons claimed, but this is not it.

The proprietary, unstructured, otiose, and primitive nature of MUMPS has caused the Veteran's Administration to delay care to military veterans and made auditing of its responsiveness unnecessarily difficult. Cf.http://www.va.gov/oig/51/FY2007rpts/VAOIG-07-01083-157.pdf, an August 2007 report which found serious problems in both areas, where data systems perform a critical role.

Comments anyone? ww 18:12, 15 October 2007 (UTC)

Go, ww! 8-) -- CWesling 09:44, 11 November 2007 (UTC)

Ummm, that report dealt with the physical loss of a hard drive with data on it. You are blaming that on MUMPS? Perspectoff (talk) 18:47, 17 April 2009 (UTC)

Moved 'Major Users' to own page, other edits

There's not any other programming languages that list the people who use it, and that section was starting to become it's own 'special advertising section'. It probably belongs on an external MUMPS advocacy website, but whatever... it has it's own Wikipedia article now, so advertise away! I saw that someone moved it to the top of the article for bonus goodness, so I put it back under 'History'.

MUMPS is odd in being nearly invisible for a widely used programming language. WP can surely note this, with examples, without straying beyond its rubric. ww (talk) 21:25, 30 May 2008 (UTC)

I suppose. It shouldn't be the focus of the article though. Someone seems to have made a nicer summary of Major MUMPS Users, but some quote from a company showing how many credit unions and hospitals use a system would be good. 169.237.249.166 (talk) 17:20, 5 June 2008 (UTC)

Procedures are not c source files with respect to variable scope. Procedures by default create variables that are visible to everything calling it and called by it, unlike C, where your function's variables are private unless you declare otherwise.

True, but ...? If the article was misleading, this point might belong there. MUMPS is not a modern language in some of these respects and expecting it to be so merely confuses. Perhaps we should note these oddities from a perspective some 40 years on? ww (talk) 21:25, 30 May 2008 (UTC)

It's just that I removed the claim that procedures = c source files with respect to variable scope. I changed it (on the MUMPS Language Syntax page) to say that they're analogous in terms of how you group functions together. I also added a bunch of other stuff to that section, explaining variable scope, etc... 169.237.249.166 (talk) 17:20, 5 June 2008 (UTC)

Added short example to procedures.

Lots of redundant language removed from the section on variables. There's still some weasel words "large set of string manipulation operators". I'd say it's true... most other languages don't let you treat delimited strings as arrays, but perhaps some sort of comparison or number would go well here. "MUMPS has 50 different internal string operators compared to the 2 in C, or whatever."

Random claim that MUMPS outshines SQL in "faster, more easily used and managed" networked data removed, but feel free to add it back with a cite to an Intersystems ad showing how easily Intersystems' $250k system dominated little Bobby's 8th-grade science-fair-entry SQL server.

POV comment here. MUMPS access of data from an external node takes a line or two. In many other languages, this requires coordination amongst operating systems configuration choices, external utility programs, or add-on bits to the language system. All are more complex than MUMPS. Quite how to make the point without runing afoul of the OR police is not so obvious. ww (talk) 21:25, 30 May 2008 (UTC)

Although you can mention system names in global names to write onto that system, this feature doesn't help anyone but people writing one-shot MUMPS applications or DBMS designers. Ideally, all databases (including SQL) will have an API layer/DBMS that prevents programmers from directly accessing globals, and adds networking features transparently. So the programmer should never have to know where the data is stored. From the DBA's perspective, GUI tools should make adding network nodes just as easy with both MUMPS and SQL. 169.237.249.166 (talk) 17:20, 5 June 2008 (UTC)

I agree -- from a programmer's and DBA's perspective -- that it should never matter just where the data is stored. No traces in the code of the location, and all that. But from a security perspective, such ease of access (and lessened effort by programmers) is decidely dicey. One doesn't want one's data to be transparently accessed by <whomever> to be used <however>. And abstracting the access control away from the programmer (to some spiffy crypto based access control system -- three headed dogs anyone?) has its own problems. Things are now being handled by two separate apparti, with differing briefs, and ... Well you can see how that can go. So I sympathcize, but recognixe other issues.

But all of this is obiter dicta for the purposes of this article. MUMPS is not an ideal language for some purposes, but is sensible for some others. Among its minor virtues is easy syntax for accessing data on other systems, admittedly other MUMPS systems and not just any old CSV flat file somewhere. But this is not specially problematic, as most other languages have similar problems. That's the reason for all those messy middle ware specs that were to unify the world and have. By the way, am I talking with one person (Saint) or two (Saint and 169.237...)? ww (talk) 20:12, 5 June 2008 (UTC)

Oh, 169.237.249.166 was me, I just hadn't signed in. Even from a security perspective, access control should probably happen before your app is started. Or, each app shouldn't be reinventing the security framework. Any DBMS (including Fileman) allows you to specify access controls at the database level. Provided you use the API you'll never have to worry about some app that bypasses the security model to retrieve data directly from a global on a networked system. Your system isn't easier to manage when a dozen programmers have written a hundred apps that write directly to remote nodes, and now you've decided you want an access check in front of all of them. However, I did add a section to the summary indicating how the language makes it easy to do so, and it should have a longer section on the syntax page. Saintly (talk) 20:18, 6 June 2008 (UTC)

MUMPS can't "easily" generate HTML - you have to put write statements in front of every line and deal with line length limitations. You can't even build entire pages in a variable due to variable size limitations. There's templating languages that are designed for that sort of thing that can probably say they "easily generate HTML and XML", but MUMPS isn't one of them. MUMPS doesn't even read .csv files "easily" if they have embedded commas:

 "smith, john",12,14,20,11/22/1966

but I left the claim in, since it's true of very simple files. I guess.

Good point, but there are similar issues with many other languages. MUMPS is not specially vicious in this respect, just not as easy as some special purpose languages are. This too is a point which perhsp belongs in the article. ww (talk) 21:25, 30 May 2008 (UTC)

No, but this point keeps creeping back onto the page for some reason. I suppose someone could point out that MUMPS is pretty average in it's support of reading/writing CSV, HTML and XML, but why point out the average-ness? Most languages have equal trouble with doing these tasks, and deal with it in different ways. 169.237.249.166 (talk) 17:20, 5 June 2008 (UTC)

Moved the language summary to a new page, so it can grow and thrive.

This is reification, albeit humorous. The language summary, if present at all -- and given MUMPS obscurity and simplicity it should be here -- belongs on the language page. To force the Gentle Reader to chase links to get an impression is not helpful, merely an obstacle. ww (talk) 21:25, 30 May 2008 (UTC)

Hmm... I wasn't very clear. Actually, I *left* the 'summary' part on the main page, and moved the details of the language (how procedure files are organized, variable scope details, and some other stuff to the new Syntax page). There seemed to be a lot of redundancy between the 'Summary' and the larger in-depth sections that came before it. 169.237.249.166 (talk) 17:20, 5 June 2008 (UTC)

Expanded & clarified the 'Summary' section to cover what was removed as well.

MUMPS does NOT have somehow have less "code bloat" than other languages, unless you count the rampant use of unscoped variables instead of parameter passing, single-letter variables and commands, and use of GOTO instead of loops as "space saving features" instead of "nightmares".

POV. And wrong. One letter variables and commands are optional, if pernicious. There are still people (large nrs of them) programming in Fortran, Lisp, and assorted assemblers, all of which are poisonous by the implied standard here. No language is perfect, most are annoying in multiple ways, and all do one or more things better than others. MUMPS is good at database sorts of things, has low typing requirements (even if one doesn't elect to use one letter names) many statements are pretty high level (more so than in say, C), ... It's not so good on code and data isolation, in accord with more recent ideas about program structure. But it's usable and widely used. This objection is really an objection of "perfection" ww (talk) 21:25, 30 May 2008 (UTC)

Yeah yeah, but I save my sarcasm for the talk page. =) I don't think too many shops are still writing code that looks like Fileman (thank god), but there was a strange claim that MUMPS has grown up with less "code bloat" than other languages, whatever that means. No cite, no example, just some guy's opinion. Likely a guy that never dug into the Fileman internals, or saw a routine more than 3 years old. I wouldn't consider "code bloat" to be bad these days, space-saving 'features' like having functions fall into other functions because you didn't 'QUIT', or allowing people to jump into the middle of your routine with 'func+2^rtn' are now safely in the realm of "pointless disk space hacks". Hopefully also in the realm of "shootable offenses for programmers". 169.237.249.166 (talk) 17:20, 5 June 2008 (UTC)

Saintly (talk) 10:11, 27 May 2008 (UTC)

Apparently undiscussed removal

Out of idle curiosity, why didn't anyone notice this removal, which appears to have been done with no discussion? Just because something is disputed for a few months and people forget about it doesn't mean it gets to vanish. If something is broken, clean it up if possible, don't just trash it without discussion. --Thinboy00 @177, i.e. 03:14, 11 December 2008 (UTC)

Do you think there was any useful information in there? An "opinion" section on this page tends to bloat up with unsourced opinions. MUMPS diehards/hardheads/people who don't understand modern database concepts add their justifications for why they never learned to use a proper database. Then the eggheads with their fancy-schmancy "math degrees" start yammering about their "relational" concepts and how their high-powered 6-figure-license databases have totally rendered MUMPS obsolete. Then the technazis jump in with how their johnny-come-lately languages (ie, anything invented in the past 30 years, like C) can do everything MUMPS can do, but in a faster and more elegant way. Then the diehards chip in again with how their non-MUMPS vendor-specific workarounds and patches to their MUMPS interpreter give them all the goodies they'll ever need. Then it all goes around again. Then the "opinion" section bloats up to 90% of the article, then some MUMPS hardcase who can't think of any more arguments removes it all "to save space".

There's also no real debate. Who's seriously considering MUMPS instead of MS SQL Server or Oracle for brand new app development? The only reason anyone uses MUMPS anymore is because they have a legacy MUMPS app to support. MUMPS advocates are convincing no-one that their language has any modern relevance. Modern language advocates likewise aren't going to convince MUMPS programmers to convert their 2-million-line epic-scale MUMPS app to SQL.

Other than that, why don't you start another "Opinion" section and see what happens?  :) Saintly (talk)

It's just that now (or last time I more than skimmed it anyway) the article seems (seemed) to be ~exclusively/mostly positive or neutral, which would appear to exclude half the people you just mentioned, along with the (not a WP:RS, but bear with me) folks at The Daily WTF (who hate it [1]). --Thinboy00 @834, i.e. 19:01, 2 January 2009 (UTC)

The reasons Saintly gives for supporting removal of this seciton are themselves POV, the POV of someone who has learned his database chops in a later era. MUMPS is the basis of the largest medical database (critical to patient treatment and survival) project in the world (Fileman/VISTA and derivatives at the VA, IHS, and DoD) and is performing quite well by all accounts, despite the opaque programming style of the original Fileman code. There is indeed debate, despite Saintly's evaluation, and difference of opinion too, which is not now addressed at all.

In any case, the removed section provides perspective useful to the Reader for whom we are editing and so is a worthwhile part of a proper WP article. For languages as old as MUMPS, much comment is merely received classroom wisdom (or prejudice), and not particularly informed. Unlike many older languages (eg, BCPL, or Jovial, or ...) MUMPS is still widely and usefully deployed. That fact is sufficiently anomalous, amongst old languages, that this article is deficient if it does not address the point. This section did so, sort of.

I'd say we need to reincoporate the content, if not the exact phrasing in the defunct section. ww (talk) 21:01, 2 January 2009 (UTC)

I agree that there is disagreement as to the usefulness/worth of MUMPS, but I would like to note that just because a company is doing something does not mean that decision is the optimal way to do it. It merely means that from the company's point of view, the short term benefits of changing to an (apparently) more optimal system (if one exists) do not outweigh the costs of switching (which should be substantial in the case of MUMPS b/c it is nothing like e.g. C or other popular languages (is it even imperative?) and thus more effort is expended in switching). So just because MUMPS is widely deployed doesn't mean it is a valuable language compared to e.g. SQL, it simply means a lot of companies decided some time ago that of the options they knew they had, MUMPS appeared to be the optimal one, or at least the lesser of N evils. OTOH, they chose MUMPS for a reason, and there is no reason to assume that they were misinformed or incompetent. We need to show both of those viewpoints, assuming both are notable and not just original research that I made up on the spot (which may turn out to be the case...). --Thinboy00 @019, i.e. 23:26, 2 January 2009 (UTC)

Note:I have tagged the article with {{npov}} in reference to this discussion. I don't know if this can be called a "dispute", but it looks like me and at least one other person agree that the article in its current form is biased. Revert if I'm wrong. --Thinboy00 @026, i.e. 23:37, 2 January 2009 (UTC)

Yes, I think you're wrong. Wikipedia articles are supposed to have neutral point of view, not balanced positive and negative points of view. All the arguments I see on this page advocate including all points of view (negative and positive) instead of the required neutral point of view. Your tag seems to have been placed as a protest that unsupported negative (or positive) POVs have been removed. That's silly. You know, you can always do a sub article just for the opinion section. I'd wager it gets a speedy delete. Perspectoff (talk) 18:56, 17 April 2009 (UTC)M

There's definitely some large apps being run on a MUMPS database. However, they're almost all very old and too large to convert easily to another language. Even the VA tried to abandon MUMPS for their EMR at one point, but gave up when it looked like too big a task. Is there even one external source (reliable or not) suggesting that brand new applications should be written in M? It has no OO features (now widely believed to be essential for any large app), no relationship to any language still being taught in school, and not even the humble 'while' loop. Even the only vendor selling it doesn't mention it; Cache lets you write your code entirely in Java. If there's a debate, where's the comparison studies? How does a MUMPS-based DBMS compare to Oracle? How does a hand-coded, global-using MUMPS app compare to a C program that similarly bypasses the DBMS layer of a SQL database? Where's the ongoing development of the language? I'm pretty sure that no-one even implements the 1995 standard, which was mostly about dealing with the windowing system. Does any professional software reviewer see any benefits you would get from choosing MUMPS over a solution that is more easily maintainable? If you can find these answers in magazines or online articles, then by all means... let's make a decent 'Opinion' or 'Pros and Cons of MUMPS' section. Otherwise, the only debate is on Wikipedia itself, between a bunch of anonymous screen names. Saintly (talk) 12:16, 4 January 2009 (UTC)

<- I understand the position, but it is POV. That you don't see much virtue in MUMPS and can rationally defend that position is all good, but not grounds for deleting WP content which is not blatantly POV. For instance, Intersystems may not mention MUMPS in its sales literature, but this could be due to many reasons, including a tradition at Intersystems of preferring M. Only one possible explanation is that Intersystems is stuck with a product line they don't want to expose as based on passe technology. OO is indeed the flavor of the week (or longer), but, like all other software paradigm advances I can recall, is not likely to be the last word in design approaches. That the herd has moved is not compelling evidence of a proper decision by some neutral and omniscient observer. I think we still don't have sufficient reason to delete that section, your advocacy notwithstanding. ww (talk) 20:24, 4 January 2009 (UTC)

I'm not against having a "pros and cons" section, but I'm just not clear on what you'd plan to put in it. My point was that there doesn't seem to be any discussion of MUMPS or research into it's merits going on-- anywhere. The reasons for not just bringing back any of the previous versions of the "opinion" section are that they contain absolutely no references, citations or even original research to back up the opinions. There was just useless crap like "Dick Walters [an MDC member and MUMPS advocate] says that MUMPS is the best-kept secret in IT", or "Saintly says MUMPS sucks and is a pain to work in". I could be wrong, but I don't think these random observations and quotations are very encyclopedia-worthy. Saintly (talk) 22:49, 6 January 2009 (UTC)

What's going on here? "Pros and Cons" doesn't play into it; no one is evaluating MUMPS as a seriously as a choice for new development. The reason MUMPS still exists is the reason COBOL still exists: legacy systems. Not just the VA/DoD, though. M is used by other major EMR vendors and major financial institutions (Epic, Fidelity, AmeriTrade, more here and here) who collectively have tens, if not hundreds of millions of lines of MUMPS code. That's not really the point, though. Checking the articles for other languages, such as C or Python shows no similar section. COBOL has "Criticism" and "Defense" sections, which seems inappropriate for an encyclopedic article, much like this one did. Leave it out. 216.165.132.252 (talk) 16:29, 7 January 2009 (UTC)

I don't see any point in reestablishing an "Opinions" or "Pros and Cons" section either. Opinions aren't encyclopedic, and pros and cons are pointless for a language this old, as 216.165.132.252 points out so well. I looked at what was removed, and none of it was cited or referenced. Whoever removed it did us a favor, IMNSHO. Just let it go... — CWesling (talk) 21:35, 11 November 2009 (UTC)

Cause following effect?

"Because it predates C and most other popular languages in current usage, it has very different syntax and terminology. " It doesn't follow. Accepting that M predates C, it would be at least as sensible to say that although C followed M/Mumps, very different syntax and terminology were chosen for C by its designers. It would not be senible to say that this was becuase C followed M, I'd assume that the designers made choices that seemed good to them, for their own reasons. I'd suggest that the sentence is either discarded, or is altered to something similar to: "Mumps predates C " (in case anyone can't decide form the dates given for the start of the two, which came first) "The syntax of M is very different from C". (in case anyone can't tell that from looking at the syntaxes. Actually, it would be best left out, would it not? Midgley (talk) 23:06, 30 March 2009 (UTC)

Actually, probably not. MUMPS is a little known language and this comment relates some aspects of it to a much better known language. In the process explaining, for non-MUMPS heads, that its differences are not an aberration in an era of block structured languages (and so aberrational in a bad way), but arise from the history and so look of perfectly plausible reasons. Reading this comment as a logical cause and effect is misplaced. But if you can word it in such as way as to not misled logically while making the same points on behalf of the Gentle Reader, please be bold. ww (talk) 00:58, 31 March 2009 (UTC)

PDP-8 Version?

Is anyone aware of a port to the PDP-8? I see a number of references worded exactly the same as in the body of this posting but I am not aware of a PDP-8 version. It was built on the PDP-7 and ported to the PDP-9 and PDP-15 and briefly to the PDP-11. I propose to remove the PDP-8 reference and replace it by the PDP-9 and PDP-15, I think the original reference was a typoLawrence1957 (talk) 21:49, 14 April 2010 (UTC)

There is no sign of PDP-8 version in DEC history document 1957-1978, though PDP-15 and PDP-11 are present. This predates the VAX, and its version.

This is the source:

From the bitsavers.org collection, a scanned-in computer-related document.

dec :: Books :: DEC 1957 To The Present 1978

Digital Equipment Corporation, 1957 To The Present [1978]

https://archive.org/stream/bitsavers_decBooksDE78_60225737/DEC_1957_To_The_Present_1978#page/n25/mode/1up/search/MUMPS

Lent (talk) 22:23, 17 May 2014 (UTC)

Sample code

It seems regrettable that the article does not contain an example of good, straightforward, intelligible MUMPS coding practice. The FILEMAN example is a fair representative of what might be called "old-school" coding style; the others border on tricks or intentional obfuscation.

I've personally been away from MUMPS for too long to have an example to supply. Dpbsmith (talk) 23:03, 15 June 2010 (UTC)

• The %DTC code example is terrible. It's a date library function which is far from typical, and doesn't contain a single global reference. 80N (talk) 06:21, 23 September 2010 (UTC)
• Can't seem to get a good wraparound print of this article (MUMPS invariably has been consistent in this problem creation). Using the Wikipedia Print version, on either Chrome or ie9, the GREPTHIS boxed subroutine is cut off on the NEW'ed variables line.
  • Am not an expert in the boxing portion to make this correction. Regular article text does not appear to be cutoff in the same regard using ie9. BrianLAmmon (talk) 18:58, 14 March 2012 (UTC)

Here is a better article on MUMPS

When your article is less informative than the DailyWTF article on the same topic, you know you're doing it wrong. — Preceding unsigned comment added by 109.38.97.175 (talk) 16:16, 16 September 2013 (UTC)

Nope. See the (exhaustive) debate in this talk page and MUMPS/Archive01, for why people decided criticism of MUMPS didn't belong here. It'd be nice if the page linked to that post though, since a DailyWTF post about a language is pretty notable, but I'm having trouble thinking of a way to do it neutrally. Publicly Visible (talk) 18:27, 7 July 2014 (UTC)

OK, I added a link to The Daily WTF. And, well, made a new Criticism section. But don't panic! I put it as a subheading under "Summary of key language features" and didn't actually include any of the criticisms, which is hopefully more WP:NPOV. Someone said above that The Daily WTF isn't WP:RS but I think it falls under a source that's biased but still important enough to be worth including. I think as long as we stick with things like "The Daily WTF wrote about it" as opposed to "The Daily WTF wrote about it and that means it's bad" we'll be fine. Publicly Visible (talk) 19:25, 7 July 2014 (UTC)

Looks like it has been Orwell'd, there is currently no mention of the daily WTF in the article.Medinoc (talk) 10:00, 14 October 2016 (UTC)

$PIECE Example in "Summary of key language features" restructured

I am not a MUMPS programmer, but I revised the $PIECE example. In particular, I moved this in front of the PIECE example that uses SET.

  $PIECE("world.std.com",".",2) yields "std".

The example has no dependency on the SET X portion which had preceded it. This MUMPS code seems to be equivalent to the following AWK example:

echo 'world.std.com' | awk 'BEGIN{FS="."};{print $2}'

yielding

std

The example MUMPS code that follows:

SET X="dpbsmith@world.std.com"

SET $P(X,"@",1)="office" causes X to become "office@world.std.com"

seems to be equivalent to the following AWK code.

echo 'dpsmith@world.std.com' | awk 'BEGIN{FS="@";OFS=FS};{$1="office";print}'

which yields:

office@world.std.com

Lent (talk) 21:49, 17 May 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on MUMPS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.sanchez.com/news_2000/nr_001107.asp

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 16:01, 2 July 2016 (UTC)

Criticism section needed

This article should have a criticism section for completeness and usability. The lack of criticism about MUMPS makes this article appear opinionated and non-objective. This is of particular importance for non-technical readers. The DailyWTF article previously referenced in the talk section is perhaps biased.

Other important programming language articles such as the one on C++ and JAVA have criticism sections. — Preceding unsigned comment added by 104.34.69.100 (talk) 18:47, 20 December 2017 (UTC)

A practical criticism of using MUMPS and/or MUMPS/CACHE based systems is the lack of trained and experienced programmers. Would this belong in the criticisms section, or under its own title? — Preceding unsigned comment added by 2605:E000:1702:40B5:45AA:696:E6A7:DDE (talk) 18:03, 23 October 2019 (UTC)