std-mumps@plus5.UUCP (12/14/84)
From: Hokey (The Moderator) <std-mumps-request@plus5.UUCP> Ansi MUMPS digest Thursday, 13 Dec 1984 Volume 1 : Issue 6 Today's topics: ansi standard [Jose Speaks] ---------------------------------------------------------------------- Date: Wed, 28 Nov 84 08:21:02 pst From: wucs!ihnp4!ucbvax!ucdavis!clover:rojas (Jill Rojas) Subject: ansi standard The new number is ANSI/MDC X11.1-1984 I hope this is all the information you needed. Jill Rojas for Dr. Walters ------------------------------ Date: Thu, 6 Dec 84 10:09:09 est From: wucs!ihnp4!watmath!wateng!jmmussi (Jose Mauro F. Mussi) Subject: mod.std.mumps Hi Hokey, I am very glad to see a news group about MUMPS on the USENET. I hope this might lead to finding out just how many MUMPS users are connected to the net. In reference to digest V1 #4 where you provide a memo describing the semantics of MUMPS symbol operations, I have a few questions to make: a) Were these features approved in the last standard (the one mentioned in V1 #5) or are they still in discussion? [DEC wants to use the ideas described in the memo as a working model for describing the symbol table interface within the Standard. I suspect the items you are describing (the NEW command for environment control and parameter passing/extrinsic functions) are Type A releases of the MDC. HMS] b) Is it possible to obtain a few examples (very simple) of how this would look in a real program and in which way does it differ from the available commands? Also, will you be able to send as one of the future digest a short description of the new standard that was recently approved (ref. V1 #5)? [I will try to get an on-line copy of the new Standard. HMS] Enough of questions. Here is some food for thought about MUMPS. ------------------------------------------------------ Where will MUMPS be in the future? As an enthusiast of the MUMPS language for many years and more recently a daily user of UNIX O.S. I can't help to wonder what effect the rapidly changing computer market will have on current systems. MUMPS is a very good example of a language that has been changing to keep up with the new needs. Developed at a time when mini-computers were still a new idea, memory was very expensive and limited and existing operating systems were almost unberable, MUMPS was designed to be small, memory efficient and above all very simple to use. This was possible since is was not only a new language but was also the O.S. Today the scenario has changed drastically. Computers have improved in speed, memory size, and in price (well, most of them did). The new generation of micros have much more capacity than the PDP-11 and are being used by much more informed users. It seems clear that many of the original premises on which MUMPS was built do not hold true any longer. It is not necessary to optimize the use of memory space (at least not in the same drastic way). What a user looks for in a system today is: a) ease of use, b) reliability, c) portability, d) performance, e) security, f) distributed environment, g) existing software packages. I believe item (a) is still the greatest advantage of MUMPS. Although a MUMPS program might look cryptic to someone who is seeing one for the first time, most concepts of the language are very simple to understand. I have personally trained more than 40 programmers and even though most of them had no previous programming knowledge, all of them were writing good programs in less than 3 months. Of course there are still some drawbacks like documentation that must be improved (but is there any language that does not have this problem?). Item (b) is very implementation dependent but is still a very important aspect when dealing with MUMPS. The nature of the applications most often using MUMPS makes any system very dependent on the integrity of the global variables (files). The tree structure frequently used (either AVL or B*) are vulnerable at certain times (i.e. killing of a sub-tree) to errors. If the filing system is not carefully designed to recover from such errors, the integrity of the global variables can be very easily corrupted. In my view, MUMPS portability (item c) is at least as good as that of any other standardized language. Almost all implementations I have seen (except MIIS) offer full standard compatibility. Usually the only exceptions are language extensions to handle specific interactions with the underlying operating system (I know of MUMPS systems running under CP/M, MS-DOS and UNIX). These extensions are easy to detect since the standard provides a common name range for them. Performance (item d) is often the greatest complaint from the users. MUMPS is an interpreted language and therefore [HMS: interpretIVE, not interpretED ] exhibits a considerable overhead for command interpretation. Also, all number values are stored in their ASCII form which can increase considerably the time needed for numerical operations. There are, of course, techniques that can reduce the effects of these problems in the overall performance of the system but it seems that most implementations lack them. Even in the best cases, the performance of a MUMPS program will always be less than that of other programming languages like C, Pascal or even compiled BASIC. I have always had the opinion that the gains obtained during the development of application systems are much more important the a slower execution time. I might add that just as important is how little time it takes to change an application due to some new user need. But still, efforts to improve MUMPS' performance must be continuos, specially in respect to the full utilization of the underlying hardware. The next item (e), security, is also implementation related, but was one of the concepts used since the beginning of the language. Each user space is well separated and there is no way a normal user can interfere with the operating system. In my opinion, item (f) is the one that deserves the most attention. The availability of small powerful work-stations and the advantages of distributed applications have created new complex requirements for software. Although MUMPS can be vastly benefited by a distributed environment (large performance improvement), it does not provide the necessary mechanism to implement efficient distributed applications. There is no inter-process communication and lacks ways to execute remote (inter-processor) operations. Finally, the fact that MUMPS is an interpreted language also discourages de development of general purpose software. The programs can only be distributed in source code which makes piracy a very common and simple task. This means that most programs are hand-crafted for each case (very expensive) or adapted from small packages that can be obtained from users' groups like MUG. There should be a way to prevent this situation to permit an increase in the available software base (item g) for MUMPS. The above comments are in no way exhaustive or necessarily correct. They just reflect my personal opinion and I hope this will bring more discussions about the future of MUMPS. Jose Mauro Fialho Mussi Dept. of Electrical Engineering University of Waterloo Waterloo, Ont., N2L 3G1 Canada ------------------------------------------------------------ Note: Hokey, this letter ended up much longer than I had expected. Please feel free to use your unrestricted powers as moderator and cut out anything you don't like. jose. [Jose, I apologize for the delay in posting your submission. It arrived while I was out of town last week, and I have been fighting a backlog of news from our feed which has been soaking us dry for both space and inodes for several days.] ------------------------------ End of Ansi MUMPS digest ************************ -- Hokey ..ihnp4!plus5!hokey 314-725-9492