Talk:MUMPS/Archive01

message: 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)
thread_title: Older talk page comments

message: 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)
thread_title:  "Higher level" layer? 

message: 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)
thread_title: History section restructured

message: :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)
thread_title: The MUMPS database (section removed from main article)

message: 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)
thread_title:  "Best kept secret" 

message: 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)
thread_title:  Revised, with Criticisms 

message: three, four, etc. sets of equals signs, e.g.
===this creates a third-level subsection===
Dpbsmith (talk) 21:06, 18 November 2005 (UTC)
thread_title: by using

message: --AGlassman 04:23, 10 February 2006 (UTC)
thread_title:  M-Global Mumps History 

message: 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)
thread_title:  Reverted without reading? 

message: 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)
thread_title:  Discussion of specific changes: 

message: 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)
thread_title:  MUMPS the amazing XML Parser 

message: 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)
thread_title:  Talk page getting large