comments inline below
--- Robert Witkop <[EMAIL PROTECTED]> wrote:
> Hi Chris, et. al.,
>
> I am out of the woodwork. Cache and MUMPS offer capabilities not
> found in
> most ohter languages.
Absolutely. If anything, I think the MUMPS community has failed to
effectively get the word out that the language has some very powerful
capabilities that are very much of interest today. Perl and Python have
more successful in this respect.
>
> For a newcomer, MUMPS is easy to write, but hard to read. This is why
> one of
> the first tools a newcomer will write is a pretty printer. Once
> getting over
> the intial shock of being able to abeviate the commands, most (not
> all, I
> still write full commands) will begin to abbreviate the commads.
>
I don't know that it's exactly easy to write. Certainly, a minimal
MUMPS program is much simpler than a minimal Java program (or even a
minimal C program), but are realistic programs really easier to write?
But, of course, that wasn't your point. I occasionally compose Java or
C code in vi(m), but generally prefer to use an IDE like Xcode or
Eclipse if one is available. Similarly, I like Komodo for Perl. I can
format my own code, but I'd rather have an editor do a lot of the
tedious work for me than think ("Okay, let's see, that's 8 times I need
to press <space>". Even in vi, the autoindent, shiftwidth and showmatch
options can make life a lot easier.
>
> As Chris mentioned, I have written a MUMPS to C++ transformer, but
> fortunately, have never done a transformation except as a proof of
> concept.
> The main reason I wrote the transformer in the first place, is to
> convince
> OTP (Otherwise Intellegent People) that by translating their
> applications to
> C or C++, they are only translating their problem. The message I send
> them
> is "don't kill the language, kill the programmer", because with power
> comes
> responsibility, and if the application failed, the programmer failed.
I haven't seen your transformer, but that's an interesting concept. I
actually think we understimate what can be done with automated analysis
and translation tools, but certainly a mechanical translation would
produce code no one wants to seriously consider using!
>
> Some Cache/MUMPS aplplications, like VistA are stable, and I grant
> you
> although, no sotware application is perfect, VistA is carefully
> maintained.
Uh...I don't think patched in ad hoc fashion counts as "carefully
maintained", but I agree that a lot of conscientious effort goes into
maintaining VistA.
> In my entire career, I have only written one application that ran the
> first
> time, and no one ever found a bug in it. The only reason the program
> worked
> correctly the first time, is because in the early days, computer time
> was
> very expensive, and we spend days/weeks reviewing our code before
> running
> the application on the computer.
I've written code that's run without bugs being reported AFTER it was
released. I don't know that I've ever written anything that worked
perfectly in every developer test! I've always been impressed by people
who managed to develop significant amounts of code with nightly batch
runs.
>
> The power I have enjoyed from Cache/MUMPS, after having to interface
> with
> databases from other languages is that I have direct access to the
> data.
If there is a single "home run" in the MUMPS language, it has to be the
global. I agree completely.
> The
> problem with other languages is that databases are an afterthought,
> and like
> any other Kludge, it can be ugly, even if it works (somewhat).
Again, I agree. The introduction of "tie" in Perl 5 was a big
improvement, but it's still an example of trying to splice a new
concept into the language after the fact.
Another issue that is (in my opinion) more than cosmetic is the fact
that MUMPS arrays may have values at any node. Off hand, I can't think
of a single language providing a structure like this, but decorated
trees (and other graphs) are pervasive in computer science. It really
makes you wonder why this construct is not directly supported in more
languages.
>
> Most languages (I lost count of how many I use) were created for a
> specific
> problem, and they do well when they are used for the problems they
> were
> created for.
Hmm...Some languages are very specialized, focusing on a particular
problem or type of problem, but others are geared more to an
application domain (e.g., Fortran and scientific computing). Other
languages (like Algol, and later, Pascal) were designed to be simple,
to abstract away from domain specific features and focus on the very
basic task of expressing algorithms effectively. In general, I think I
agree, perhaps with a little qualification.
> MUMPS was created to satisfy the needs of the medical
> world,
> and it did very well for many years.
Well, it was certainly developed initially for medical applications,
but there's nothing about it that is particularly medical. I don't
disagree with either point you are making here, only I think it is
worth pondering what it is about MUMPS that has made it useful for
medical (and financial) applications.
> The only reason I have switched
> from
> MUMPS to Cache is that it gives me backward compatibility with MUMPS,
> a good
> database, and I can write object-oriented applications that are
> easier to
> maintain, and easier to interface with other technologies.
And that is the principle reason for my interest in Cache. I am also
interested in other possible directions, such as functional
programming, that are less directly supported by MUMPS or Cache, but I
have long found object oriented languages to be useful and interesting.
>
> OK, I am returning to observer mode.
>
Don't do that!
> Bob
>
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Design quality doesn't ensure success, but design failure can ensure failure."
--Kent Beck
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
