On Apr 2, 2:54 pm, Lee <l...@[EMAIL PROTECTED]
> wrote:
[KSB] <...snip...>
> But the more general question still remains: When, if ever, is it time
> to re-implement a perfectly good application system because its software
> technology is obsolete, or growing near obsolete, or has become too
> eccentric and isolated from the main stream of the software "State of
> the art" ?
>
> Presumably this is an engineering question to be disposed of
> dispationately based on a cost benefit analysis made as objectively and
> rationally as we can manage.
[KSB] A system that is continuously re-engineered to keep it
contem****ary should in theory never become obsolete, even if, in the
fullness of time, none of its original lines of code remains. Such a
system should always be more cost effective than a complete
replacement. But fail to re-engineer, and it will indeed become
obsolete and worth replacing.
[KSB] <...snip...>
> Hardware advances since the 1970's have been compelling. Software
> advances, I opine, have been somewhat less so, but still, much water has
> passed under the proverbial bridge since then:
>
> Mumps, I'me given to understand, has grown some ACID properties, or at
> least the tools to implement ACID, though the mumps programmer, if I've
> not been misled, is free to leave himself or herself open to
> inconsistent results, lost updates, deadlocks and such like annoyances
> by not using the features, or by not using them properly.
[KSB] With GT.M, use the TStart / TCommit commands to bracket the code
that you would like to have ACID properties.
As for inconsistent results, lost updates, etc., the most
sophisticated transaction processing system, the most object oriented
language, and the most intuitive of compilers cannot stop a programmer
from shooting himself in the foot. Software systems can encourage
good programming practices, but they cannot enforce it. I can write
obfuscated code in any language, and I can write maintainable code in
any language.
Where I see MUMPS as weak is in encapsulation and information hiding
(but take a look at Esi Objects - http://esiobjects.sourceforge.net).
> How much further development its undergone I cant really say. I suppose
> there's a "how many hairs make a beard problem" here. How different can
> it become and still "Be" good old Mumps?
>
> In the old days it was of course a character mode system. Is it still?
> Has it grown GUI parts? It was a "Terminal based" system, i.e. a single
> tier. Has it become client/server and/or N tier since then? Has it
> become integrated with the web? Are there provisions for source code
> control and configuration management? An IDE? One would think that the
> essentially hierarchial nature of the data model would lend itself to
> XML tools? Are there any for Mumps?
[KSB] The different MUMPS implementations have evolved in different
ways. Some have indeed grown a plethora of features.
The philosophy of GT.M has been small is beautiful. We have stayed
focused on what it does well, and made it easy to leverage the
surrounding operating environment for what it provides. Thus, GT.M
doesn't implement its own security, but is secure because it uses the
operating system's security features. You can set it up to serve
requests under the control of the standard Internet superservers,
inetd/xinetd. At the same time, it has unique features for robustness
and continuity of business that even the major brand name relational
databases lack.
> From what I remember of mumps, its distinctive feature was its close
> integration of its "data base" with the language, and the notion that
> all its global persistent variables could be considered as sparse
> arrays. I suppose its not fair to consider Mumps as "only" a language,
> because it sup****ted multiple simultaneous terminal users, as did
> Dartmouth Basic and APL (Two contem****ary languages/systems of the
time)
>
> I know a bit more about SQL, so I can attest that today's SQL is a far
> cry from what it was way back when.
>
> I havent followed UNIX in detail, but I understand that it too has
> undergone quite a bit of development "under the hood".
>
> If we had to use 1970's operating systems and the 1970's versions of
> languages which survive today in updated forms, we would be tying our
> hands behind our backs, but as you point out, all of those have evolved
> and are not exactly what they were then, any more than Paris is what it
> was at its founding.
[KSB] I can't speak for other MUMPSen, since I have never used any
other, but GT.M at least is continuously evolving and for the better,
I hope. In the last year, for example, in addition to a significant
enhancement to its continuity of business capability, we also added
sup****t for Unicode.
Incidentally, at least one or two people still use a programming
language that also has its origins circa 1970 - C. How much has that
evolved and how fast? It seems that when something works well, it's
best to use it without changing it significantly, but to let it evolve
gradually as the needs change.
Regards
-- Bhaskar
|
