Talk:MUMPS

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)[reply]

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)[reply]

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.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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