Why MUMPS Failed (Henry was right.)
Charlie-Boo
appellants to ANSI were programmers and very small implementers.) No
big implementer would propose making fundamental or backwards
incompatible changes. But that is exactly what MUMPS needed. The
basic data type should have been arrays and the intrinsic functions
should have been array manipulations instead of string manipulations.
IF-ELSE should have been fixed.
The MDC optimized the short term rather than the long term. In the
end, it was good old short term thinking. And the long term has now
arrived.
Charlie Volkstorf
Henry was right.
Denver Braughler
> IF-ELSE should have been fixed.
A few months ago I discussed this in InterSystems' newsgroup.
M's IF and ELSE allow building structures that are very relevant to programming
but that don't appear in other structured languages or that require more nesting
in other languages.
Unfortunately, there are tradeoffs, one of which is that behavior is controlled by
$TEST.
In other languages one typically has to repeat tests or declare and maintain a
flag variable to emulate $TEST.
Charlie-Boo
> Charlie V wrote:
> > IF-ELSE should have been fixed.
>
> A few months ago I discussed this in InterSystems' newsgroup.
>
> M's IF and ELSE allow building structures that are very relevant to programming
> but that don't appear in other structured languages or that require more nesting
> in other languages.
What "structures don't appear in other languages"?
> Unfortunately, there are tradeoffs, one of which is that behavior is controlled by
> $TEST.
> In other languages one typically has to repeat tests or declare and maintain a
> flag variable to emulate $TEST.
Ok, how about an example? Assume the standard IF/ELSE/ELSEIF and
{...} for nesting in the other languages.
I remember a National MUG/MTA Meeting at which the MDC was complaining
that there was a "conspiracy" among Computer Science professors to not
teach MUMPS. I sat there quietly wondering why any professor would
teach principles of programming using a programming language that is
different from the other 90%, especially with known problems with
something as fundamental as IF/ELSE (believe it or not - I mean the
"quiet" part.)
You realize, of course, the real reason that MUMPS does it that way?
Overall, which way do you feel is better?
Charlie Volkstorf
Christopher Browne
> Denver Braughler <aa.DBrau...@aa.bwcc.com> wrote
>> Charlie V wrote:
>> > IF-ELSE should have been fixed.
>>
>> A few months ago I discussed this in InterSystems' newsgroup.
>>
>> M's IF and ELSE allow building structures that are very relevant to
>> programming but that don't appear in other structured languages or
>> that require more nesting in other languages.
>
> What "structures don't appear in other languages"?
As an outsider to Mumps... That seems an interesting claim to me,
too.
>> Unfortunately, there are tradeoffs, one of which is that behavior is controlled by
>> $TEST.
>> In other languages one typically has to repeat tests or declare and maintain a
>> flag variable to emulate $TEST.
>
> Ok, how about an example? Assume the standard IF/ELSE/ELSEIF and
> {...} for nesting in the other languages.
>
> I remember a National MUG/MTA Meeting at which the MDC was
> complaining that there was a "conspiracy" among Computer Science
> professors to not teach MUMPS. I sat there quietly wondering why
> any professor would teach principles of programming using a
> programming language that is different from the other 90%,
> especially with known problems with something as fundamental as
> IF/ELSE (believe it or not - I mean the "quiet" part.)
>
> You realize, of course, the real reason that MUMPS does it that way?
>
> Overall, which way do you feel is better?
Sounds to me like this might be vaguely similar to APL "reduction",
although that's a wild wild guess.
It sure sounds like a case where MUMPS has adopted some sort of
"idiom" that some fans are misrepresenting as being somehow
'fundamental to computing.' The idiom may be "convenient to their
application," but that certainly does NOT establish that it is some
new form of logic.
- Continuations (as used in Scheme implementations) are a pretty
unique form of control structure that are of academic interest.
- The lexical bindings known as "LET" structures in both Lisp and ML
are interesting control structures well worth studying.
- The last time I saw something claiming to be a new sort of 'control
structure' was the presentation of "PanCode," which was a kind of
'visually composable' set of condition and loop control structures.
If no one has heard of them, that shows to what degree they "set the
world on fire."
- A lot of the 'scripting' languages have adopted accessor/collection
schemes that allow really efficient walks through hash tables via
something like Perl's
while (($key,$value) = each(%TABLE)) {
# do something with table's contents
}
- Perl has thrown in the ability to attach pretty wild modifications
of 'parsing' logic via fiddling with environment variables.
Some of those items are 'control structures' worthy of a week's study;
others are simple enough to explain that several could be covered in a
day. If someone decides that the control structures of MUMPS are so
necessarily special that they cannot be explained in terms people
using other systems can understand, that's likely to minimize public
interest...
--
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];;
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
Denver Braughler
> What "structures don't appear in other languages"?
> > Unfortunately, there are tradeoffs, one of which is that behavior is controlled by
> > $TEST.
> > In other languages one typically has to repeat tests or declare and maintain a
> > flag variable to emulate $TEST.
>
> Ok, how about an example? Assume the standard IF/ELSEIF/ELSE and
> {...} for nesting in the other languages.
I've been there, done that, proved the point.
Feel free to join the ISC board and challenge me were every proponent of the
block structure conceded.
> Overall, which way do you feel is better?
Each has its merits and demerits.
I happen to prefer the one that is shorter to use in practice.
paul perrin
arrays etc... (irony alert).
Personally I wouldn't suggest PERL is a good language to learn first from
the academic POV-- but it has found its own (massive) niche.
Paul /)/+)
"Charlie-Boo" <ch...@aol.com> wrote in message
news:3df1e59f.04030...@posting.google.com...
Denver Braughler
> > What "structures don't appear in other languages"?
>
> As an outsider to Mumps... That seems an interesting claim to me,
> too.
ElseSoFar and IfAny from IF/ELSEIF/ELSESOFAR/ELSEIF/IFANY/ELSE.
> It sure sounds like a case where MUMPS has adopted some sort of
> "idiom" that some fans are misrepresenting as being somehow
> 'fundamental to computing.' The idiom may be "convenient to their
> application," but that certainly does NOT establish that it is some
> new form of logic.
You are really rude.
Only "IF" is fundamental.
The only misrepresentation is yours.
> If no one has heard of them, that shows to what degree they "set the
> world on fire."
Always judge a matter before you hear it.
That way you never have to rethink your position.
> If someone decides that the control structures of MUMPS are so
> necessarily special that they cannot be explained in terms people
> using other systems can understand, that's likely to minimize public
> interest...
If that leaves out you, we won't miss the publicity.
So what brought you to our group?
Charlie-Boo
> Charlie-Boo wrote:
> > What "structures don't appear in other languages"?
> IF/ELSEIF/ELSESOFAR/ELSEIF/IFANY/ELSE.
You wrote: "M's IF and ELSE allow building structures that are very
relevant to programming but that don't appear in other structured
languages."
# 1. How does M's IF and ELSE allow us to build ELSEIF, ELSESOFAR,
IFANY - what do they mean, anyway? Can you show how to express them
using M's IF and ELSE?
# 2. What structured languages don't include IF or ELSE (in your list
above)?
> > > In other languages one typically has to repeat tests or declare and
> > > maintain a flag variable to emulate $TEST.
> >
> > Ok, how about an example? Assume the standard IF/ELSEIF/ELSE and
> > {...} for nesting in the other languages.
>
> I've been there, done that, proved the point.
With all due respect, you haven't - not here, anyway. Is there some
specific publication that you'd like to refer us to instead? Even
then, if you're going to make an assertion here, especially one that
refutes someone, I think it only fair that you substantiate it here.
> > Overall, which way do you feel is better?
>
> Each has its merits and demerits.
> I happen to prefer the one that is shorter to use in practice.
That is one gauge, which remains undemonstrated.
Charlie Volkstorf
Denver Braughler
> # 1. How does M's IF and ELSE allow us to build ELSEIF, ELSESOFAR,
> IFANY - what do they mean, anyway? Can you show how to express them
> using M's IF and ELSE?
K D,Y S C=$$c(1) D Dinit(.D)
I A S Y=$$a(1)
E I B S Y=$$b(2)
I D c(Y,.C) ;IFANY
E I C?1.N S Y=$$d(C,3),C=C-1
E S Y=$$d(C,10) D e(C,.D) ;ELSESOFAR
E I D(C)<14 S Y=$$f(4)
E S Y=$$g(D(Y)+7)
D h(Y,.D)
Note as I stated before: there is no nesting (the five cases are at
the same logical level in the code just as in reality) nor any
repeated condition (even indirectly through a state variable).
> # 2. What structured languages don't include IF or ELSE (in your list
> above)?
I made no such claim.
> With all due respect, you haven't - not here, anyway.
With all due respect, you often play Calvinball at times like this.
So while I appreciate your intelligence, I have no reason to invest
in such an effort on this forum.
> if you're going to make an assertion here, especially one that
> refutes someone, I think it only fair that you substantiate it here.
I agree. But not everyone else agrees.
Otoh, if you didn't already have your mind made up, and really cared to
know, you might make the investment to find out.
I'm not here to sell you anything.
If you want to know, I've given you an easy way to find out.
If you don't want to know, I've given you an easy way out.
Charlie-Boo
> Charlie V wrote:
> > # 1. How does M's IF and ELSE allow us to build ELSEIF, ELSESOFAR,
> > IFANY - what do they mean, anyway? Can you show how to express them
> > using M's IF and ELSE?
>
> K D,Y S C=$$c(1) D Dinit(.D)
> I A S Y=$$a(1)
> E I B S Y=$$b(2)
> I D c(Y,.C) ;IFANY
> E I C?1.N S Y=$$d(C,3),C=C-1
> E S Y=$$d(C,10) D e(C,.D) ;ELSESOFAR
> E I D(C)<14 S Y=$$f(4)
> E S Y=$$g(D(Y)+7)
> D h(Y,.D)
>
> Note as I stated before: there is no nesting (the five cases are at
> the same logical level in the code just as in reality) nor any
> repeated condition (even indirectly through a state variable).
You are nesting the IFs and ELSEs. But more to the point, how does
MUMPS' IF and ELSE allow this - why wouldn't normal IF and ELSE work?
And doesn't the D e(C,.D) (in general) risk resetting $T (the whole
problem with MUMPS' IF and ELSE)?
(This also illustrates the effort that it takes to follow the nesting
of the IFs and ELSEs above. In any block structured language, the IFs
and ELSEs would be delineated by {}.)
> > # 2. What structured languages don't include IF or ELSE (in your list
> > above)?
>
> I made no such claim.
You: "M's IF and ELSE allow building structures that are very relevant
to programming but that don't appear in other structured languages."
Me: "What structures don't appear in other languages?"
You: "IF/ELSEIF/ELSESOFAR/ELSEIF/IFANY/ELSE."
> With all due respect, you often play Calvinball at times like this.
What does that mean and when did I do that?
Charlie Volkstorf
Denver Braughler
> Denver Braughler wrote:
> > Charlie V wrote:
> > > # 1. How does M's IF and ELSE allow us to build ELSEIF, ELSESOFAR,
> > > IFANY - what do they mean, anyway? Can you show how to express them
> > > using M's IF and ELSE?
> > K D,Y S C=$$c(1) D Dinit(.D)
> > I A S Y=$$a(1)
> > E I B S Y=$$b(2)
> > E I C?1.N S Y=$$d(C,3),C=C-1
> > E I D(C)<14 S Y=$$f(4)
> > E S Y=$$g(D(Y)+7)
> > D h(Y,.D)
> >
> > Note as I stated before: there is no nesting (the five cases are at
> > the same logical level in the code just as in reality) nor any
> > repeated condition (even indirectly through a state variable).
>
> You are nesting the IFs and ELSEs.
> But more to the point, how does MUMPS' IF and ELSE allow this - why
> wouldn't normal IF and ELSE work?
I welcome your re-write in you favorite Pascal or C-like language.
> And doesn't the D e(C,.D) (in general) risk resetting $T (the whole
> problem with MUMPS' IF and ELSE)?
No, a simple I 0 or I 1 suffix clears that up.
> (This also illustrates the effort that it takes to follow the nesting
> of the IFs and ELSEs above. In any block structured language, the IFs
> and ELSEs would be delineated by {}.)
As I said, I await your re-write.
I find the above M version very easy to follow.
> > > # 2. What structured languages don't include IF or ELSE (in your list
> > > above)?
> > I made no such claim.
> You: "M's IF and ELSE allow building structures that are very relevant
> to programming but that don't appear in other structured languages."
> Me: "What structures don't appear in other languages?"
> You: "IF/ELSEIF/ELSESOFAR/ELSEIF/IFANY/ELSE."
Yeah, and?
That refers to two structures: IF/ELSESOFAR/ELSEIF (which is really useful
only is a more complex structure - otherwise it is a case of IF/ELSE
with a nested IF that is also readily expressed in other languages) and
IF/ELSEIF/IFANY.
My answer *action* be decomposed to mean that "IF or ELSE" doesn't appear
in another language.
"ELSE" is not even a structure. It's a command.
And it is absurd to think that I was saying that MUMPS has "IF" whereas
other languages don't.
I await your evidence that these structures appears elsewhere.
Show me an IF/ELSEIF/ELSESOFAR/ELSEIF/IFANY/ELSE structure in another language.
> > With all due respect, you often play Calvinball at times like this.
> What does that mean
That means that you will change the rules to suit you as the game progresses.
> and when did I do that?
Charlie-Boo
> > > Unfortunately, there are tradeoffs, one of which is that behavior is
> > > controlled by $TEST.
> > > In other languages one typically has to repeat tests or declare and
> > > maintain a flag variable to emulate $TEST.
> >
> > Overall, which way do you feel is better?
>
> Each has its merits and demerits.
> I happen to prefer the one that is shorter to use in practice.
1. Increment a Counter:
M: S N=N+1
PHP: ++$N
2. Add to a list:
M: S N=N+1,P(N)=A
PHP: $P[]=$A
3. Traverse a sparse ("associative") Array:
M: S A="" F S A=$O(P(A)) Q:A="" D T(A)
PHP: foreach ($P as $A) T($A)
M takes 75%, 100% and 54% more code, respectively (average = 76%.)
(Note that # 3 would be even worse in M if I hadn't proposed the
argumentless FOR command, but would be even better if they had also
accepted my array manipulation proposal! I guess array manipulation
was too radical an idea for the MDC.)
You can learn PHP at http://www.php.net/manual/en/index.php .
Charlie Volkstorf
Charlie-Boo
> Charlie W wrote:
> > Denver Braughler wrote:
> > > Charlie V wrote:
> > > > # 1. How does M's IF and ELSE allow us to build ELSEIF, ELSESOFAR,
> > > > IFANY - what do they mean, anyway? Can you show how to express them
> > > > using M's IF and ELSE?
> > > K D,Y S C=$$c(1) D Dinit(.D)
> > > I A S Y=$$a(1)
> > > E I B S Y=$$b(2)
> > > I D c(Y,.C) I 1 ;IFANY
> > > E I C?1.N S Y=$$d(C,3),C=C-1
> > > E S Y=$$d(C,10) D e(C,.D) I 0 ;ELSESOFAR
> > > E I D(C)<14 S Y=$$f(4)
> > > E S Y=$$g(D(Y)+7)
> > > D h(Y,.D)
> > > With all due respect, you often play Calvinball at times like this.
> > What does that mean
> That means that you will change the rules to suit you as the game progresses.
>
> > and when did I do that?
> <http://groups.google.com/groups?th=fff030315c1b7aaf>
You take a joke that ridicules the absurdity of asking for minutes to
MDC meetings that occurred 25 years ago, and use it in an attempt to
attack my character? My my . . . I critique MUMPS and you critique
me. Just like the MDC! (And where are all of the other examples
where I "often play Calvinball . . . change the rules"? According to
Google, I have posted to this group at least 50 times. You should
have plenty of examples if it so often. Where are they?)
Actually, it isn't a question of what you or I prefer. The question
was why the rest of the world doesn't prefer MUMPS. I just maintain
that problems like IF-ELSE not working right do have an impact on the
popularity of the language (despite the fact that you and I are used
to it and even accept it.)
So you are far removed from the original question, not only in your
"attack the messenger" approach, but in terms of the burning question:
Why don't more people use MUMPS?
I also noticed that your original example of superior MUMPS code using
IF-ELSE and DO was:
I D c(Y,.C) ;IFANY
E I C?1.N S Y=$$d(C,3),C=C-1
E S Y=$$d(C,10) D e(C,.D) ;ELSESOFAR
which when responded to naturally became:
> I D c(Y,.C) ;IFANY
> E I C?1.N S Y=$$d(C,3),C=C-1
> E S Y=$$d(C,10) D e(C,.D) ;ELSESOFAR
but when I pointed out the potential problems with the DO it became
(above):
> > I D c(Y,.C) I 1 ;IFANY
> > E I C?1.N S Y=$$d(C,3),C=C-1
> > E S Y=$$d(C,10) D e(C,.D) I 0 ;ELSESOFAR
and I 1 and I 0 (top and bottom lines) mysteriously appeared to fix
it, in the midst of "quoted" (by virtue of the > and > > indentations)
messages! Now we're rewriting history!
This is a good example of what I was saying. Even when we're talking
about the problems with IF-ELSE and an experience programmer shows how
to correctly use it, the problem still occurs - under the best of
circumstances, no less.
Also, the fact that the ELSE in the 3rd line can be the complement to
the IF in either the 1st or the 2nd line is one of the things that
confuses programmers, IMHO. Or should I say the two IFs in the 1st
line or the one IF in the 2nd line - gad!
Now speaking of "changing the rules" (or should I say, "changing the
code"?) . . . Maybe you can explain how this game of Calvinball works.
You seem to play it so well.
Charlie Volkstorf
(But unfortunately not good enough to keep from getting caught! LOL
:-)
if ($d) e($y,$c)
elseif (int($c)) {$y=d($c,3) ; --$c}
else {$y=d($c,10) ; e($c,$d) ;
Denver Braughler
> Denver Braughler wrote:
> > Charlie W wrote:
> > > Denver Braughler wrote:
> > > > With all due respect, you often play Calvinball at times like this.
> > > What does that mean
> > That means that you will change the rules to suit you as the game progresses.
> > > and when did I do that?
> > <http://groups.google.com/groups?th=fff030315c1b7aaf>
> You take a joke that ridicules the absurdity of asking for minutes to
> MDC meetings that occurred 25 years ago, and use it in an attempt to
> attack my character?
> (And where are all of the other examples
> where I "often play Calvinball . . . change the rules"?
I think a single example suffices to rebut your denial.
> According to Google, I have posted to this group at least 50 times. You should
> have plenty of examples if it so often. Where are they?)
And I do.
> So you are far removed from the original question
I was answering your questions.
I didn't change the subject.
> Maybe you can explain how this game of Calvinball works.
Like this:
Armin van Harten
I followed your hot discussion about a dead horse now for several days, but
for MHO you both did not get to the point. First I think, it is academic to
compare an imperative language of the 70's with an object oriented language
of the 90's. But as we can see in your discussion, it was not this or that
single language element wich caused the dead of the M movement. Programming
itself, the strategy, changed through the 90's and all, except the Mumpster
recognized it. So it came that M still has no standardized way to link in
third party libraries or encapsulated particular structures. !! (there are
some weak proprietary approaches but they do not help)
When I write a Delphi program, not more than 20% of the program is my own.
The rest is written by some unknown professionals and this way I can write
stuff far beyond my personal knowledge (like mediaplayers or WYSISWYG
wordprocessors etc). In M I usually write 90% of the program, and if I
don't know how, there is, well I don't know who. Google usually does not
help the Mster. So it happends, that although M is very effective, I can
write better progs in Delphi in almost the same time usimng third party
libraries and components. I've never seen a third party component library
for M in twenty years.
Charly, I can understand your frustration, but see, it was not IF/THEN/ELSE
wich killed the language, it was this type of caveman behaviour of the
protagonists of M. The ignorance of the importance of working together in
teams in the M scene. The complete ignorance of trends and findings of the
rest of the IT world for over ten years! No tool system, even the best, can
survive that.
I still think that there should be M in the future, because it is so
different from the rest, that it helps to think in different ways (just
like : The earth is not flat, and data are not naturally structured as
tables!). But my hopes that there would be a M-group or implementor wich
will go this way, are limited. So we will all meet at the microsoft booth
and talk about how fantastic SQL solves problems we would not have without
it.
Amen!
Have a good fight anyway but don't forget to shovel your peanutshells away
when you are through with it. If then else or what.
Armin van Harten
IfmD - consulting GmbH
Wetzlar, Germany
vanharten @ ifmd - consulting . deutschland
Charlie-Boo
> Charlie V wrote:
> > Denver Braughler wrote:
> > > Charlie W wrote:
> > > > Denver Braughler wrote:
> > > > > With all due respect, you often play Calvinball at times like this.
> > > > What does that mean
> That means that you will change the rules to suit you as the game progresses.
> > > > and when did I do that?
> > > <http://groups.google.com/groups?th=fff030315c1b7aaf>
> > You take a joke that ridicules the absurdity of asking for minutes to
> > MDC meetings that occurred 25 years ago, and use it in an attempt to
> > attack my character?
> No.
I consider changing the rules to be dishonest and thus such a
suggestion to be an attack on ones character. What else would be the
purpose of saying that someone "often changes the rules"?
> > (And where are all of the other examples
> > where I "often play Calvinball . . . change the rules"?
> I think a single example suffices to rebut your denial.
What did I deny? I only asked for you to substantiate your claim that
I "often change the rules". One (bogus) example among 50 posts over a
period of two years hardly constitutes "often".
> > According to Google, I have posted to this group at least 50 times.
>> You should have plenty of examples if it so often. Where are
they?)
> And I do.
Why not share them with us?
> > So you are far removed from the original question
> I was answering your questions.
> I didn't change the subject.
My original statement was an attempt to determine why more people
don't use MUMPS, not to survey why hardcore MUMPS enthusiasts like it,
or to impugn the character of anyone who disagrees.
> > Maybe you can explain how this game of Calvinball works.
>
> Like this:
> > if ($d) e($y,$c)
> > elseif (int($c)) {$y=d($c,3) ; --$c}
> > else {$y=d($c,10) ; e($c,$d) ;
I don't know if you are serious or not, but of course that is my
response to your request for how to code your example in PHP.
I am only interested in questioning why more people don奏 use MUMPS,
and, in that pursuit, to compare it to other, more popular programming
languages (especially since I have been using one of them to develop
web sites for the past couple of years.)
If you want to engage in character assassination and other mud
slinging, I would suggest that you join the Republican party - or
better yet, the MUMPS Development Committee.
Thank you for the enlightening conversation.
Charlie Volkstorf
Denver Braughler
> > > if ($d) e($y,$c)
> > > elseif (int($c)) {$y=d($c,3) ; --$c}
> > > else {$y=d($c,10) ; e($c,$d) ;
>
> I don't know if you are serious or not, but of course that is my
> response to your request for how to code your example in PHP.
It is incomplete.
Your lines and symbols don't correlate with those in my example.
Reversing yours, I get:
I D D e(.Y,.C)
E I C S Y=$$d(.C,3),C=C-1
E S Y=$$d(.c,10) D e(.c,.d)
The last two lines look like lines 5 and 6 in the middle of my example.
Where is the rest?
My example is:
Charlie-Boo
> Dear Charly Volkstorf and dear Denver Braughler,
>
> third party libraries or encapsulated particular structures. !! (there are
> some weak proprietary approaches but they do not help)
>
> wich killed the language, it was this type of caveman behaviour of the
> protagonists of M.
>
>
> Have a good fight anyway but don't forget to shovel your peanutshells away
> when you are through with it. If then else or what.
>
> Armin van Harten
> IfmD - consulting GmbH
> Wetzlar, Germany
>
> vanharten @ ifmd - consulting . deutschland
Armin,
I agree with (and thank you for) your thoughtful comments. MUMPS was
always a very closed system - originally developed without even an
operating system. I listed IF-ELSE as the problem that sticks out
like a sore thumb. My guess is that essentially every other mid-level
programming language there is handles IF-ELSE correctly (or at least
those widely accepted.)
Talking about IF-ELSE is sort of like a test case - of the person whom
you're debating. Anyone who defends it per se is really playing games
and ignoring reality. The truth is, IF-ELSE is that way (as you may
know) because MUMPS was originally interpreted and its developers felt
it too difficult (or they were too lazy) to keep track of the IF state
at various points through the execution of the program. Then, being
unable to make tough decisions, the MDC left it that way.
IF-ELSE is just one particular nuisance in MUMPS, but I think it goes
a long ways towards illustrating the general problems, then and now:
abnormal behavior in the language that turned off academics, a tough
decision that the MDC refused to make, and the mindset of idealogues
who claim that there is any kind of a technical, rather than
historical, justification for its being that way.
Charlie Volkstorf
Charlie-Boo
> Charlie V wrote:
> > > > if ($d) e($y,$c)
> > > > elseif (int($c)) {$y=d($c,3) ; --$c}
> > > > else {$y=d($c,10) ; e($c,$d) ;
> >
> > I don't know if you are serious or not, but of course that is my
> > response to your request for how to code your example in PHP.
>
> It is incomplete.
> Your lines and symbols don't correlate with those in my example.
> Reversing yours, I get:
> I D D e(.Y,.C)
> E I C S Y=$$d(.C,3),C=C-1
> E S Y=$$d(.c,10) D e(.c,.d)
>
> The last two lines look like lines 5 and 6 in the middle of my example.
> Where is the rest?
You miss the point. It doesn't matter how you use IF and ELSE, nobody
uses MUMPS anyway, you should give up and stop playing CalvinBall and
slinging mud, join the Army (now that's a real growth industry), stop
wasting people's time with your "examples" which have no use in the
real world, give up on this dinosaur "MUMPS" (when was the last time
anybody did anything useful with it, say, guide a missile with a
nuclear warhead or an unmanned predator drone looking for bin Laden?),
learn PHP like I did, cut your long hair, get out of the 1960's when
MUMPS was at its heyday (10-12 users), help to defeat the John
Kerry/Jane Fonda ticket and contribute to Pat Robinson and Jerry
Falwell so we can end all un-American perversions including that
abomination called MUMPS.
If you don't understand, then I'm sorry. I tried my best.
"To those who understand, no explanation is necessary. To those who
don't, no explanation will suffice."
(Study the above words well. It describes you EXACTLY.)
Charlie Volkstorf
PS I could code your "example" in PHP with about 4 characters, but why
bother - you'd never understand it anyway!
Denver Braughler
> Denver Braughler wrote:
> > Charlie V wrote:
> > > > > if ($d) e($y,$c)
> > > > > elseif (int($c)) {$y=d($c,3) ; --$c}
> > > > > else {$y=d($c,10) ; e($c,$d) ;
> > >
> > > I don't know if you are serious or not, but of course that is my
> > > response to your request for how to code your example in PHP.
> >
> > It is incomplete.
> > Your lines and symbols don't correlate with those in my example.
> > Reversing yours, I get:
> > I D D e(.Y,.C)
> > E I C S Y=$$d(.C,3),C=C-1
> > E S Y=$$d(.c,10) D e(.c,.d)
> >
> > The last two lines look like lines 5 and 6 in the middle of my example.
> > Where is the rest?
>
> You miss the point.
> It doesn't matter how you use IF and ELSE,
exist as simply in other languages is precisely the point.
> nobody uses MUMPS anyway,
Lots of people use MUMPS..
> you should give up and stop playing CalvinBall
Okay, Calvin.
> and slinging mud,
Imagine that coming from you.
> stop wasting people's time with your "examples"
You asked for it, you got it.
It's just one example, singular.
Not too long ago you were grousing because I gave only one example.
> cut your long hair
Ha, ha. You want me to shave my chest?
> you'd never understand it anyway!
It would be a vulgar word, so no one cares.
Ed de Moel
> [ . . . ] a tough
> decision that the MDC refused to make, and the mindset of idealogues
> who claim that there is any kind of a technical, rather than
> historical, justification for its being that way.
>
> Charlie Volkstorf
Since the horse is dead, and no additional arguments can be made,
it might still be worth while to make one little remark:
the MDC did make a decision.
While everyone recognized that the behavior of ELSE is different
in MUMPS than in most other programming languages, it was felt
that is was more important that existing software that was written
to this behavior would continue to behave as it did, rather than
change the language specification to become "the same as everyone else".
And that was the decision that the MDC made: the decision to
NOT BREAK existing software.
Ed de Moel
Alexander Riemer
to give this discussion a bit more humor:
I think, one of the reasons why MUMPS failed,
was the name.
MUMPS is a sickness. Who wants to use a language/
database that has a name of a sickness? ;-)
Only inthusiasts do.
Alexander Riemer
BEWIDATA
"Charlie-Boo" <ch...@aol.com> schrieb im Newsbeitrag news:3df1e59f.04030...@posting.google.com...
Charlie-Boo
> Charlie V wrote:
> > Denver Braughler screamed:
> > > Charlie V wrote:
> > nobody uses MUMPS anyway,
> Lots of people use MUMPS..
Name 2.
> > you should give up and stop playing CalvinBall
> Okay, Calvin.
Thanks, Calv'
> > stop wasting people's time with your "examples"
> You asked for it, you got it.
I forgot "Be careful what you ask for because you might get it."
> It's just one example, singular.
> Not too long ago you were grousing because I gave only one example.
What's grousing mean?
> > cut your long hair
> Ha, ha. You want me to shave my chest?
No, stop pounding it.
Denver,
You are right. Apparently there is no way to express your example
flow using only if/else/elseif without duplicating something (the
predicates or the conditional code.) I guess in hindsight (20-20) one
might guess that there might be SOME use for MUMPS' argumentless IF
and ELSE that is not expressible nonredundantly using the alternate
approach. I comment you for your insight!
I was tempted to point out that MUMPS' required additional IF 0 and IF
1 is a tradeoff between the two approaches, but that is not really so.
IF 0 and IF 1 (or some other fix, although I agree that this is the
best) are needed only because MUMPS (foolishly – do we agree?) does
not stack $T for all forms of subroutine invocation (also making the
language inconsistent in that respect.)
Not to put a damper on your clever example (which has value in its own
right), but as far as the question of why more people don't use MUMPS
goes, I really don't think that contributes to that debate. Do you
think that this potential advantage in any way diminishes people's
chagrin at the problems (bugs and fixes) introduced by $TEST not being
stacked? Or by MUMPS being so different in how IF-ELSE works? So we
actually have a number of somewhat distinct issues: the utility of the
argumentless IF and ELSE based on the last executed IF, the use of
line breaks to segregate as opposed to language delimiters such as {
and }, and the failure of MUMPS to stack $TEST in all contexts. I
wonder if anyone would argue that there are any real advantages to not
always stacking $TEST?
But back to the original question: Why don't more people use MUMPS?
(Let's ignore the fact that it is no longer an ANSI standard - the
situation was still less than optimal even in the best of times,
although MUMPS did enjoy an estimated 20% annual growth rate in its
infancy.) Armin van Harten correctly points out that the difficulty
of interfacing MUMPS code with other technologies is a great hindrance
to its acceptance.
I would like to suggest a list of possibilities to which people could
add entries and give weights. I am reminded of news media that take
polls as to the public's political opinion, then pundits give their
opinions as to why. I have always wondered why the polls never
include a question as to why the respondent takes that particular
position! Well, here's the chance to fix that, in this new:
MUMPS Poll
A. How do you think MUMPS compares to other programming languages?
1. Far better.
2. Somewhat better.
3. About the same.
4. Somewhat worse.
5. A lot worse.
(Please don't cloud the issue by asking for or pointing out details
like the fact that there are many aspects to the question, or it
depends on the implementation or application, etc. These factors
could be incorporated into the next question, actually.)
B. Why don't more people use MUMPS?
1. It's too different from the norm.
2. Its technical flaws (e.g. not stacking $TEST, a lack of block
structuring and array manipulation, awkward parameter passing.)
3. It doesn't interface well with other technologies.
4. They assume it won't work well for nonmedical applications because
of the name. ("But what does M stand for?")
5. It was designed for (optimizes) factors that no longer apply (small
program space, ascii based terminals.)
6. Its original base of support was not broad based - it started out
as a project among medical professionals and never really reached out
to the general public.
7. Nobody uses any technology more than 5-10 years old at most.
If you are a manager, the question is, why don't YOU use MUMPS? But
this needs to be asked in a non-MUMPS environment. Or maybe, have you
stopped using MUMPS and why?
One last thought (for this message, anyway, of course): Plenty of
people use (used to use?) MUMPS - for medical applications. MUMPS
very successfully penetrated this market (what percentage??). It
should have kept the name MUMPS, be happy that it dominates medical
applications, and continue to work on that (e.g. developing more
intelligent diagnostic applications.) After all, specializing is
always a good idea, that's a pretty big market anyway, and who wants
to work on anything else but saving lives using computers? (Never
mind the fact that this phenomenon has essentially no technical basis
whatsoever - it's all in the marketing.) Sign me, the devil's
advocate . . .
Charlie Volkstorf
Charlie-Boo
> Charlie-Boo wrote:
> > [ . . . ] a tough
> > decision that the MDC refused to make, and the mindset of idealogues
> > who claim that there is any kind of a technical, rather than
> > historical, justification for its being that way.
> >
> > Charlie Volkstorf
>
> Since the horse is dead, and no additional arguments can be made,
> it might still be worth while to make one little remark:
An oxymoron!
> the MDC did make a decision.
Yes, they took the easy way out (short term , that is.)
> While everyone recognized that the behavior of ELSE is different
> in MUMPS than in most other programming languages,
On "most" days the sun rises.
> it was felt
> that is was more important that existing software that was written
> to this behavior would continue to behave as it did, rather than
> change the language specification to become "the same as everyone else".
How about changing the language to avoid extinction? Then we'd be the
same as everyone else: nonextinct.
> And that was the decision that the MDC made: the decision to
> NOT BREAK existing software.
In other languages, the standard term is "deprecated". They give you
time to get rid of it (dependence on $T not being stacked, in this
case.) And think of all the cool software we could have written to
find them all!
> Ed de Moel
You know, it's funny. MUMPS was developed in Boston, the bastion of
liberalism (the only state that McGovern carried.) Yet the MDC
decided that the best approach was not to bite the bullet. It reminds
me of the current administration's solution to economic problems: more
consumer spending and tax cuts. The MDC sounded more like
republicans!
I guess they wore designer jeans.
Charlie de Ratt
Actual conversation (paraphrased with literary license):
Me: You have to bite the bullet.
MDC: If we did that we wouldn't survive.
Me: If you think it's bad now, wait'll it gets worse. You have to
think of the long term.
MDC: In the long term, we're all dead anyway.
Me: It's come sooner than you think.
MDC: . . . no answer . . . nobody home . . . left no forwarding
address . . .
Aaron Seidman
>NOT BREAK existing software.
And when new elements were added to the language, such as block structures
(argumentless DOs), $TEST was stacked.
>In other languages, the standard term is "deprecated". They give you
>time to get rid of it
On balance, making ELSE a separate command and relying on a non-stacked
special variable created more problems than it solved. Unlike the case with
$NEXT and $ORDER, it is not obvious how it could have been fixed without
breaking existing code. (Hmm, maybe $EITHER ... ELSE ... ENDIF)
Aaron
--
Aaron Seidman
Imaginative Illustration
P O Box 1009, Brookline MA 02446
aa...@imaginative-illustration.com
http://www.imaginative-illustration.com
617.232.2509
Denver Braughler
> Denver Braughler wrote:
> > It's just one example, singular.
> > Not too long ago you were grousing because I gave only one example.
> What's grousing mean?
<http://dictionary.reference.com/search?book=Dictionary&q=grousing>
> You are right. Apparently there is no way to express your example
> flow using only if/else/elseif without duplicating something (the
> predicates or the conditional code.) I guess in hindsight (20-20) one
> might guess that there might be SOME use for MUMPS' argumentless IF
> and ELSE that is not expressible nonredundantly using the alternate
> approach.
This could be done in other languages by adding "ifany" and
"elsesofar" to the control structure.
"Elsesofar" is really the same a "else".
But programmer would need to think of it a little differently and it
would not end an if-block.
> I comment you for your insight!
- with hash, slash-star, slash-slash, bang, or a semicolon?
> I was tempted to point out that MUMPS' required additional IF 0 and IF
> 1 is a tradeoff between the two approaches, but that is not really so.
Correct. Actually, it would work even "better" if $T could net be contaminated.
> Do you think that this potential advantage in any way diminishes people's
> chagrin at the problems (bugs and fixes) introduced by $TEST not being
> stacked?
It works for me, because, as with any language, one must adapt to its quirks or vagaries.
When coding C, one must be cognizant to use if(a==1) rather than if(a=1).
Do you how many problems (bugs and fixes) introduced by the assignment operator being
the same as what everyone else uses as an equality operator?
Look how JavaScript handles the problem.
Version 1.0: if(x=1) is always true and assigns 1 to x, just like C.
Version 1.1: if(x=1) is interpreted as if(x==1) because that's what the programmer probably meant.
Version 1.2: assignment operator is forbidden where a conditional expression is expected.
Aren't you glad they got that figured out?
> I wonder if anyone would argue that there are any real advantages to not
> always stacking $TEST?
The only place that I've ever found it useful was to return a value from Xecute code
(typically field validation).
However, something like I $X(xecutecode) where the code has Q 0 or Q 1 to return a value would
have had greater utility.
If $T were always stacked, I would be fine with that.
I think it has been more than ten years since I wrote any code that relied on its not being stacked.
Denver Braughler
> MUMPS is a sickness. Who wants to use a language/
> database that has a name of a sickness? ;-)
I think Thomas Salánder was a big proponent of changing the name.
But no better name ever came forward that was agreeable.
When put to a vote, "M" was adopted as an alternative name.
InterSystems eventually settled on Caché - a misspelling of "cachet".
That name is difficult to Google because of the noise from the
industry term "cache".
The diacritical mark makes it difficult to compose on a US-En keyboard.
Many people write just "Cache" or "Cache'".
Charlie-Boo
> Hi all,
>
> to give this discussion a bit more humor:
>
> I think, one of the reasons why MUMPS failed,
> was the name.
>
> MUMPS is a sickness. Who wants to use a language/
> database that has a name of a sickness? ;-)
> Only inthusiasts do.
>
> Alexander Riemer
> BEWIDATA
>
> "Charlie-Boo" <ch...@aol.com> schrieb im Newsbeitrag news:
Thanks. I always wondered what my name looks like in German.
> > IF-ELSE should have been fixed.
> > The MDC optimized the short term rather than the long term. In the
> > end, it was good old short term thinking. And the long term has now
> > arrived.
> >
> > Charlie Volkstorf
> >
> > Henry was right.
Oh darn - all these years and it was just the name! Who'd ‘a thunk?
We always thought that MGH's Utility Multi Programming System was such
an appropriate title for something developed at Mass General.
Hey, here's an idea. Let's change the name and call everybody back
and ask them to reconsider!
How about: MGH's Amazing Language for Algebraic Relational Information
Access?
Charlie Volkstorf
Axel Trocha
> The MDC did only what the biggest implementers wanted. (The
> appellants to ANSI were programmers and very small implementers.) No
> big implementer would propose making fundamental or backwards
> incompatible changes. But that is exactly what MUMPS needed. The
> basic data type should have been arrays and the intrinsic functions
> should have been array manipulations instead of string manipulations.
>
> The MDC optimized the short term rather than the long term. In the
> end, it was good old short term thinking. And the long term has now
> arrived.
Hello,
the IF/ELSE/$T issue is annoying and during the last 15 years where I
have been using Mumps, I never figured out the reason behind it. I
really do wonder how many times I did not think of that issue and am
producing unexpected results with my code ;)
During the last two years we have been using parts of FreeM as a
scripting language for an internet massive multiplayer game written in
C(++). In that particular case a scripting language is a good thing,
since you do not need to recompile/reboot your game for each tiny
change, but can edit event-triggered scripts online and on-the-fly. In
the last months, I have been introducing several people (8-10) to Mumps
and all(!) of them had a really hard time with Mumps' strict syntax. I
rate the missing possibility of dynamic whitespacing as another reason
why new people really do have problems with Mumps. As a side-note -
all(!) people really loved Mumps after they got used to it. (about one
to four weeks per person)
Another thing, which we as old Mumpsters sometimes do not think about
anymore, but which horribly 'boggles' new people are the abbreviated
commands and functions. 's a=$t($e($s($tr(...))))' ... Outsiders think,
what drugs have the coders been on? -- they move away and do not even
spend another thought.
Mumps is not pretty and it neither is trendy. But for myself it is first
choice for web applications. It is small, still it is able to do a lot -
language and database. With inline HTML it is a very easy way to create
such applications. (I will add an HTML/M script at the end of this text.)
For web programming: I have done my share of Java, PHP, Phyton, Perl,
Ruby connected to mainly postgres (also mysql, msql or ingres). There
has never been a problem with the language really - it has always been
the database performance. With a few thousands of records SQL has been
horribly slow compared to the Mumps-$order counterpart.
That little unoptimized Mumps binary (about 250k) has always been
performing better compared to its counterparts, which were even 100+
times the size. The reason that Mumps is not where it belongs is because
it got no hype nor emotion. There is no PR at all. There are mostly old
people who have been with Mumps all their live, who are happy about what
they got. This is all fine, but we got no young people - neither do we
seem to care about young people. There are no die-hard idiots like
Charlie or Denver supporting it and willing to fight over it -
permanently and all the time - 24/7. (Charlie, Denver - I am sure you
understand that I meant that in the most positive way)
If PHP had an $ORDER command, being able to step through a btree
database, then really I would not hesitate one second. It is so much
nicer to work with PHP, but until then ...
-Axel
Denver Braughler
> the IF/ELSE/$T issue is annoying and during the last 15 years where I
> have been using Mumps, I never figured out the reason behind it.
Things are the way they are because they got that way.
The genesis of $T was in the interpreter.
> I really do wonder how many times I did not think of that issue and am
> producing unexpected results with my code ;)
It can happen with almost any language.
Just look how common buffer overruns are in many other languages.
At least MUMPS doesn't have that problem.
> I rate the missing possibility of dynamic whitespacing as another reason
> why new people really do have problems with Mumps.
On the other hand, the line scope rule and strict spacing makes code very
readable. I never have to match braces or get used to someone else's idea of pretty print layout.
> As a side-note - all(!) people really loved Mumps after they got used to it.
Good.
> (about one to four weeks per person)
Great!
> Another thing, which we as old Mumpsters sometimes do not think about
> anymore, but which horribly 'boggles' new people are the abbreviated
> commands and functions.
Many languages have so many reserved words that one could not recall them all from memory.
MUMPS could abbreviate because it had so few instructions.
Ed de Moel
> Charlie-Boo wrote:
>
>> The MDC did only what the biggest implementers wanted.
Now,there is the one item that really is important:
When the MDC voted for backward compatibility,
that was NOT on the behest of the biggest implementors,
but on the majority vote of the end-users.
They were the ones who had made the investment in the
software that they had written, and they were the
ones who wanted to see their invenstment preserved.
Just my recollection of what really happened...
Ed
Jeffrey Williams
news:3df1e59f.04031...@posting.google.com...
> Denver Braughler <aa.DBrau...@aa.bwcc.com> argued
> > Charlie V wrote:
> > > Denver Braughler screamed:
> > > > Charlie V wrote:
>
> > > nobody uses MUMPS anyway,
> > Lots of people use MUMPS..
>
> Name 2.
Okay, I'll bite.
IDX - installed at over 3,300 customer sites.
Epic - something about a multi-billion dollar deal with Kaiser - uses
Intersystems Cache
Ameritrade - trade any stocks lately, decided to use Intersystems Cache
because it works better than Oracle.
Sanchez and GT.M
VA
Oops - that's more than 2, sorry
> > > you should give up and stop playing CalvinBall
> > Okay, Calvin.
>
> Thanks, Calv'
>
> > > stop wasting people's time with your "examples"
> > You asked for it, you got it.
>
> I forgot "Be careful what you ask for because you might get it."
>
> > It's just one example, singular.
> > Not too long ago you were grousing because I gave only one example.
>
> What's grousing mean?
>
> > > cut your long hair
> > Ha, ha. You want me to shave my chest?
>
> No, stop pounding it.
>
> Denver,
>
> You are right. Apparently there is no way to express your example
> flow using only if/else/elseif without duplicating something (the
> predicates or the conditional code.) I guess in hindsight (20-20) one
> might guess that there might be SOME use for MUMPS' argumentless IF
> and ELSE that is not expressible nonredundantly using the alternate
> approach. I comment you for your insight!
>
> I was tempted to point out that MUMPS' required additional IF 0 and IF
> 1 is a tradeoff between the two approaches, but that is not really so.
> IF 0 and IF 1 (or some other fix, although I agree that this is the
> best) are needed only because MUMPS (foolishly - do we agree?) does
Charlie-Boo
There was a proposal and the two big implementers voted to make
backwards incompatible changes? When was that and what backwards
incompatible changes were being considered?
Charlie Volkstorf
Denver Braughler
> There was a proposal and the two big implementers voted to make
> backwards incompatible changes?
This is as silly as the notion that DEC and the deck-stacking VA centers voted as a bloc.
> When was that and what backwards
> incompatible changes were being considered?
I don't know that such proposals ever made it out of subcommittee.
I think it was well-understood that the majority of the users did not want
backward incompatible changes.
So no such change was going to be passed until there was a way to fix the installed base.
I do believe that the implementors including the three biggest were willing to do so.
Certainly it was technically feasible.
ISC now runs compatibility modes for several varieties of MUMPS.
Another mode could have been for legacy routines that don't stack $T.
I never heard a vendor say that it couldn't be done.
Stacking $T would not have completely fixed the problem.
But there was a large installed base of code for which the change was unpredictable any way.
My opinion was that it would be bad to leave a lot of folks with no reasonable migration path.
The VA was a big user of $T.
I would not expect DEC to vote against their own customer on this issue (even though they often voted against them on other issues).
Charlie-Boo
> Alexander Riemer wrote:
> > MUMPS is a sickness. Who wants to use a language/
> > database that has a name of a sickness? ;-)
> This argument was commonly made.
> I think Thomas Salánder was a big proponent of changing the name.
> But no better name ever came forward that was agreeable.
> When put to a vote, "M" was adopted as an alternative name.
Reality Check - Speaking of the MDC doing only what the biggest
implementers wanted:
The vast majority of voices in the MUMPS community supported a name
change, and by far M was the preferred name. (Cocktail party jokes
were what our new slogan would be: "Dial M for Murder" etc.) But one
big contributor to the MDC (Bush has his Pioneers' Club, MUG had its
"Gold Members") said no, they wanted to be the only vendor who used a
big M in their advertisements. So the MDC did nothing for years.
Then one year, MUG announced at the annual meeting that they had
finally taken the matter into their own hands. They projected onto
the screen a resolution that they had passed: M is the preferred
alternate name for MUMPS.
People cheered and the MDC went ape. They (Tom) rushed out an email
to everyone saying that they had voted to change the name to M. But
then why did MUG not say anything about it, I wondered. When did that
happen? Accustomed to not receiving a response to my letters to the
MDC, I started to get the most respectable person in the MUMPS world
whom I knew to send them a letter asking for when and where this vote
by the MDC occurred. But in the end I decided, why bother?
We now use M for MUMPS. Still I ask, when did the MDC ever vote to do
so? (Or at least before MUG lit a candle under them.)
Ah, he good old days . . .
Sentimentally yours,
Charlie Volkstorf
Charlie-Boo
> Charlie V wrote:
> > There was a proposal and the two big implementers voted to make
> > backwards incompatible changes?
> It wouldn't have mattered how they voted.
> This is as silly as the notion that DEC and the deck-stacking VA centers voted as a bloc.
The only people who brought up that silly notion was the MDC. The
appellants to ANSI said that their proposals weren't voted on, while
the big vendors' proposals were voted on repeatedly until passed. The
MDC responded that their members don't vote as a block.
(The reference to the VA was in the context of the contention that the
MDC doesn't follow its own rules, e.g. recording rollcall votes and
only one member per organization. Part of the appeal was a request
for written rules and procedures, e.g. on the voting process, that
would be applied uniformly to eliminate preferential treatment.)
(The appellants also asked that votes be taken through the mail so
that everyone could participate equally, to which the MDC strongly
objected. It was a blatant case of the power of money. ANSI votes
were always through the mail and their bylaws expressly prohibit
membership attendance from being a requirement.)
> > When was that and what backwards
> > incompatible changes were being considered?
> I don't know that such proposals ever made it out of subcommittee.
In the post that started this thread, Ed the MoleMan wrote:
"When the MDC voted for backward compatibility, that was NOT on the
behest of the biggest implementors, but on the majority vote of the
end-users.", Calvin!
> I think it was well-understood that the majority of the users did not want
> backward incompatible changes.
> So no such change was going to be passed until there was a way to fix the installed base.
I volunteered to write utilities to do so, if a proposal would be
written up.
> I do believe that the implementors including the three biggest were willing to do so.
> Certainly it was technically feasible.
> ISC now runs compatibility modes for several varieties of MUMPS.
> Another mode could have been for legacy routines that don't stack $T.
> I never heard a vendor say that it couldn't be done.
Yes. Bottom line: Other languages stack "$T" and deprecate features
when better ways are realized. The MDC didn't. And the other
languages have a lot more users with which to contend!
Charlie Volkstorf
Armin van Harten
troubles are all about. Compared to a modern type language, the most
irritating leak is the total absence of a standardized library concept wich
allows the programmer to use third party products without knowing anything
about there internal architecture of the package. Except M, EVERY language
can do this. Following are the consequences:
a) since you cann't link libs, nobody writes them
b) since nobody writes them there are no
c) since there are no libs, you must do everything yourself
and now: If you don't know how?? M Literature is prehistoric. Usergroups
are old mens tobacco collegium debating about sense or nonsens of the
implementation of the IF statement. Everything smells stuffy in here. Let
me get out!!!
That's what you get when you enter M.
With libraries you can even sell more horrible languages like C, because
when the heavy coding begins, nobody sees it, because it is encapsuled,
invisible, looking like a part of the language, wich is definetly wrong,
because modern languages do not have much elements, but enormous
libraries!!!
We learned from HTML and SQL that a successfull computerlanguage may be as
ugly as can be, but if it does not confront me with the uglyness, people
like it when they get the desired result with a few keystrokes.
The next killer of M is the pleistozaen like local memory management called
the Local Symbol Table. Wich successfully prevents inspired programmers
from implementing even simple modern structures. Why is this a killer? It
is the mother of sideeffects! Did you ever try to protect a calling program
from possible influences of the program wich was called? Did you like the
solution you've found? No encapsulation, no grouping, no controlled
visibility, and as a consequence : no persistence in controlled ranges like
it is commonly used with OO languages. You see all or nothing. And here we
meet $T again!And all the IF/THEN/ELSE calamity (fortunatly M has so many
ways for conditioned branching that IF usually does not count, while other
languages have IF (CASE maybe) etc. as the only conditioned branching, and
if you find somebody who worries about IF, than you've probably found
somebody who didn't understand M)
If you try to sell this to a younger professionel, historic reasons will
not save you.
There are some minor beasts in the cave, but with a little help one can
avoid to meet them. The two above you can not avoid! And only the
implementors could change the situation. Unfortunatly, there are no
implementors anymore. So rest in peace, dear M. Your grave will be
cultivated. And as it is with the dead, we love them to be dead, we do not
want them to change or get up alive again. Fortran 80 was not Fortran
anymore, I never touched Fortran again after the revision. I love the dead
M because I am one of the last survivors who saw it alive. Yes, the good
old days, when you could start a car only when you knew enough about the
engine. Now you simply turn a key. We didn't have keys that time!!
Now you know why M failed, Axel
Armin van Harten
IfmD-consulting GmbH
Wetzlar, Germany
Axel Trocha
Why address me? I never claimed that M did not fail in the general
sense, neither did I have problems grasping relating reasons. All I said
was that it works fine for some of my applications and I guess this is
pretty much the same with most other people here.
Noone really claimed that M is top-notch in the sense of innovation and
that it can beat nowadays products. How would it be able to? During the
last years it has been successfully abandoned by commercial industry.
(vendors)
But really those people who found out years ago that Mumps has failed,
please tell me what you are still doing here in this newsgroup. You
should have moved on long ago. Do not tell me that you are just being
social and want to protect us from miserably failing. ;)
Axel
Armin van Harten
> Why address me?
Simply because you just opened the thread. Nothing special. I know, you
not responsible for nothing and I didn't want to offend you personally.
>I never claimed that M did not fail in the general
> sense, neither did I have problems grasping relating reasons.
But in a way I can not avoid to state that you didn't get it anyway. I
posted: The usergroups, the users and developers failed, not the language.
How can something fail wich didn't move for 12 years?
>All I said was that it works fine for some of my applications and I guess
> this is pretty much the same with most other people here.
And I say, that is not enough. This is wasting time and space. Two years
ago, I posted the question: 'What is M good for?', and I didn't get reply.
It seems, that there is still no answer. And I am getting angry, when I
see, that M is mostly the language for those who do not know how to open a
random access file. I realy feel with Charlie Volkstorf!
> Noone really claimed that M is top-notch in the sense of innovation
> and that it can beat nowadays products. How would it be able to?
It's been a time since I've seen M beating anything. For the last 8 Years I
could only hear M-people call 'me too, me too!'. But with a few add on's
it could be up again! Unfortunatly nobody seems to like this.
> During the last years it has been successfully abandoned by commercial
> industry. (vendors)
Ahh, not realy! It has been much more successfully abandoned by the
softwareauthors. Writing tools for VB People can give you money and make a
living. M Programming was strikly related to some inhouse application -
support crews(What we call, a very small and highly vertical market). Not
very attractive for investors.
Nobody can sell M programs like i can sell my XY Written OCX's or Dll's
etc.for the above named reasons(I remember when I was looking for a M-based
Forms I/O-system, oh my ....). MSters never cared about this because they
always have been satisfied with what they did by themselfs, as if there
would no world outside. It took a long time to recognize, that this tool
had been killed by the users while others have been supported by their
users.
It was not the industry. They gave us what we asked for. We never asked for
something better (Or better: too few did, and could not be heard). Keith
Snell answered the question about if there would be transaction processing
be implemented in M21 soon, 'No we will not, because M programmers do not
use this technique, and use home cooked algorithms instead' or something in
this sense. Any more comments?
>
> please tell me what you are still doing here in this newsgroup. You
> should have moved on long ago. Do not tell me that you are just being
> social and want to protect us from miserably failing. ;)
>
> Axel
>
I don't know it exactly. Sometimes I visit cemeteries, take look at the new
tombs, put some flowers here or there. Remember the times when there were
chances, and see them all spoiled. I like the quiet atmosphere around.
Nothing new, everything well known. Sometimes a name vanishes from the
posting list and you know, that time made a step once more.
DEVIL, not realy! The best thing about this group is, that there is a fight
again, Thank you Charly. Thanks to Mr Bashkar. GTM Open source gives us a
chance to reenter the evolution. And it's been the hope that someday
possibly something will move.
This are may statements:
M is not an application programming language, according to Grady Booch it
is an instruction code!
M is not a database !
M is the last environment wich is realy different from the mainstream. And
therefore must be kept and needs a special evolution conception.
The world is not a disk and data are not naturally arranged in tables.
Armin
Armin van Harten
Ifmd-consulting GmbH
Wetzlar, Germany
Denver Braughler
> Denver Braughler wrote:
> > Alexander Riemer wrote:
> > > MUMPS is a sickness. Who wants to use a language/
> > > database that has a name of a sickness? ;-)
> > This argument was commonly made.
> > I think Thomas Salánder was a big proponent of changing the name.
> > But no better name ever came forward that was agreeable.
> > When put to a vote, "M" was adopted as an alternative name.
>
> Reality Check - Speaking of the MDC doing only what the biggest
> implementers wanted:
>
> The vast majority of voices in the MUMPS community supported a name
> change,
> and by far M was the preferred name.
I don't know that there was one.
> But one big contributor to the MDC
You must mean InterSystems.
> ... said no, they wanted to be the only vendor who used a
> big M in their advertisements. So the MDC did nothing for years.
There really is no point in infringing on a trademark.
Seriously, "M" is a letter, not a name.
> Then one year, MUG announced at the annual meeting that they had
> finally taken the matter into their own hands. They projected onto
> the screen a resolution that they had passed: M is the preferred
> alternate name for MUMPS.
You mean "alternate [sic] name".
> We now use M for MUMPS.
> Still I ask, when did the MDC ever vote to do so?
As an alternate name or as an alternative name?
Denver Braughler
> Denver Braughler wrote:
> > Charlie V wrote:
> > > There was a proposal and the two big implementers voted to make
> > > backwards incompatible changes?
> > It wouldn't have mattered how they voted.
> > This is as silly as the notion that DEC and the deck-stacking VA centers voted as a bloc.
> The only people who brought up that silly notion was the MDC.
> The appellants to ANSI said that their proposals weren't voted on, while
> the big vendors' proposals were voted on repeatedly until passed. The
> MDC responded that their members don't vote as a block.
More importantly, that a proposal needs a proponent, a shepherd, a sponsor, or such
to explain it, address issues, update the document, etc.
> > > When was that and what backwards
> > > incompatible changes were being considered?
> > I don't know that such proposals ever made it out of subcommittee.
> In the post that started this thread, Ed wrote:
> "When the MDC voted for backward compatibility, that was NOT on the
> behest of the biggest implementors, but on the majority vote of the
> end-users."
Ed did not mean that backward compatibility was put to a vote.
But rather that when the issue arose in any proposal the majority of
end users didn't want to lose their installed code base.
> > I think it was well-understood that the majority of the users did not want
> > backward incompatible changes.
> > So no such change was going to be passed until there was a way to fix the installed base.
> I volunteered to write utilities to do so, if a proposal would be
> written up.
You have me beaten there.
How could you possibly automate conversion?
The man-hours required could be far more than Y2K fixes.
> > I do believe that the implementors including the three biggest were willing to do so.
> > Certainly it was technically feasible.
> > ISC now runs compatibility modes for several varieties of MUMPS.
> > Another mode could have been for legacy routines that don't stack $T.
> > I never heard a vendor say that it couldn't be done.
>
> Yes. Bottom line: Other languages stack "$T"
Other languages *have* $T??
Name 2.
> and deprecate features when better ways are realized.
So do, some don't.
You said "if a proposal would be written up."
I'm sure there were more than a few people who would have liked to have seen it.
I never saw a proposal to comprehensively correct IF and ELSE.
Did you?
Look at the mess found in regular expressions in C, Unix shells and utilities, Perl, etc.
Why hasn't that been cleaned up?
Denver Braughler
> Compared to a modern type language, the most
> allows the programmer to use third party products without knowing anything
> about there internal architecture of the package. Except M, EVERY language
> can do this.
So far as I know, GT.M can do this.
Cache' definitely can do this.
<http://platinum.intersys.com/csp/docbook/DocBook.UI.Page.cls?KEY=GCJB> Java
<http://platinum.intersys.com/csp/docbook/DocBook.UI.Page.cls?KEY=GCPP> C++
<http://platinum.intersys.com/csp/docbook/DocBook.UI.Page.cls?KEY=GACT> Activate
<http://platinum.intersys.com/csp/docbook/DocBook.UI.Page.cls?KEY=GAX> ActiveX
<http://platinum.intersys.com/csp/docbook/DocBook.UI.Page.cls?KEY=RCOS_fzf-3> DLL
> Following are the consequences:
> a) since you can't link libs
False premise.
> c) since there are no libs, you must do everything yourself
False premise, false conclusion.
> there are no implementors anymore.
False.
I believe five have been mentioned recently.
Denver Braughler
> How can something fail wich didn't move for 12 years?
What didn't move for 12 years?
> I am getting angry
That sounds like a personal problem.
> M is mostly the language for those who do not know how to open a
> random access file.
But it is also a language for me.
The M database is far more versatile than a mere keyed file.
> if there would be transaction processing be implemented
TStart, TCommit
> The world is not a disk and data are not naturally arranged in tables.
You got that right.
So what's up with those OracleSybaseIngresPostgresAccessMySQL people?
Do they think the earth is flat too?
Axel Trocha
[..]
>>I never claimed that M did not fail in the general
>>sense, neither did I have problems grasping relating reasons.
>
> But in a way I can not avoid to state that you didn't get it anyway. I
> posted: The usergroups, the users and developers failed, not the language.
> How can something fail wich didn't move for 12 years?
>
>>All I said was that it works fine for some of my applications and I guess
>>this is pretty much the same with most other people here.
>
> And I say, that is not enough. This is wasting time and space. Two years
Erm?! It is my time and my space, which is spent - only mine. I chose to
use M for some apps and I did choose it for myself and only for myself.
Others are not involved. So I do not care what others think, if they
understand or agree with me. I do not ask others to use it also - just
as I do not ask others to use Windows or Linux.
> ago, I posted the question: 'What is M good for?', and I didn't get reply.
I remember when you asked that. And if I am not mistaken you asked
similar even longer ago. Maybe you did not get much reply because you
would only have accepted a reply which would conform to your point of
view? The question itself at least points into that direction.
> It seems, that there is still no answer. And I am getting angry, when I
> see, that M is mostly the language for those who do not know how to open a
> random access file. I realy feel with Charlie Volkstorf!
I feel a lot with Charlie Volkstorf too - I even like him without
knowing him, but then again I am not the same. And erm whatever I should
do with a random access file, I am sure I could handle it if I needed to
do so :)
[..]
> Ahh, not realy! It has been much more successfully abandoned by the
> softwareauthors. Writing tools for VB People can give you money and make a
> living. M Programming was strikly related to some inhouse application -
[..]
Are you trying to blame M for something personal? You sound incredibly
bitter for someone who does not care anymore.
[..]
>>please tell me what you are still doing here in this newsgroup. You
>>should have moved on long ago. Do not tell me that you are just being
>>social and want to protect us from miserably failing. ;)
>>
>>Axel
>>
>
> I don't know it exactly. Sometimes I visit cemeteries, take look at the new
> tombs, put some flowers here or there. Remember the times when there were
> chances, and see them all spoiled. I like the quiet atmosphere around.
> Nothing new, everything well known. Sometimes a name vanishes from the
> posting list and you know, that time made a step once more.
But you are not pulling the dead into discussions how bad and with what
they spent their time? Or .. are you? ;)
It is everyones own business how they spend their time and what they do.
You got the same right too and apparently used it. But if you then
come back and tell others all they do/use is crap - sorry that I
exaggerated - then it is not particulary fair.
regards,
Axel
Charlie-Boo
> Armin van Harten wrote:
> > Compared to a modern type language, the most
> > irritating leak is the total absence of a standardized library concept which
> > allows the programmer to use third party products without knowing anything
> > about there internal architecture of the package. Except M, EVERY language
> > can do this.
>
> So far as I know, GT.M can do this.
>
> Cache' definitely can do this.
I've never seen so much CalvinBall in my life. He's talking about
MUMPS and why it went kaputz. You're talking about the successor to
MUMPS, which is alive and apparently doing well (at least in Europe,
it seems.)
BTW Does anybody have any idea as to the trend in the actual number of
M users - % added, % dropped / year or during the last few years? All
I see are drops and few adds, but maybe there are more secret MUMPS
users?
Charlie Volkstorf
> > there are no implementors anymore.
> False.
> I believe five have been mentioned recently.
If you believe that then I have a nice bridge that I'd like to sell
you. Who's left?
Armin van Harten
news:4059CD7E...@aa.bwcc.com:
> Armin van Harten wrote:
>> How can something fail wich didn't move for 12 years?
> You tell us.
>
> What didn't move for 12 years?
mainstream M-programming. There is still a lot of fileman around...
>> I am getting angry
> That sounds like a personal problem.
It usually is. Thank you for your eludicating remark.
>> M is mostly the language for those who do not know how to open a
>> random access file.
> But it is also a language for me.
I know.
> The M database is far more versatile than a mere keyed file.
But nobody cares anymore. Because if someone once collided with the
established leaders of the M world, he turns around and walks away for
ever....
>
>> if there would be transaction processing be implemented
> TStart, TCommit
Still dummies in M21, M3 etc. no effect, not implemented. Ain't it
significant that you didnt know this? (you can see a copy of the original
discussionthread of the M21 discussion group below)
>> The world is not a disk and data are not naturally arranged in tables.
> You got that right.
>
> So what's up with those OracleSybaseIngresPostgresAccessMySQL people?
> Do they think the earth is flat too?
Ask them, when you've the time to meet them, but possibly you have to get
out of the M-ivory tower and enter the real world. You'd be amazed.
Definetly!
Armin van Harten
IfmD - consulting GmbH
Wetzlar, Germany
<snip>
Any plans to support transactions?
Andrei Kazakov (dev...@kometa.vrn.ru)
16 May 2002, 6:57 am
Dear Keith,
Glad to get to know about your new product.
Do you have any plans to add transaction processing support to M21?
Best regards,
Andrei Kazakov
Kometa
Re: Any plans to support transactions?
Keith Snell (kei...@m21.uk.com)
17 May 2002, 6:23 pm
Andrei,
It is good to hear from you again.
Thanks for your encouraging comments.
Currently there are no plans to support transaction processing in M21.
Best Regards
Keith Snell
Re: Any plans to support transactions?
Dmitri Nosov (dmitri...@informx.ru)
03 Jun 2002, 9:34 am
Keith, Why NOT ? It's very difficult ? Or may be you think this mechanism
is unneeded ?
Re: Any plans to support transactions?
Keith Snell (kei...@m21.uk.com)
05 Jun 2002, 8:29 pm
Andrei,
The reason that TP is not implemented in M21 is not about difficulty, but
about development priorities and user needs.
Whilst I worked for Micronetics and since leaving, I have come across very
few people who were interested in TP in M. In my opinion and experience the
MDC standard for this came late in the day and most long time users of M
had already developed their own application level mechanisms for ensuring
logical transaction integrity.
This was certainly the case when, prior to joining Micronetics, I worked
for the Health Service in the U.K. from 1982 until 1989. Our regional
systems already had a sophisticated transaction integrity assurance
mechanism.
FYI The mechanism we used was the subject of a paper presented at the first
Barcelona MTA meeting and published in the meeting proceedings.
Best Regards
Keith Snell
Armin van Harten
news:c3cp6p$v...@library2.airnews.net:
> Erm?! It is my time and my space, which is spent - only mine. I chose to
> use M for some apps and I did choose it for myself and only for myself.
> Others are not involved.
OK, I didn't know, you are practicing experimental archeology. Maybe this
is the center of all the misunderstandings I encountered in this group. I
allways thought this is a M-computing group, Sorry about that.
>>I remember when you asked that. And if I am not mistaken you asked
similar even longer ago. Maybe you did not get much reply because you
would only have accepted a reply which would conform to your point of
view? <<
:-)) How can you know if you never tried? Implications are prejudice, not
truth.
>> And erm whatever I should do with a random access file, I am sure I
could handle it if I needed to do so :)
But you don't know it yet, because you never tried ? Do you want to tell me
this? Lots of Mster think this way until ... ;-)
>> Are you trying to blame M for something personal? You sound incredibly
bitter for someone who does not care anymore.<<
I never cared much about the so called M-community, but I blame it for
destroying this tool. I think the chances of M will get better when all
these folks are gone. Maybe they can go on ruin PHP next. That is all I am
angry about. Nothing personal. Simply complaining about the waste of
substance.
>>But you are not pulling the dead into discussions how bad and with what
they spent their time? Or .. are you? ;)<<
I can see dead people! They don't know, that they are dead, and they only
see what they want to see (The Sixth Sense)
>>It is everyones own business how they spend their time and what they do.
You got the same right too and apparently used it. But if you then
come back and tell others all they do/use is crap - sorry that I
exaggerated - then it is not particulary fair.<<
We both knew, that someone someday had to do this.
Usually people who do this, don't do it openly. They usually turn their
back on you and do it behind yours. So you do not have the chance to
answer. That's what I call unfair. They come up smiling and do not ask
about to solve the M problem they have, they come up and ask about how to
convert their M-DB to Oracle, to get the hell out of here.
But who, except you, realy cares?
Armin van Harten
IfmD-consulting GmbH
wetzlar, Germany
Armin van Harten
> Armin van Harten wrote:
>> Compared to a modern type language, the most
>> irritating leak is the total absence of a standardized library
>> concept which allows the programmer to use third party products
>> without knowing anything about there internal architecture of the
>> package. Except M, EVERY language can do this.
>
> So far as I know, GT.M can do this.
>
> Cache' definitely can do this.
>
No, it can't. You can not create a set of M routines like a DLL and link it
to another M program. Read the manuals! I've been looking for this feature
desperately, asked IS people and there is no feature like that. You can
shell in on a proprietary basis from other laguages. You can shell out to C
modules if you are willing to create a new Cache.exe and you can elaborate
nifty namespacing concepts, but thats not almost similar to a java import
lib. (BTW Cache didn't implement the ^&yxz() interface)
GT.M 's possibilities to shell in and shell out are much more advanced. But
they still do not have a library concept for M libs and packages. But with
GTM it does not hurt that much. Unfortunatly those approaches are not
portable, so that your customer should have GTM. If he uses Cache, you're
done.
>
>> Following are the consequences:
>> a) since you can't link libs
> False premise.
Oh my good!
>
>> c) since there are no libs, you must do everything yourself
> False premise, false conclusion.
>
>> there are no implementors anymore.
> False.
> I believe five have been mentioned recently.
OK, the challenge is to write a M library set with more than one module
wich I can link to an application of my choice into a M system of my
choice, without endangering its functionality and LST.
Show me your expertise! Mr. Braughler, Sir!
Axel Trocha
[..]
>> could handle it if I needed to do so :)
>
> But you don't know it yet, because you never tried ? Do you want to tell me
> this? Lots of Mster think this way until ... ;-)
I still do not see why you are targetting people this way? If you are so
much better, be happy and use the advantage for yourself.
As for myself, I wouldn't have done such a statement if I would not have
used them. So if DOS Interrupt 0x21 (Functions 0x3D - 0x42) or (fopen(),
fseek(), ...) count for you and - no, I did not use the relating Java class.
>> Are you trying to blame M for something personal? You sound incredibly
>> bitter for someone who does not care anymore.
>
> I never cared much about the so called M-community, but I blame it for
> destroying this tool. I think the chances of M will get better when all
> these folks are gone. Maybe they can go on ruin PHP next. That is all I am
> angry about. Nothing personal. Simply complaining about the waste of
> substance.
C'mon, and you wonder why noone did answer your question(s)? Blaming
others is always the easiest solution. Doing it the way you just did is
also lowest cathegory.
At least since I am paying attention it was pretty obvious how M will
evolve. And reading your comments you knew that too, so you had all
chances and time to make the right decision for yourself. Did you? And
trying to seperate a product and its community - you sure that would
work out? We would end up with the product and you as 'community'.
Besides - with just some knowledge of random access files, which you
apparently got, it would have been easily possible to do a database of
your choice. With some more lines of code you could have reached the
next step. So why did you let a tool, which is worth enough to get angry
about, dependent on a community which you do not care about?
[..]
> Usually people who do this, don't do it openly. They usually turn
> their back on you and do it behind yours. So you do not have the
> chance to answer. That's what I call unfair. They come up smiling and
> do not ask about to solve the M problem they have, they come up and
> ask about how to convert their M-DB to Oracle, to get the hell out of
> here.
>
> But who, except you, realy cares?
Is that part of your problem with the M community? That it is only me
who cares?
As I clarified in my previous comment - I do not ask anyone to use M,
neither do I say M is better or worse. And neither do I mind people
letting it live up or dooming it.
What I cared about was someone coming up out of the blue, specifically
addressing me and wanting me to accept that what _I_ do is 'wasting time
and space', without even knowing or caring what I do. Then in the next
step adding stuff like 'you are practicing experimental archeology'.
So I will let you have the last word on it and maybe we can discuss that
when I come to Giessen and meet up with Wilhelm after my vacation time.
cheers,
Axel
Alexander Riemer
> > "Charlie-Boo" <ch...@aol.com> schrieb im Newsbeitrag news:
>
> Thanks. I always wondered what my name looks like in German.
Your surname sounds very German. Didn't you know?
> How about: MGH's Amazing Language for Algebraic Relational Information
> Access?
I think,
MGH's Interprogramming Caché(d) Relational Only Stable On mainFrames and Terminals
have had more success ;-)
Alex
bhaskar
would like to set the record straight about GT.M, below.
-- Bhaskar
k dot bhaskar at sanchez dot com <-- send e-mail here
Armin van Harten <vanharten@_remove_ifmd-consulting.de> wrote in message news:<Xns94B15FD9BD96Fva...@195.20.224.116>...
> Denver Braughler <aa.DBrau...@aa.bwcc.com> wrote in
> news:4059CAD8...@aa.bwcc.com:
>
> > Armin van Harten wrote:
> >> Compared to a modern type language, the most
> >> irritating leak is the total absence of a standardized library
> >> concept which allows the programmer to use third party products
> >> without knowing anything about there internal architecture of the
> >> package. Except M, EVERY language can do this.
> >
> > So far as I know, GT.M can do this.
> >
> > Cache' definitely can do this.
> >
>
> No, it can't. You can not create a set of M routines like a DLL and link it
> to another M program. Read the manuals! I've been looking for this feature
> desperately, asked IS people and there is no feature like that. You can
> shell in on a proprietary basis from other laguages. You can shell out to C
> modules if you are willing to create a new Cache.exe and you can elaborate
> nifty namespacing concepts, but thats not almost similar to a java import
> lib. (BTW Cache didn't implement the ^&yxz() interface)
>
> GT.M 's possibilities to shell in and shell out are much more advanced. But
> they still do not have a library concept for M libs and packages. But with
> GTM it does not hurt that much. Unfortunatly those approaches are not
> portable, so that your customer should have GTM. If he uses Cache, you're
> done.
[KSB] As Armin notes, GT.M does have the ability to call within the
same process from C to M and from M to C, and the top level main
program invoked from the shell or DCL prompt can be a main() written
in C that calls M code that calls C code, etc.
On the Alpha/AXP OpenVMS, pSeries (formerly RS/6000) AIX, Alpha/AXP
Tru64 UNIX and PA-RISC HP-UX, GT.M also supports the ability to create
shared libraries with object modules created from M source code by the
GT.M compiler. The feature is not (yet) supported on x86 GNU/Linux
and SPARC Solaris platforms. This is mostly a funding issue,
especially so for open source free software such as GT.M on x86
GNU/Linux, where there is no license revenue and the business model is
based on providing services - support and enhancements.
I don't understand the comment "... so that your customer should have
GT.M." If you have an application written in GT.M, please feel free
to ship GT.M to your customer on the x86 GNU/Linux platform. The GNU
General Public License permits this. Also, Sanchez's does not require
that you open source your code written in M and running on GT.M, so
you are free to ship object code only for your application. If I have
misunderstood the comment, please contact me directly to clarify any
licensing question you may have about GT.M.
Jim Self
The first claim is over generalized and obviously false. Thanks to
Bhaskar and many others from Sanchez we have a stable, scalable, high
performance Open Source implementation of MUMPS that is working quite
well for us. Many other implementations of MUMPS are in use by others.
Still, both claims undoubtedly contain some element of truth if
appropriately qualified. Henry must have been right about something. (I
wasn't part of that dialog although I do remember something from 10
years or more back about repeated objections to MUMPS standards
proposals.) Is Henry (or someone who knows) still around to explain what
he was right about? Does any of it still matter?
While it is easy to reject the unqualified claim that MUMPS has failed,
it is clear that there have been a number of failures related to the
independence and viability of MUMPS vendors and standards, the MUMPS
User Group, and the MDC. I don't think any of the reasons given yet in
this discussion are really central to why these actually happened. The
real issues have more to do with the capture of large numbers of MUMPS
programmers by large organizations like the VA, the lack of a viable
independent reference implementation of MUMPS, the lack of participation
of users in actually implementing proposed changes to the standard or in
support of those vendors who did, the monopolization efforts of
Intersystems, etc.
Having converted our data and applications to run on GT.M and Linux and
Apache we are now in a position where we can easily integrate PHP, Perl,
Zope, MySQL, PostgreSQL etc with our MUMPS applications. We will be able
to conduct realistic tests of performance and stability and ease of
development etc and to change the composition of our applications as
needed based on facts generated from the tests. I expect that MUMPS will
do well in the comparison and that we will then be able to make strong
arguments in its favor to developers who might not be aware of the
alternative. If not we will have something to guide future development
of GT.M or to guide us away from it.
Denver Braughler
> Still dummies in M21, M3 etc. no effect, not implemented. Ain't it
> significant that you didnt know this?
> >> The world is not a disk and data are not naturally arranged in tables.
> > So what's up with those OracleSybaseIngresPostgresAccessMySQL people?
> Ask them, when you've the time to meet them, but possibly you have to get
> out of the M-ivory tower and enter the real world. You'd be amazed.
That they use tables in spite of overwhelming evidence that the world is not flat?
> Do you have any plans to add transaction processing support to M21?
> Keith Snell (kei...@m21.uk.com)
...
> Currently there are no plans to support transaction processing in M21.
...
> The reason that TP is not implemented in M21 is not about difficulty, but
> about development priorities and user needs.
...
That must mean at least six vendors of M exist.
Denver Braughler
> I don't understand the comment "... so that your customer should have
> GT.M."
I believe that meant that GT.M has capabilities that the other MUMPS
implementations lack, so if you want to use them, you better have GT.M.
Denver Braughler
> > Cache' definitely can do this.
> No, it can't. You can not create a set of M routines like a DLL and link it
> to another M program.
I was referring to calling already written DLL to use rather than reinventing
the wheel in MUMPS.
> GT.M 's possibilities to shell in and shell out are much more advanced. But
> they still do not have a library concept for M libs and packages.
Did you get that from the manual?
I suppose you also find that C code written for one compiler or platform
compiles in another manufacturer's compile and on all the other platforms.
Folks can't even get HTML to work the same between all the different browsers.
Kevin O'Kane
to C. Mumps subroutines can be called by other languages
and Mumps routines can invoke entry points in object modules
written in other languages.
The MDH Toolkit (which provides a Mumps personality for C++
and access to industry standard object oriented programming
facilities) is written in C++ and routines written with the
Toolkit are likewise fully interoperable with other system
resources.
Shared libraries (DLL's) (as opposed to static libs)
are likewise not a problem for compiled Mumps routines.
To wit, Compiled Mumps programs can be installed as Apache
modules (.so). Thus, Mumps programs can become part of
the web server, not just invoked routines. Much faster
than a full restart for each app for each transaction.
The Mumps Compiler and MDH toolkit are fully written in C/C++
and not tied to a hardware architecture or vendor.
--
Kevin C. O'Kane,
University of Northern Iowa
Cedar Falls, IA 50614-0507
http://www.cs.uni.edu/~okane
ok...@cs.uni.edu
Armin van Harten
news:81627b7f.04031...@posting.google.com:
> I don't understand the comment "... so that your customer should have
> GT.M." If you have an application written in GT.M, please feel free
> to ship GT.M to your customer on the x86 GNU/Linux platform. The GNU
> General Public License permits this. Also, Sanchez's does not require
> that you open source your code written in M and running on GT.M, so
> you are free to ship object code only for your application. If I have
> misunderstood the comment, please contact me directly to clarify any
> licensing question you may have about GT.M.
If he does not have GTM you will have problems to port your libraries. Our
main customer uses cache, so it will not help to develop for GTM and then
ship to him, he would not accept GTM even if we supply a complete
alternative system. (maybe later, but there are reasons to stay with cache
for him now). Although he is already under Unix. but this is a political
and nevertheless a commercial issue.
Anyway, we have to face the fact, that M is not longer as portable as we
believed twenty years ago. And the Javanese are after us.
For IfmD i can say, that GTM made us to think about using M for the future
again, after accepting that 22 years of experience have lost their value.
The last obstacle was wiped away when Sanchez implemented the new interface
possibilities you stated above. This was one thing we've been waiting for,
for years. I have some very concrete ideas about how to use the M Systems
in modern environments and we are about to implement them. But this is a
different thread.
Thanks for your comments
Armin van Harten
IfmD - consulting
Wetzlar, Germany
Armin van Harten
>> > Cache' definitely can do this.
>> No, it can't. You can not create a set of M routines like a DLL and
>> link it to another M program.
>
> I was referring to calling already written DLL to use rather than
> reinventing the wheel in MUMPS.
well ok, but how can I create a .dll from M routines??
>> GT.M 's possibilities to shell in and shell out are much more
>>advanced.But
>> they still do not have a library concept for M libs and packages.
>Did you get that from the manual?
Come on, how can you get something wich does not exist from a manual? What
you can do with GTM is to built big M-modules wich behave like such
libraries and with some particular OS one can use them even from different
languages too. Under linux you still have to encapsulate them in a C
container but this should not be the major problem. But in any way you can
not move this to a different M system!
>I suppose you also find that C code written for one compiler or platform
>compiles in another manufacturer's compile and on all the other platforms.
>
>Folks can't even get HTML to work the same between all the different
>browsers.
but I can create .SO's, or .dll's etc. from languages to share my programs,
and sell this stuff or give it away. The customer can link it to his
application and run it without the kind of torubles we have if we want to
link jus two M-applications together in a componentwise way.
M-Implementors of the past (and I must exclude the GTM staff here), fauiled
to recognize that this leak was substantial for the going down.
As you stated, other languages did not better, some even worse, but where
successful, what did they have what M didn't? Exchangable, shareable
components!
Armin van Harten
> As for myself, I wouldn't have done such a statement if I would not
> have used them. So if DOS Interrupt 0x21 (Functions 0x3D - 0x42) or
> (fopen(), fseek(), ...) count for you and - no, I did not use the
> relating Java class.
Interesting that you compare a basic high level element of almost any
language with a particular assembler element of a special operating system.
>C'mon, and you wonder why noone did answer your question(s)? Blaming
>others is always the easiest solution. Doing it the way you just did is
>also lowest cathegory.
First part of a analysis wich should help to get out of a mess, is always
to adress the mistakes and those who are responsible. If this is not fair,
than any type of error analysis is not fair. It would be easier, if we
could blame the implementors (as done usually), but in this case it would
be wrong. In this case it has been the users wich sunk the boat. No way out
of this. People like you! And I realy don't care what you think about me. I
am not arguing because I want to loved. No, but there are some things wich
should be said in plain words before it's over. If you cann't stand it, it
is not my fault. And it doesn't help if you offend me personal (the the one
who knows everything better, I don't know where you get that from, I simply
wrote, what the problems are) and then try to get out as beeing totally
private. Who do you think you are fooling?
>Besides - with just some knowledge of random access files, which you
>apparently got, it would have been easily possible to do a database of
>your choice.
Again, what is this?? Everybody who ever learned a different language but M
has this knowledge!
I do not know what databases you are working with, but the ones I know need
a few more lines of code to implement.
>So why did you let a tool, which is worth enough to get angry
>about, dependent on a community which you do not care about?
For the xx time now, I am not angry about the tool. And I don't think there
is a community in the M world. Maybe there can be one again in the future.
But what I've seen in the M-scene for the last 8 years was embarrasing. The
only topic wich seems to interest some of the more engaged posters was the
VA system, especially fileman. I've seen some of the fileman applications
through the last 3 years. Now I like SQL
>Is that part of your problem with the M community? That it is only me
>who cares?
I have no problem with the M-community since I never met them. When I was
looking for it, I couldn't find them. Maybe that is different in other
countries, but here, I cann't see them.
>As I clarified in my previous comment - I do not ask anyone to use M,
>neither do I say M is better or worse. And neither do I mind people
>letting it live up or dooming it.
Check your pulse, possibly your are already dead. If pulse is OK, see your
doc. People who do not care about nothing usually, suffer from severe
depression. This can be dangerous.
Don't bite. Just wanted to help.....
>So I will let you have the last word on it and maybe we can discuss that
>when I come to Giessen and meet up with Wilhelm after my vacation time.
There is nothing left to discuss. As you said, you left the last word for
me, and here there are:
Good Bye
Armin
Armin van Harten
> That they use tables in spite of overwhelming evidence that the world
> is not flat?
If you do not travel far, this approximation is good enough for many
applications.
>That must mean at least six vendors of M exist.
Let me count the one I know:
Sanchez GTM
Intersystems Cache
Patterson&Gray M3
M21
MumpsV1 (from the australians)
Kevin O'Cane's M2C compiler
I do not know what happend to FreeM, But Axel will surely know. And I don't
know what happend to UCD - MicroMumps. as far as I know, they never
implemented 95 standard.
Denver Braughler
> Shared libraries (DLL's) (as opposed to static libs)
> are likewise not a problem for compiled Mumps routines.
>
> To wit, Compiled Mumps programs can be installed as Apache
> modules (.so). Thus, Mumps programs can become part of
> the web server, not just invoked routines.
I think that is a good rebuttal to Armin's gripe.
Denver Braughler
> well ok, but how can I create a .dll from M routines??
> >> GT.M ... do not have a library concept for M libs and packages.
> What you can do with GTM is to built big M-modules wich behave like such
> libraries and with some particular OS one can use them even from different
> languages too.
How is this inadequate?
> Under linux you still have to encapsulate them in a C
> container but this should not be the major problem. But in any way you can
> not move this to a different M system!
Did you get that from Bhaskar's response?
I didn't.
Regardless, I can say the say about Oracle and Sybase.
> but I can create .SO's, or .dll's etc. from languages to share my programs,
> and sell this stuff or give it away.
And Prof O'Kane can't?
> As you stated, other languages did no better, some even worse,
Correct.
> but were successful,
Perhaps so, perhaps not.
> what did they have what M didn't? Exchangable, shareable
> components!
Is that what Oracle has?
Michael
<vanharten@_remove_ifmd-consulting.de> wrote:
> I have some very concrete ideas about how to use the M Systems
> in modern environments and we are about to implement them. But this is a
> different thread.
>
I would be interested in hearing your ideas, if you would like to
discuss...
Michael
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Armin van Harten
Unfortunately they do not connect to Cache or GTM or M21 or M3 as far as I
know. So to me they are just one more isoltated flavor of the old language.
With some minor restrictions they could also be implemented as some
'import' or 'uses' units wich expand the original language. BTW a feature,
M never accuired. The best way to connect proprietary M implementation to
the rest of the world offers GTM.
But remember what I complained about: The fact that I can not link M
routines to M routine in a standard way like I can link Java or Delphi
components. And I can not sell M - components to some other users of
another M - System wich I do not need to know. The Fact that after 10
years of ignoring most M systems do not longer refuse to talk to the outer
world, didn't help much.
If the solutions would work, wich are proposed here, why cann't I buy or
download M stuff from internet in a way I can do it with almost any other
contemporary language?
If I write PHP, I can find loads of software up to a complete clinical
information system
If I write Delphi, I can usually download 80% of the targetted application.
Java, and Visual Basic folks tell me the same.
So, if M has all this features, why is M so isolated and does not exchange
anything?
And it does not help much if this M has this, and that M has that
particular property! To be fair, we should than not longer talk about M
(wich does not have these features), but about M2C or GTM or Cache.
Get it, M is out.
Armin van Harten
>> >> GT.M ... do not have a library concept for M libs and packages.
>> What you can do with GTM is to built big M-modules wich behave like
>> such libraries and with some particular OS one can use them even from
>> different languages too.
> How is this inadequate?
It's great, but it is a GTM feature and we can not transport this solution
to any Cache user. So I can not produce for Cache users using the GTM
technique. Marketwise not very clever to exclude the leader of the segment.
>> Under linux you still have to encapsulate them in a C
>> container but this should not be the major problem. But in any way you
>>can
>>> not move this to a different M system!
>Did you get that from Bhaskar's response?
It is not in Mr.Bhashkars respones. It is in the system. GTM Implemented
the ^&xyz interface on a standard linux way. Cache didn't implement this
interface. They use some Zfeature and a customized Cache executable. About
M21 I don't know, but I also do not know any user of M21 around here and so
on. So If they can do it, they all do it different, even under the same OS.
And although all these containers contain the same M I can not put it into
another standard M system, lets say M3.
I must supply the source and as well as module names and global names have
to be compatible with the host system. According to GTM that means, you
have to eliminate all the descriptors longer than 8 characters. They also
have to be compatible with the host application not to interfere with it.
Place a simple argumentless KILL or LOCK somewhere in this Lib, you can
have lots of fun.
>>Regardless, I can say the say about Oracle and Sybase.
We should not compare proprietary databases with some features of using
stored procedures with a programming language wich still claimes to have a
standard. Oracle and Sybase therefore have a standard SQL interface. With M
you need to get some software to implement that.
> but I can create .SO's, or .dll's etc. from languages to share my
>programs,
> and sell this stuff or give it away.
>And Prof O'Kane can't?
As far as I know, Prof. O'Kanes compiler compiles a M-routine down to a C-
routine, wich is then compiled with the C-compiler again to create the
runtimemodule. O'Kane therefore can do every communication a C - module can
do. He just wraps the problem, but for a price: To do this successfully,
he needs to know what flavor of M to compile, and where (resp.how) to store
the global data. M2C uses it's own M-flavor (wich introduces some
retrictions like: no Xecutes etc...) and it's own DB access (Berkley I
presume?), if I read the whitepapers right.
Imagine a standard task of a component:
A Cache based M-module wants to call a M - component, created this way,
pass a globalreference, to make the component perform a special action on
that global (maybe statistics?) and return some results in another global
wich has been passed also as a reference to the component. Remember Cache
requires to create a customized executable to access C-modules directly or
Microsoft Windows OS to use a DLL. So many problems to solve that this does
not look like a solution. So many specialities, that I can not count a
succesfull approach to M. This approach virtually does not work in dayly
life.
And doing this is a standard low level technique with other languages!
>> what did they have what M didn't? Exchangable, shareable
>> components!
>Is that what Oracle has?
Oracle stored procedure should be compatible to oracle stored procedures,
but they are not in general, as far as I know. But this is not the normal
way to access the database (oracle never claimed to be a programming
language). Usually they use SQL and SQL lost its shape a bit throughout the
years, so we can not realy say that the SQL wich gives a particular result
on MS-Access, will work unchanged on Oracle. But I think we should refer to
a Oracle group to get precise information to the topic if necessary.
Armin van Harten
IfmD-consulting GmbH
Wetzlar, Germany
Armin van Harten
news:opr46egr...@news.shawcable.net:
>> I have some very concrete ideas about how to use the M Systems
>> in modern environments and we are about to implement them. But this is a
>> different thread.
>>
>
> I would be interested in hearing your ideas, if you would like to
> discuss...
Ok, why not.
Let me first expose the set of statements wich lead us to the position we
are now:
1. The laguage does not matter anymore. It is the communication, the
encapsuation and the availability of third party software that matters.
2. relational structures get into trouble when describing real worlds
structures (RDB Systems usually explode in complexity much earlier than M
systems do.). The amount of hierarchic structures in the real world is much
bigger than the amount of relational structures wich are artifical
(mathematical). So we should have a tool wich is able to implentent
hierarchical structures directly and combine it with the rest of th worlds
application.
The only System today wich matches the demands on communication and
datastructure is GTM. So when I talk about M from now on, it is a typing
error, I think about GTM.
3. Web based applications of today are usually heterogen and performing
some kind of (what i call:) anarchic communication. Wich means everybody
talks to everybody. As we know, in small companies this can work, but in
bigger companies (with many departments) this will lead to severe problems.
If we look at heterogenous environments, they behave like companies. If
they grow to big, the get the same problems as we can see them in companies
wich grow without implementing sufficient management structures.
In the Webbased application structure we mostly can not find these manager
structures beween heterogenous parts (because they do not belong to any
application part, but to the companiy wich uses the application and
therefore are highly individualistic to the customer). So this system get
more and more complex until there behaviour become virtually unpredictable.
If we want to establish this necessary structures wich manage the system,
what would we need:
A) The system should be able to talk to everybody, therfore it needs
typeless data, because typeless data can emulate any kind of type. (All teh
webbased data are typeless in a way, sometimes they add additional
informations in the files like XML etc)
B) Because of this reason it should have good abilities to call out, and
being called from outside
C) It should be well integrated in the network
D) it must have it's own brain consisting of memory and methods to perform
its job.
E) it has to be event driven, because it's task is usually a reaction on
something happening out there.
F) must be very easy to adopt to the customers needs and the changes of his
company.
If you use any kind of a different language, you will need mostly more then
three communicating systems to peform this tasks (Webserver/client,
programming language, database, for example). Only with GTM you can do it
with one singular platform. So I would say, the best tool to built this
manager institution will be GTM.
Ok, Don't want to write a book, let me have some coffee.....
regards
Denver Braughler
> Denver wrote:
> > Armin van Harten wrote:
> >> components!
> >Is that what Oracle has?
> Oracle stored procedure should be compatible to oracle stored procedures,
> but they are not in general, as far as I know.
> But this is not the normal way to access the database (oracle never claimed
> to be a programming language).
All of which might lead one to infer that perhaps shareable components aren't
a necessary ingredient for success.
> Usually they use SQL and SQL lost its shape a bit throughout the
> years, so we cannot really say that the SQL wich gives a particular result
> on MS-Access, will work unchanged on Oracle.
Simply amazing.
I guess standardization isn't the ticket for success either.
> But I think we should refer to
> a Oracle group to get precise information to the topic if necessary.
Yes, ask them precisely why they use something proprietary.
And do tell that Oracle needs standardization and shared libraries if it
is ever going to be successful.
Kevin O'Kane
...
> As far as I know, Prof. O'Kanes compiler compiles a M-routine down to a C-
> routine, wich is then compiled with the C-compiler again to create the
> runtimemodule. O'Kane therefore can do every communication a C - module can
> do. He just wraps the problem, but for a price: To do this successfully,
> he needs to know what flavor of M to compile, and where (resp.how) to store
> the global data. M2C uses it's own M-flavor (wich introduces some
> retrictions like: no Xecutes etc...) and it's own DB access (Berkley I
> presume?), if I read the whitepapers right.
>
Correct but we use not only Berkeley but also a native module.
However, the data base interface is open - it could be replaced
by a module which communicates with another data base. The
interface to the data base is simple, having only commands such
as retrieve, store, next, prior, delete, etc. If I understand
correctly, Cache accepts queries of from other programs that
would satisfy this. I believe this is possible with GTM
too?
Also, we do permit Xecutes with only minor restrictions.
Armin van Harten
news:uWB7c.51886$aT1....@newsread1.news.pas.earthlink.net:
> However, the data base interface is open - it could be replaced
> by a module which communicates with another data base. The
> interface to the data base is simple, having only commands such
> as retrieve, store, next, prior, delete, etc. If I understand
> correctly, Cache accepts queries of from other programs that
> would satisfy this. I believe this is possible with GTM
> too?
OK, but what for do I need that M2C compiler then? See what I am doing :
write a M2C Mumps program to compile it down to C to integrate GTM Mumps
code to access the database. Maybe it works, but it looks pretty wild to
me.
> Also, we do permit Xecutes with only minor restrictions.
I didn't know. It's been a while since I looked at the publications on your
website. Sorry, for giving wrong details.
Armin van Harten
> How about to Sybase stored procedures?
Sorry, but I can not tell you. Stored procedures are a vendor specific
enhancement and I am not sure if they are implemented in sybase at all. But
since all the DB-vendors did in the last years, i assume that there are
some possibilities to run at least local scripts. But the features and the
dialects may differ in a very wide range from DB to DB.
>> But this is not the normal way to access the database (oracle never
>>claimed
>> to be a programming language).
>All of which might lead one to infer that perhaps shareable components
>aren't a necessary ingredient for success.
From the point of the programming language you can look at a database as
one shareble component. The common interface is SQL. If you stay with the
common standard in SQL, you can exchange the RDB or work on more than one
etc. I think the success of the RDB was founded in the characteristic to be
a shareble and exchangeble component.
If you want to look at M as a Database wich uses M programs as stored
procedures, than we must ask about the Database features. E.G.:What is the
common access interface for all M 'Databases' ?? In don't think it is
SQL...
>> Usually they use SQL and SQL lost its shape a bit throughout the
>> years, so we cannot really say that the SQL wich gives a particular
>>result
>> on MS-Access, will work unchanged on Oracle.
> Simply amazing.
> I guess standardization isn't the ticket for success either.
Standardization of laguages was the way of the 70's to protect the
investments. But already in the late 80's technical development was much
faster, than the standard authorities. In the mid 90's language standards
where definitely out. In the world of communication, interfacing became the
number one qualification to be successful. But that was not the discipline
where M was a winner. If I had to design a system for success, i would take
very good look at the interfaces. No problem to exchange the programs, but
changing the interfaces can be a drag. So when it comes to standardization,
then the interfaces rule.
>> But I think we should refer to
>> a Oracle group to get precise information to the topic if necessary.
> Yes, ask them precisely why they use something proprietary.
They think, they are using standard SQL and therefore proprietarity of the
DB Engine would not count, like it should not matter if one uses IS or GTM,
but in the end we know that it matters. Programming stored procedures is
not the normal way to use the db.
As we stated out in this discussion, even M is not longer portable in an
appropriate way, since so many features have not been defined in the
standard, wich would be necessary (a XML interface for example ). Too late.
I didn't see not one new product based on M-technology throughout the last
8 years. But I've seen a lot of products based on RDB technology, although
I am sure that it is not the saver.
While the RDB's have a well foundet paradigma how to use them (linear
algebra), M never had a paradigma how it is to be used and what it meant,
to have a associative, treebased, typeless, fully dynamic system. There is
still some work to do to explain about the theoretical foundation of the
system since 1981. Anybody here to take the challenge?
Denver Braughler
> Stored procedures are a vendor-specific
Exactly.
> I am not sure whether they are implemented in sybase at all.
They are.
> But the features and the dialects may differ in a very wide range from DB to DB.
So are they failures?
> common access interface for all M 'Databases' ?? In don't think it is
> SQL...
It works.
> when it comes to standardization,
> then the interfaces rule.
Like OMI? MWAPI?
> Programming stored procedures is
> not the normal way to use the db.
How about triggers? Views?
How can you implement anything serious without stored procs?
Aaron Seidman
> It's been a time since I've seen M beating anything.
Not too long ago, at a session of NEMUG (New England M Users Group), a
representative of one of our local hospitals was describing the systems they
use. The bulk of the code is M, with the data stored in Cache' globals. They
also have some Oracle apps and hired some experienced Oracle people to run
those. According to the speaker, the Oracle people were flabbergasted by the
speed of the response time of the M system; they didn't think any DB could
be that fast.
> Keith
> Snell answered the question about if there would be transaction processing
> be implemented in M21 soon, 'No we will not, because M programmers do not
> use this technique, and use home cooked algorithms instead' or something in
> this sense. Any more comments?
I don't know about M21, but DSM had transaction processing in the 1980s and
it outperformed every system it was tested against. In fact, it was so fast
that it created political problems inside DEC (the late Digital Equipment
Corporation); the people selling Rdb arranged to have the results suppressed
because they were afraid it would cut into sales of the relational DB.
Aaron Seidman
Aaron Seidman
> the total absence of a standardized library concept wich
> allows the programmer to use third party products without knowing anything
> about there internal architecture of the package.
Gosh, I didn't realize that I was not using external libraries when I wrote
code in DSM and made calls to non-M routines. Every Mster that I know of
realizes that for some things, compiled code is better; I used to write
routines in C, for instance, and link them to the DSM interpreter very
easily. Now it is true that at that time we were not using dynamic link
libraries, but I don't recall very many systems that did.
Aaron Seidman
Armin van Harten
>> But the features and the dialects may differ in a very wide range
>> from DB to DB.
> So are they failures?
Did I say that? Sorry for the misunderstanding. I said that stored
procedures are a vendorspecific enhancement to his database system.
>> common access interface for all M 'Databases' ?? In don't think it is
>> SQL...
>It works.
Wich one do you mean? KBase SQL, Cache SQL, AIDA??? All these are RDB's
written in M. I've never heard about a native SQL Access into M, and I
would be very! surprised if there would be one, since there is a slight
difference between a tree and a flat table.
>>when it comes to standardization,
>> then the interfaces rule.
>Like OMI? MWAPI?
In a way yes, but unfortunatly you picked two of the few inglorius attempts
of the M world to communicate with others. I was thinking more about
exposing an interface to other languages like the shared object library
interface, the OCX or DLL interface, the TCP/IP link (where the M world was
almost the last who got it running). Anyway, I think about open interfaces
wich are familiar to most programmers and languages. Not M-specific stuff.
Did you ever find a OMI lib to connect a JAVA prog. with an M system ?
>> Programming stored procedures is
>> not the normal way to use the db.
>How about triggers? Views?
Denver, what are we doing here? Discussing the traps of the RDB's and how
they try to get out by using techniques well known to any Mster?
>How can you implement anything serious without stored procs?
I know many folks who did. SQL isn't that bad. If your primary
datastructure is a table, and most businessdata are this way, than it will
work pretty good. But I would not like to use it in medical computing.
Table structures usually explode here after a short time of maintanance.
Stored procedures are not so much in use. They tie your application too
much to not only a vendor but often to a certain version of the DB too, so
any application designer tries to avoid them as long as possible. If you
use M$-access you can go nuts if you write for more than one customer.
Armin van Harten
news:405F97E2...@imaginative-illustration.com:
> Gosh, I didn't realize that I was not using external libraries when I
> wrote code in DSM and made calls to non-M routines. Every Mster that I
> know of realizes that for some things, compiled code is better; I used
> to write routines in C, for instance, and link them to the DSM
> interpreter very easily. Now it is true that at that time we were not
> using dynamic link libraries, but I don't recall very many systems
> that did.
As you are talkng about DSM your scope must be in the 80's. No wonder that
you will not remember dll access, because it is a MS-windows format. DSM in
many cases was a standalone system that time and did not have a underliing
OS. No OS, no library convention. Just ZCALL ' s. I think this is a
difference and it was never standard M, and it was never portable to any
other than DSM.
Explicitly with DSM you could not load any other M program into your
application, from a third party e.g., without checking out very closely the
names, the global usage and the local symboltable usage. You had to trust
in the programmer, that he will not use argumentless Locks or Kills. And
you needed the source therefore. I think it was much easier to link the C-
module to your M system than link another M program.
That was what I tried to say. There has never been a market for M
programming except as an inhouse programmer or an associate freelancer to a
big inhous application. The only M-companies I knew, writing applications
and components where Data-Methods and Cybertools, and I knew them just for
a short while.
Aaron Seidman
> As you are talkng about DSM your scope must be in the 80's. No wonder that
> you will not remember dll access, because it is a MS-windows format.
I think I misunderstood your comments. My observations were meant to point
out that even in the eighties there were M systems that could make use of
libraries -- in the case of DSM, through Z-calls. At that time MS-Windows
was not yet the important platform that it is today, and DLLs were still
being developed.
> DSM in
> many cases was a standalone system that time and did not have a underliing
> OS.
I am not sure I follow. DSM ran on VMS, which is still around because it
only needs to be rebooted when the hardware is shut down (and is probably
the most secure OS that I've ever used). It had also been ported to run in a
Unix environment, although that version never made it to commercial release.
> no library convention. Just ZCALL ' s. I think this is a
> difference and it was never standard M, and it was never portable to any
> other than DSM.
The M standard was constantly being revised -- too slowly perhaps -- and
plans were in the works to add standardized library functions and external
calls. Many of these revisions developed out of proprietary innovations
implemented by various vendors. This does not negate your main point, that M
apps were mostly written as closed systems.
Aaron Seidman
Armin van Harten
> The M standard was constantly being revised -- too slowly perhaps --
> and plans were in the works to add standardized library functions and
> external calls. Many of these revisions developed out of proprietary
> innovations implemented by various vendors. This does not negate your
> main point, that M apps were mostly written as closed systems.
Thanks for your remarks, Now I see what you wanted to say.
About the standard revisions after 1995 I must say, I didn't care any more,
because they didn't announce something realy important. I remember when I
found some whitepaper in the web about the handling of GOTO from within
dotted subroutines. That was the point when I came to the conclusion that
those guys are realy going crazy. Obviously many of the implementors
thought the same way and the 1995 standard was the last wich was almost
completely implemented by all of the vendors.
The MDC managed it to survive a few years more. But for my eyes, they did
not see what the real problems where until the end. It's one mystic thing
about isolation, one looses his capability to reflect the own position.
I remember when I started Delphi a couple of years ago and successively
explored the OO and component oriented world of programming. It felt like
suddenly I was reconnected to the world again. When I was hired to serve
some old M system, the contrast was very sharp.
Armin van Harten
Jim Self
> Hello,
>
> the IF/ELSE/$T issue is annoying and during the last 15 years where I
> have been using Mumps, I never figured out the reason behind it. I
> really do wonder how many times I did not think of that issue and am
> producing unexpected results with my code ;)
One thing I *would* prefer to have changed in MUMPS about IF/ELSE/$T
would be to stack $T when calling any subroutine via DO or XECUTE so
that the state of $T at any point in the execution of a given block of
code could be totally determined by inspection of just that local
context. That would avoid the unexpected result you are wondering about
- yes?
Unfortunately, that "fix" would break existing code that depends on the
current behavior. I know that the VA Fileman used to depend on exactly
that behavior in the code that it generated for running database
searches. If it still does, that "fix" would break applications in quite
a few existing MUMPS installations if applied there. Not a desirable
outcome.
At the same time it might really fix an unknown number of other
applications (that may no longer be in use) that were coded by
programmers who naively worked with a less than precise understanding of
the language and therefore produced applications that sometimes worked
correctly and sometimes not.
When I started working with MUMPS 23 years ago, I was an advanced
graduate student in computer science and familiar to some degree with
around two dozen programming languages. MUMPS syntax and other features
for handling the setting and testing of logical conditions were
certainly different from the others but they did not seem at all
strange. Furthermore, MUMPS syntax had a number of advantages over most
other languages, including a certain elegance, especially in programming
multi-user applications where timeouts on LOCK and OPEN and READ came
into play.
> During the last two years we have been using parts of FreeM as a
> scripting language for an internet massive multiplayer game written in
> C(++). In that particular case a scripting language is a good thing,
> since you do not need to recompile/reboot your game for each tiny
> change, but can edit event-triggered scripts online and on-the-fly.
I think this is really important for a hospital information system as
well. When a system is in use around the clock, there is no good time to
take it out of service for software updates. Support for continuous
development of actively used multi-user systems has always been one of
MUMPS strengths.
What do you mean by massive? How many users? What other measures of size
or activity? Just curious :)
> In
> the last months, I have been introducing several people (8-10) to Mumps
> and all(!) of them had a really hard time with Mumps' strict syntax. I
> rate the missing possibility of dynamic whitespacing as another reason
> why new people really do have problems with Mumps. As a side-note -
> all(!) people really loved Mumps after they got used to it. (about one
> to four weeks per person)
>
> Another thing, which we as old Mumpsters sometimes do not think about
> anymore, but which horribly 'boggles' new people are the abbreviated
> commands and functions. 's a=$t($e($s($tr(...))))' ... Outsiders think,
> what drugs have the coders been on? -- they move away and do not even
> spend another thought.
That is one reason why I wrote a web based routine viewer that allows
the user a choice as to whether they want to see the command and
function names fully spelled out or abbreviated. It also hyperlinks all
references to extrinsic functions or subroutines and clearly
differentiates quoted strings and comments with alternate coloring or
other font style differences. Examples:
http://birch.vmth.ucdavis.edu/m2web/rtn/htEcho
http://birch.vmth.ucdavis.edu/m2web/rtn/htEcho?terse
http://birch.vmth.ucdavis.edu/m2web/rtn/htEcho?verbose
http://birch.vmth.ucdavis.edu/m2web/rtn/htEcho?verbose&case=U
http://birch.vmth.ucdavis.edu/m2web/rtn/htEcho?verbose&case=L
http://birch.vmth.ucdavis.edu/m2web/rtn/htEcho?verbose&case=M
You can substitute for "htEcho" with any other routine name from VistA
or M2Web.
>
> Mumps is not pretty and it neither is trendy. But for myself it is first
> choice for web applications. It is small, still it is able to do a lot -
> language and database. With inline HTML it is a very easy way to create
> such applications. (I will add an HTML/M script at the end of this text.)
I agree that MUMPS is a good choice for web applications. There are
quite a few functions in M2Web that can make web programming easier.
(see http://birch.vmth.ucdavis.edu/m2web/rtn/html)
I think you forgot the script.
> For web programming: I have done my share of Java, PHP, Phyton, Perl,
> Ruby connected to mainly postgres (also mysql, msql or ingres). There
> has never been a problem with the language really - it has always been
> the database performance. With a few thousands of records SQL has been
> horribly slow compared to the Mumps-$order counterpart.
It would be helpful if you could give some example comparisons and
measurements. Something that shows clear performance differences could
be one of the strongest arguments we could make for MUMPS.
>
> That little unoptimized Mumps binary (about 250k) has always been
> performing better compared to its counterparts, which were even 100+
> times the size. The reason that Mumps is not where it belongs is because
> it got no hype nor emotion. There is no PR at all. There are mostly old
> people who have been with Mumps all their live, who are happy about what
> they got. This is all fine, but we got no young people - neither do we
> seem to care about young people. There are no die-hard idiots like
> Charlie or Denver supporting it and willing to fight over it -
> permanently and all the time - 24/7. (Charlie, Denver - I am sure you
> understand that I meant that in the most positive way)
>
> If PHP had an $ORDER command, being able to step through a btree
> database, then really I would not hesitate one second. It is so much
> nicer to work with PHP, but until then ...
GT.M provides a PHP interface that gives you $ORDER etc. I have not
tried it yet because (as I understand it) it only gives access to the
basic database, not to existing functionality written in MUMPS. That
makes it unappealing to me as a first choice for the purpose of
incrementally moving forward with a large existing MUMPS based
information system such as VMACS, but it seems to hold great
possibilities for new development, especially if one is already partial
to PHP.
BTW, what is it about PHP that attracts you?
> -Axel
Armin van Harten
h...@omsoft.com:
> I have been introducing several people (8-10) to Mumps
>> and all(!) of them had a really hard time with Mumps' strict syntax. I
>> rate the missing possibility of dynamic whitespacing as another reason
>> why new people really do have problems with Mumps. As a side-note -
>> all(!) people really loved Mumps after they got used to it. (about one
>> to four weeks per person)
>>
I do not know what M Axel is using, but I was amazed when just triing MSM
with dynamic whitespacing. There was just one limit left: a single space
before and after the argument of a statement (even if it is a null
argument) but that was all, and with Cache it is the same. So dynamic
'whitespacing' is a fact in M as in other languages, although the standard
may tell something different.
> Another thing, which we as old Mumpsters sometimes do not think about
> anymore, but which horribly 'boggles' new people are the abbreviated
> commands and functions. 's a=$t($e($s($tr(...))))' ... Outsiders think,
> what drugs have the coders been on? -- they move away and do not even
> spend another thought.
Until they encounter PERL...... or C or .....
But bad phrasing and super long lines, still used by many traditional M-
sters, are pretty confusing to the beginners. There is another challenge
usually found in traditional M programs : the use of GOTO ! The traditional
M-scene seems to be the last reservation wich still publishes GOTO infected
sources as some state of the art. If you could not shock the newbie 'til
here, now you get him!
>>That is one reason why I wrote a web based routine viewer that allows
the user a choice as to whether they want to see the command and
function names fully spelled out or abbreviated. <<
Or, for the traditionalists, use good old Bob Lushene's %INDEX routine
lister, wich comes along with the MSMWS utility set.
> There
> has never been a problem with the language really - it has always been
> the database performance. With a few thousands of records SQL has been
> horribly slow compared to the Mumps-$order counterpart.
If there are common interfaces, the language is truely not the part that
matters. About the SQL performance, I pass the advice I got from an SQL
professionell in Berlin: SQL performance strongly depends on a) the design
of your tableset, b) the implementation (=database, mysql usually gets down
on big volumes), and c) the nesting of SQL-expressions. If one transports a
M-wise datastructure to a SQL engine, he will get very bad results and vice
versa. M is different and so are the solutions.
> The reason that Mumps is not where it belongs is because
> it got no hype nor emotion. There is no PR at all.
Definetly! But why? The press usually is looking for news like mad, why
don't they look at this strange M thing? As you've told it: there is
nothing new here since 1994.
M also missed a lot of chances because it was unable to communicate with
the outer world, chances like:
- Datamining (one approach, long lost)
- neuronal nets (never been explored)
- Websolutions (is not realy the world of the traditional M system although
it should be)
- some particular filds of artificial intelligence (like problem diagnosis
in technical systems etc.)
- retail systems (barcode decoders etc., I do not know if there are some M-
systems here)
- EAI approaches, the full scope!! Should be M, but only cache entered the
scene yet.
Many fields where M is the best choice, but actually, there is no one who
uses it. Why? Just repeating myself: NO COMPONENTS! NO THIRD PARTY
SOFTWARE! NO LIBRARIES. One has to write and support 100% of 100% on your
own. With other tools you only have to write and maintain 30% of 100%.
I would give the best chances for future approaches to GTM, not because it
is the fastes, but it has currently the best interfacing in/out by
competitive costs.
Armin van Harten
IfmD - consulting GmbH
+49 6441 67142 0
Axel Trocha
> Axel Trocha wrote:
[..]
>> During the last two years we have been using parts of FreeM as a
>> scripting language for an internet massive multiplayer game written in
>> C(++). In that particular case a scripting language is a good thing,
>> since you do not need to recompile/reboot your game for each tiny
>> change, but can edit event-triggered scripts online and on-the-fly.
>
>
> I think this is really important for a hospital information system as
> well. When a system is in use around the clock, there is no good time to
> take it out of service for software updates. Support for continuous
> development of actively used multi-user systems has always been one of
> MUMPS strengths.
>
> What do you mean by massive? How many users? What other measures of size
> or activity? Just curious :)
The game is a MUD and still in its development stages, which probably
will never end ;) At the moment there are about 6500 unique rooms,
populated by 700-1000 computer controlled 'mobiles'. But massive was
mostly meant in terms of the number of concurrent users. We did
simulations with 200 - 2000 concurrent users controlled by another
computer. Till now there only have been about 50 real users online,
mostly because we were still building. Not that the number will grow
much beyond 100, since MUDs are just not popular anymore.
Anyways the Mumps Scripts only trigger for selected, special or rare
occasions. Functions which are permanently used or which need a lot of
time are competely coded in C/C++.
[..]
> I think you forgot the script.
oops, I did :) I will attach it at the end.
[..]
>> the database performance. With a few thousands of records SQL has been
>> horribly slow compared to the Mumps-$order counterpart.
>
> It would be helpful if you could give some example comparisons and
> measurements. Something that shows clear performance differences could
> be one of the strongest arguments we could make for MUMPS.
I will have to dig through my backups. I think the main advantage of
Mumps is the tight integration of the database into the programming
language. It is all up to the coder when he stops a '$query'- or an
'$order'-loop. '$order'ing especially through a multi-dimensional
global, with a few IF's which terminate early under certain
circumstances were a lot faster. But of course this advantage produces
an equal disadvantage on the other hand. The code and the globals tend
to get ugly and unreadable ... after some time and some 'last-minute'
hacks. And no, I will not dive into this in particular.
[..]
> BTW, what is it about PHP that attracts you?
PHP for instance offers tons of built-in interface functions to
applications like web servers, internet (pop3, imap, ..) and databases.
There are libraries for nearly everything which you can think of. So
Armin got the point here, since with Mumps you would start struggling
with the interface functions, while in PHP or anything similar you would
start writing the application.
Another reason is popularity. There are so many more PHP coders. So
people who are looking to hire someone to lets say do a web app would of
course want their application to be coded in PHP or something close to
the mainstream, because otherwise they are scared to be left alone or be
stuck with some M idiot - pardon me.
None of those points weights a lot for me though. I have always enjoyed
coding on the lower level: Z80, 6510 or later x86 assembler or C/C++. I
like to implement stuff on my own and get to know how things work
instead of just using them. So I am not that threatened by M.
regards
Axel
>-------------------------------------------------------------------------<
This is part of some test web application doing 'whois'-domain queries:
whois ; whois-interface ; rc0.0.2 ; A.Trocha
i $g(id)="" g ^index
i $g(^id(id))="" g ^index
d ^init
s domain=$g(domain)
<html>
<head>
<title>[ whois ]</title>
d ^head
</head>
<body>
d ^menu
<table width=$(wid)><tr><td>
: Hier können Sie abfragen, ob die Domain, die Sie verwenden
wollen,
: noch frei ist.
</td></tr></table>
<form method=post action=mumps>
<input type=hidden name=rou value=whois>
<input type=hidden name=id value=$(id)>Ihr Domain-Wunsch:
<input type=text name=domain value="$(domain)">
<input type=submit name=submit value=submit>
</form>
i $g(domain)'="" d domain
</body>
</html>
h
domain ;
;--- filter spaces
s domain=$tr(domain," ")
;
;--- concat '.de' if no dot
i '$f(domain,".") s domain=domain_".de"
;
;--- more than two dots -> error
i $l(domain)-$l($tr(domain,"."))'=1 d q
. <b>Invalid syntax.</b>
;
;--- if not '.de' -> error
i $p(domain,".",2)'="de" d q
. <b>Fehler: Diese Domainendung gibt es nicht oder wird von uns
nicht
. :unterstützt!</b>
;
;--- domain name should not have less than three chars
i $l($p(domain,"."))<3 d q
. <b>Fehler: Domainname darf nicht weniger als drei Zeichen
haben!</b>
;
;--- extract domain without country code
s topl=$p(domain,".")
;
;--- IDN 'umlaut' conversion
x "!<echo "_topl_" | /usr/bin/idnconv"
s qdom=$g(%(1)) i qdom="" s mode=-1 g err
s qdom=qdom_"."_$p(domain,".",2)
;
;--- send OS whois command
x "!whois -T ace,dn "_qdom_">/tmp/whois."_$j_" 2>>/tmp/whois."_$j
;
s mode=0
;
; <mode> = -1 query failed
; = 0 domain not free
; = 1 free!
;
x "!<grep 'status:' /tmp/whois."_$j
i %=0 d
. s mode=-2
. x "!<grep 'not found in database' /tmp/whois."_$j
. i %=0 s mode=-1
. e s mode=1
e d
. s %(1)=$tr(%(1),$zmu,$zml)
. i $f(%(1),"free") s mode=1
. e s mode=0
;
<b>
err i mode=-1 <font color=red>* Abfrage fehlgeschlagen</font>
i mode=0 <font color=red>* '$(domain)' ist leider nicht mehr
verfügbar.<font>
i mode=1 d
. <b><font color=green>* '$(domain)' ist noch verfügbar.</font></b>
. <br><br>
. s l=$$^a("reg","domain")
. <a href="$(l)">Wollen Sie '$(domain)' registrieren?</a>
;
<table width=$(wid) cellspacing=0 cellpadding=1 bgcolor=black>
<br><br>
<tr><td>
<table width=100% cellspacing=0 cellpadding=4 bgcolor=#f5f5f5>
<tr><td>
<pre>
;--- send file to stdout
s err=$zos(14,"/tmp/whois."_$j)
</pre>
</td></tr>
</table>
</td></tr>
</table>
x "!rm -f /tmp/whois."_$j
h
bhaskar
[KSB] <...snip...>
> Many fields where M is the best choice, but actually, there is no one who
> uses it. Why? Just repeating myself: NO COMPONENTS! NO THIRD PARTY
> SOFTWARE! NO LIBRARIES. One has to write and support 100% of 100% on your
> own. With other tools you only have to write and maintain 30% of 100%.
>
> I would give the best chances for future approaches to GTM, not because it
> is the fastes, but it has currently the best interfacing in/out by
> competitive costs.
Thanks for the optimism. FWIW, and for anyone interested, I recently
rambled about the philosophy of GT.M in another group
(http://lists.topica.com/lists/hardhats/read/message.html?sort=d&mid=909813341&start=6162).
-- Bhaskar
k dot bhaskar at sanchez dot com <-- send e-mail here
Axel Trocha
> (http://lists.topica.com/lists/hardhats/read/message.html?sort=d&mid=909813341&start=6162).
*cheers Bhaskar* great and fitting comment!
[quote]
> It's late, and I have rambled on more than I intended to, so I will
> stop here. My two bits' worth to the discussion, however, is that
[/quote]
IMO, that is the attitude to do great in the game! (at least for
yourself) Not that I did experience a lot of GT.M yet, but you got both
of my thumbs!
Axel
Jim Self
> I do not know what M Axel is using,
FreeM - that info was in the text that you removed from your reply.
>but I was amazed when just triing MSM
> with dynamic whitespacing.
I prefer to call it arbitrary whitespacing because it is generally
disconnected from the logical structure of the program. It can be quite
misleading, especially when it occurs at the beginning of a line where
it is used to indicate the nesting of logical structures. I have seen
many errors, in C and Perl for instance, where programmers couldn't
figure out what was wrong with their code because they were paying too
much attention to whitespace and missing the discrepancies between that
and the elements that really mattered - "{" and "}".
Axel wrote this (your quoting confused who wrote what in my previous
message):
>>>Another thing, which we as old Mumpsters sometimes do not think about
>>>anymore, but which horribly 'boggles' new people are the abbreviated
>>>commands and functions. 's a=$t($e($s($tr(...))))' ... Outsiders think,
>>>what drugs have the coders been on? -- they move away and do not even
>>>spend another thought.
>
>
> Until they encounter PERL...... or C or .....
>
> But bad phrasing and super long lines, still used by many traditional M-
> sters, are pretty confusing to the beginners.
Bad phrasing, whatever that is, would seem to be confusing to everyone,
beginner or not. Many traditional MUMPS programmers have not had formal
training in computer science or significant exposure to other
programming languages. One would expect their phrasing to improve with
experience and good examples.
Long lines of code are not necessaily bad nor confusing. I think that
that depends on what is going on in the line and on the tools available
in the programming environment for viewing the source code.
MUMPS seems to lend itself more than many other programming languages to
a paragraph style of coding where a line of code would contain a
sequence of related commands similar to the sentences of a paragraph in
English and other natural languages.
A good routine viewer or language-aware editor can radically improve the
readability of code that might seem too dense for viewing in a dumb text
editor or simple text dump.
>> That is one reason why I wrote a web based routine viewer that allows
>> the user a choice as to whether they want to see the command and
>> function names fully spelled out or abbreviated. <<
>
> Or, for the traditionalists, use good old Bob Lushene's %INDEX routine
> lister, wich comes along with the MSMWS utility set.
Bob Lushene's %INDEX was invaluable to me in learning MUMPS way back
when. (Thank you, Bob) When I first discovered it I began using it to
"pretty print" every MUMPS routine in CoSTAR and Fileman and several
other public domain packages. Then after wasting a few reams of paper
with printouts that I was never going to read, I discovered that most
routines were easier to read in their unexpanded form and that generally
I only wanted to see the expanded form for one particularly complex line
out of hundreds.
quoting Axel here again:
>>>There
>>>has never been a problem with the language really - it has always been
>>>the database performance. With a few thousands of records SQL has been
>>>horribly slow compared to the Mumps-$order counterpart.
>
>
> If there are common interfaces, the language is truely not the part that
> matters. About the SQL performance, I pass the advice I got from an SQL
> professionell in Berlin: SQL performance strongly depends on a) the design
> of your tableset, b) the implementation (=database, mysql usually gets down
> on big volumes), and c) the nesting of SQL-expressions. If one transports a
> M-wise datastructure to a SQL engine, he will get very bad results and vice
> versa. M is different and so are the solutions.
Again, it would be helpful if you could provide some concrete comparisons.
quoting Axel (not me) again:
>>>The reason that Mumps is not where it belongs is because
>>>it got no hype nor emotion. There is no PR at all.
>
>
> Definetly! But why? The press usually is looking for news like mad, why
> don't they look at this strange M thing? As you've told it: there is
> nothing new here since 1994.
It seems to me that there has been tremendous innovation related to
MUMPS since 1994, but perhaps you weren't paying attention or perhaps
you didn't recognize it when you saw it or have forgotten. For us (VMTH
UCD), 1994 was the beginning - not the end - of a long period of
innovation. That was about the time that we realized that MUMPS was well
suited for use as a server of web applications and that we didn't need
to wait for any vendor to come along with a radically changed version of
the language before we could begin to pursue a stable long-term path to
future technology.
We (VMTH UCD) implemented our first MUMPS based web server in 1994. I
have been trying to share ideas and to encourage MUMPS programmers to
develop web applications ever since. Of course, that has never been big
news. We were just a small group of MUMPS programmers with nothing to
sell who had found a practical way to move our existing applications
forward to new technology at virtually no cost and without breaking old
applications on the same platform.
Other MUMPS programmers found their own way to do web applications, some
before us and some after. Eventually, MUMPS vendors came up with their
own solutions.
> M also missed a lot of chances because it was unable to communicate with
> the outer world, chances like:
My own opinion is that calling it M instead of MUMPS is part of the
problem. You can't very well google on M or for that matter on Cache'.
I also disagree with your statement that MUMPS was unable to communicate
with the outer world. We have had networking, including TCP/IP for a
very long time now.
> Many fields where M is the best choice, but actually, there is no one who
> uses it. Why?
How do you know that they don't? It seems to me that MUMPS users have
generally been fairly quiet about their successes and that the
distinctions as to why MUMPS might be the best choice for an application
(or not) have not always been obvious, especially to people who lack a
working knowledge of MUMPS.
>Just repeating myself: NO COMPONENTS! NO THIRD PARTY
> SOFTWARE! NO LIBRARIES. One has to write and support 100% of 100% on your
> own.
Again, this is not true. When I first came to MUMPS in 1981 I was
astonished at the plethora of available *FREE* software in MUMPS.
Fileman and CoSTAR and %INDEX have already been mentioned. I remember
that I had access to many more. Some of those have been an integral part
of our applications development from day one.
Non-Free MUMPS software tools and libraries have always been available
also, some of them quite good - and often quite expensive. However, I do
agree that there seems to have been a historical bias against
incorporating third party software into applications and the historical
lack of separation between user interface and database operations in
many applications has made it sometimes difficult.
I myself have written a number of tools that could be useful to other
MUMPS programmers and that could greatly simplify or otherwise improve
many applications. I would be glad to do more of that if people gave me
feedback with bug reports or fixes, feature requests, help with
documentation, etc.
>With other tools you only have to write and maintain 30% of 100%.
>
> I would give the best chances for future approaches to GTM, not because it
> is the fastes, but it has currently the best interfacing in/out by
> competitive costs.
What I think may be the most important factor in the future success of
MUMPS is the fact that MUMPS implementations, including GT.M and
MUMPS_V1 and Kevin O'Kane's MUMPS compiler and FreeM, are available as
Open Source. This means that instead of complaining about this or that,
we can actively participate in fixing the problems that we see (real or
imagined) and openly share our solutions for review and discussion and
improvement by others.
Also please note that Bhaskar left a link in another message in this
thread to a very well written (as usual) message that he posted
yesterday in the hardhats forum.
Jim Self
> Jim Self wrote:
>
>> Axel Trocha wrote:
>
> [..]
>
>
> oops, I did :) I will attach it at the end.
Your FreeM script is eye opening. The non-standard inclusion of HTML
code interspersed with MUMPS could bear some discussion. It is an
interesting technique that undoubtedly has some advantages. I am sure
there are differences, but it looks very similar to a provision for HTML
and other non-MUMPS that is allowed by Kevin O'Kane's MUMPS compiler.
> [..]
>
>>> the database performance. With a few thousands of records SQL has
>>> been horribly slow compared to the Mumps-$order counterpart.
>>
>>
>> It would be helpful if you could give some example comparisons and
>> measurements. Something that shows clear performance differences could
>> be one of the strongest arguments we could make for MUMPS.
>
>
> I will have to dig through my backups. I think the main advantage of
> Mumps is the tight integration of the database into the programming
> language. It is all up to the coder when he stops a '$query'- or an
> '$order'-loop. '$order'ing especially through a multi-dimensional
> global, with a few IF's which terminate early under certain
> circumstances were a lot faster.
This begins to touch on what I think are MUMPS greatest strengths. This
subject needs closer examination and discussion to bring it out to a
larger audience.
> But of course this advantage produces
> an equal disadvantage on the other hand. The code and the globals tend
> to get ugly and unreadable ... after some time and some 'last-minute'
> hacks. And no, I will not dive into this in particular.
I would appreciate it if you would. I have a utility that includes a
fairly general iterator for efficiently traversing a large class of
MUMPS global structures based on a succinct non-procedural
representation. I am curious as to whether it would apply to your
situation. If it does or could be extended to do so, it might largely
cancel out the negatives you refer to.
> >-------------------------------------------------------------------------<
>
> This is part of some test web application doing 'whois'-domain queries:
Please describe the syntax and function of the non-standard parts of
your code. It looks like you are using some interesting conventions:
< - in place of a command appears to be an introducer of output text
$() - in the text apparently identifies MUMPS variables to be
interpolated into the text
: - ?continues text to next line?
! - appears to introduce a call out to Linux shell. Is it used only
in argument to Xecute?
Are these extensions to FreeM that you added?
Kevin O'Kane
C code and also has a routine to parse, decode and
instantiate as variables data sent thru QUERY_STRING
from HTML forms.
As to the question "why mumps", I discovered this week
that Mumps seems to have become the underground implementation
language of choice among several of our UG students. After
a rigorous and pedantic indoctrination in the virtues of an
orthodox OO paradigm thru the joy of Java, it seems that several
have nonetheless selected Mumps to implement their web based
interactive expert systems in fulfillment of UG BS research
requirements. I discovered this when I was approached regarding
a link library issue that was causing problems.
So, from the available empirical evidence, the answer to
"why mumps" is: its quicker and easier, especially for active
server pages.
Res ipse loquitur!
--
Kevin C. O'Kane
University of Northern Iowa
Cedar Falls, IA 50614-0507
(319) 273 7322 (Office + Voice Mail)
(319) 266 4131 (Iowa)
(508) 778 9485 (Massachusetts)
http://www.cs.uni.edu/~okane
ok...@cs.uni.edu
Axel Trocha
> Axel Trocha wrote:
>>
>> This is part of some test web application doing 'whois'-domain queries:
>
>
> Please describe the syntax and function of the non-standard parts of
> your code. It looks like you are using some interesting conventions:
>
> < - in place of a command appears to be an introducer of output text
>
> $() - in the text apparently identifies MUMPS variables to be
> interpolated into the text
>
> : - ?continues text to next line?
>
> ! - appears to introduce a call out to Linux shell. Is it used only
> in argument to Xecute?
No, it was encapsulated by Xecute so I was able to use some M variables.
Yes, ! as a command does execute the following text in a shell. If <
follows after the !, then the 'stdout' produced by the shell is stored
in %(i). If > follows, then %(i) is send to the shells 'stdin'. I found
this to be extremely useful.
To make life easier for web applications and to get rid of a CGI wrapper
routine, I added following:
1) mumps detects if it is called by CGI. (Environment variables
QUERY_STRING and/or REQUEST_METHOD are set)
2) if it is called in a CGI, the variables/arguments contained in the
QUERY_STRING or from STDIN are imported. If 'rou' is an imported
variable, then its given value should be a routinename, which is
executed just after.
3) in CGI mode a QUIT on the lowest execution stack level behaves as
HALT.
4) CGI/HTTP server variables are imported into %cgi(..)
5) multipart/form fileupload is possible
6) 'content-type: text/html\r\n\r\n' used to be sent automatically
before the 'rou' routine was executed. I changed that recently, so it
is only sent just before the routine wants to make the first output
to STDOUT. This has two nice advantages.
a) it is possible to change the content-type (for instance to image
with $zhttp("CONTENT-TYPE","image/png"). The given value is then
sent as content-type just before the routine does the first
output.
b) it is possible to send HTTP headers ($zhttp("RAW_HEADER",..)) with
cookies in particular $zhttp("SET_COOKIE",..)
(the contents of a received cookie would be in %cgi("COOKIE")
=> see 2)
7) now to your initial question about the non-standard parts:
a) if '<' is just where a Mumps command woudl be expected by the
interpreter, then the '<' plus all following text of the line are
sent to stdout. This allows us to use 'inline' HTML, which
makes a routine a lot more readable compared to WRITE "<html>"
etc...
- if $(<varname>) is part of that inline HTML, this construct is
substituted by the given variable value. Very useful.
b) if ':' is where the interpreter would expect a command, the
following line contents are sent to stdout
regards
Axel
bhaskar
[KSB] <...snip...>
> My own opinion is that calling it M instead of MUMPS is part of the
> problem. You can't very well google on M or for that matter on Cache'.
Jim, I planned to reply to your message saying that the biggest reason
to call it M rather than MUMPS was that the latter was a registered
trademark of Massachusetts General Hospital. However, just for the
heck of it, I went to the US Patent and Trademark Office web site
(http://www.uspto.gov) just now, and found that the MUMPS trademark
registration has expired.
Now, the biggest reason to use M rather than MUMPS is the single
letter tradition!
-- Bhaskar
Harlan Stenn
>to call it M rather than MUMPS was that the latter was a registered
>trademark of Massachusetts General Hospital.
And Octo came to the MDC and said he did it specifically to stop any
vendor from doing it first and then preventing other vendors from calling
their implementation "MUMPS".
He also said that in doing so and by explicitly not chasing any of the
vendors who called their product "MUMPS" it effectively forced the name
"MUMPS" into the public domain.
H
Ed de Moel
> My own opinion is that calling it M instead of MUMPS is part of the
> problem. You can't very well google on M or for that matter on Cache'.
That's why I usually call it M[UMPS].
That's a letter combination that is not even shared on Google/Yahoo/...
by the subject of medical papers on childhood diseases.
Ed de Moel.
Jim Self
For some reason I didn't think that searching on M[UMPS] would work.
I tried it on google and I see that it works quite well.
among other things, I found a page
(http://207.192.157.194/mdc/quotes.htm) that appears to be one of Ed's
with M(umps) related quotes, including one attributed to me.
Jim A. Self:
M[UMPS] gives you a lot of rope to hang yourself.
Well, here I am 15 years later, still hanging and doing fine.
If my math is correct, that was from 8 years ago - and we are both still
here and apparently still doing fine :)
Enjoy!