It is currently Thu Mar 28, 2024 12:04 pm


All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 14 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Generations of MUMPS (and Mumpsters)
PostPosted: Sun Nov 14, 2010 2:27 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
There have been six generations of MUMPS so far, and a seventh is coming. Likewise, Mumpsters are classifiable in part by which generation of MUMPS they first learned, which helps define their perspective on what's old and what's new, which style of programming feels most natural, and so on. This thread will explore those generations. Where generation of Mumpster are you?

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: The First Generation of MUMPS (and Mumpsters)
PostPosted: Sun Nov 14, 2010 2:30 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
1: 1966-1977 (original MUMPS and the many prestandard MUMPS implementations that followed). Octo Barnett, Bob Greenes, Curt Marbles, and Neil Papalardo launched the first generation of MUMPS when they created it on those first machines in the corner of the animal-testing lab in the basement of Massachusetts General Hospital. They launched the medical-informatics revolution that resulted in an explosion of companies and MUMPS dialects in the late 1960s. Their success set in motion everything that followed, including (as successes always do) creating the problems that the next generation of MUMPS was launched to resolve.

By 1972 there were too many semi-compatible versions of MUMPS, making it increasingly difficult to exchange MUMPS software, so Ted O'Neill launched the standardization effort with the creation of the MUMPS Development Committee in 1973. Their work culminated in 1977 with the third programming language ever standardized by the American National Standards Institute, MUMPS 1977.

I would love to see descriptions of the original MGH MUMPS and of the many implementations that followed it. This was before my time.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Second Generation of MUMPS (and Mumpsters)
PostPosted: Sun Nov 14, 2010 2:41 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
2: 1977-1984 (MUMPS 1977). 2,000-character routines and symbol tables and strictly-interpreted code made storage and performance the paramount architectural concerns. This is very terse code.

The execution stack is short, so the foundational routines are all using the Goto command to keep as much of the stack as possible free for the application routines to use. Later Mumpsters are shocked by all the use of the Goto, but it made far more complex software possible by preserving the stack for additional, independent applications to use.

It pre-dates negative and string subscripts and $Order, so we don't have real indexes yet, just the upright file with its numeric record numbers. File Manager's ^DIC lookup still contains the ability to search the upright file for lookup matches; that dates back to the time when there were no string-subscripted indexes to check for matches.

We don't yet have the Job command, so all the code we're used to queuing into the background instead have to run in the user's process. That is, users are either waiting for print jobs to finish before moving on to do their next task, or they're using the old trick of Closing the principal device to force the print job into the background, which then requires the user to sign in again to continue. When I began with MUMPS in 1984, that latter trick was often used, but by 1990 the spread of the Job command had made it quite rare.

We also don't yet have Set $Piece, so we have a lot of concatenation in our database update lines. You can still see a lot of code in Fileman that pre-dates Set $Piece.

Without the New command, namespacing of variables is our primary way to allow code from multiple packages to run in the same process without stepping on each other. Partly out of inertia and failure to fully refactor the code to take advantage of the later New command, and partly for very good reasons this site will explore, even with the introduction of the New command the use of namespacing remains crucial to VISTA's architectural integrity.

On the plus side, since standard MUMPS is new, a lot of the code hasn't grown complex enough to require the later MUMPS features for managing package interactions. Even better, since projects like VISTA/DHCP/etc. are new, building upon very little previous code, the developers have tremendous freedom to innovate and design architecture.

Mumpsters from this era are conceptual revolutionaries who can think outside the box because when they started the only boxes were technological limitations like small symbol tables - they didn't have to worry about backward compatibility until later. Likewise, in the VISTA world these are our most experienced Mumpsters - it was they who designed and wrote the software during the underground that became the core of VISTA - so they often think outside the box because they know the box better than the rest of us do.

Many of these Mumpsters are retiring today. If we know what's good for us, the rest of us will spend as much time as we can learning from these founders. The world owes them a great debt that can only really be repaid by paying it forward to the next generation and to the patients and care givers they will help.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Third Generation of MUMPS (and Mumpsters)
PostPosted: Sun Nov 14, 2010 3:12 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
3: 1984-1990 (MUMPS 1984). This was my generation. I started with MUMPS and VISTA in June 1984, so I read and worked with code and within an architecture created during the second MUMPS generation, but almost all of the code I've written has been third-generation or later. This is the version of MUMPS that for me is the "Mumpsiest," and everything since then has been some kind of extension, but of course that's just a trick of perspective.

String subscripts and $Order are the most important thing in this period - along with the gradual migration away from the older $Next, which was limited by its definition to numeric subscripts - so indexes are spreading everywhere in the database. Designing the support for compound and other complex indexes in the mid-1990s was one of my big contributions to File Manager, and in hindsight it makes sense that the version of MUMPS I started with was the one that made such things truly possible.

Likewise, the Job command is making its presence felt, as developers move more and more of the execution out of foreground processes and into the background so that users can focus on the tasks that require their presence. In the VISTA world, Dr. Dave Wilson's Task Manager module was written at Oklahoma City VA Hospital and soon adopted by the Kernel package to wrap up the Job command in a suite of tools to put background jobs more under the control of system managers. In 1986, I was hired by the VA national development organization, and for the next seven years I worked on Task Manager, so here again my career was very much defined by the central features of the generation of MUMPS I started with.

The memory given to symbol tables and routines is doubled to 4,000 characters, subscript lengths are expanded up to thirty-one characters, and full variable references are lengthened to sixty-three. We're all a bit giddy from the extra room to grow. Some of us start commenting our code. Others start properly namespacing our variables, since now we have more room to make it practical to use longer names. The terseness of the code begins to loosen up a little, and the lines begin to breathe.

Above all, the 1984 standard made obviously important improvements to the previous generation of MUMPS. What that taught us is faith in progress, the belief that our fate was in our own hands, that our community organizations really could surf with the technology curve to lift us all up - and during this time we successfully ported VISTA to run on new hardware platforms and new implementations of MUMPS - so all of this powerfully reinforced our commitment to the underlying principles of standardization and vendor-independence that made our code so portable and extensible.

The third generation of Mumpsters weren't revolutionaries, but we were children of the revolution. Most of us (not including me) started out as users of the MUMPS software developed during the second generation and understood how revolutionary user-driven software development is from direct experience, so when we became developers we were already believers in the core founding principles. So although the third-generation Mumpsters were not themselves revolutionaries, they were fellow travelers and sympathetic to the revolution.

On the other hand, the third-generation of Mumpsters were usually designing and developing within the framework of an existing architecture. There were still many opportunities to invent new packages from scratch to handle the features the second-generation hadn't yet written, so the third generation actually created more original authors than the second did. Many third-generation developers, though, only ever worked on extending other people's ideas and code, and these Mumpsters developed a less revolutionary, more scholastic, process-oriented, editorial approach to MUMPS programming. That is, the third-generation of Mumpsters were a less characterizable group in terms of their style and approach to design and development; this pattern gets stronger for the next two generations, before the VA's cultural collapse in the late 1990s recreated the kinds of pressures that can unite a generation.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Fourth Generation of MUMPS (and Mumpsters)
PostPosted: Sun Nov 14, 2010 6:03 pm 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
4: 1990-1995 (MUMPS 1990). As MUMPS 1984 and VISTA (DHCP as it was known then) succeeded and led to increasingly complex software, it created its own problems, following the cosmic principle that success breeds failure. First, angry vendors who felt MUMPS's success robbed them of potential profit launched increasingly transparent attacks on MUMPS and MUMPS-based systems, leading to an interesting and developing new vein of insecurity and overcompensation. Second, the increasingly successful MUMPS systems grew complex enough that a new generation of execution- and variable-scope-management tools was needed. Fourth-generation MUMPS addressed both problems. The results showed in both the code and the new Mumpsters from this generation.

The New command, parameter passing, and functions (extrinsic calls and argumented Quit) introduced outstanding new power for controlling the scope of variables. Since variables are the greatest common source of spaghetti logic in MUMPS, these improvements were much needed, much used, and began a dramatic change in the look and feel of MUMPS code that is still playing out, since some packages introduced these new features more quickly and thoroughly than others.

Likewise, argumentless Do did the same for the scope of execution by (1) breaking free of the line-oriented length limitations of For, If, and Else that used to cause us to add named subroutines for no better reason than to extend the amount of logic within their scope, and (2) creating anonymous subroutines whenever we wanted to, for example to create variable-scoping boundaries for the New command to work with. Stacking $Test within do-blocks was crucial to making the former work.

Getting control of these two kinds of scope - variables and execution - extended our ability to reduce unnecessary complications (like labels we didn't need) and to increase needed system complexity (like more sophisticated package interactions). This was the standard that made MUMPS able to handle the open-ended development needed for enterprise-level systems.

This fourth generation also included some nice syntactic sugar - argumentless For got rid of the need for throw-away loop variables, Set $Extract simplified our handling of fixed-length fields, merge simplified our ability to move whole trees of data about, $Query made traversing trees easier, and $Get helped get rid of some ugly $Select/$Data constructs for handling potentially undefined variables - even aside from the usual collection of minor extensions and corrections. Routines and symbol-table sizes were only raised another thousand characters, but that still felt like plenty considering all the ways this standard gave us to reduce the size of our code by using the new, more concise language constructs. Likewise, the maximum variable-name length was doubled again to one hundred twenty-seven characters, to give us more room to name our increasingly complex data structures.

This was also the era in which we extended our standardization from the MDC and ANSI to include FIPS and ISO, making MUMPS a very standardized language indeed with an overtly international audience.

When experienced Mumpsters think about or talk about old MUMPS versus new MUMPS, we almost all agree that MUMPS 1990 is the dividing line. This was new MUMPS (with the New command no less), even though everything added to it is a refinement of what came before. Like MUMPS 1984, we almost all agree it was an almost entirely successful extension of the language - addressing the biggest problems and doing it almost perfectly.

Almost.

Because of the pressures the MUMPS community was under from hostile non-MUMPS companies, at the same time MUMPS was becoming an overtly modern, sophisticated, and international language, Mumpsters themselves were developing a defensiveness about their software they hadn't shown before. They became concerned not just about being effective but also about appearing effective. And modern. And being accepted by the larger computer-software community. This led to some problems that have plagued us since.

First, with modernism on their brain, Mumpsters decided to modernize the name of their language in the hope of making it more acceptable and marketable in the larger world. In hindsight, this was a naive mistake. The folks attacking MUMPS weren't doing so because of its name - that was just a cheap shot - but because they were either competitors trying to destroy support for MUMPS software so they could replace it with their own, or they were programmers proud of and committed to other programming languages who liked taking potshots at anything different than what they knew. Changing the name could do nothing to stop either kind of attack; the first group needed us to cease to exist, the second needed us to be what they already knew and preferred, in other words, to blend in and conform with them. In neither case could we remain Mumpsters or our language MUMPS, regardless of the name. This is more apparent twenty years later than it was at the time, which is why the community thought it would be a good idea to rename the language from MUMPS to M; MUMPS 1990 introduced M as an alternate name for MUMPS, with plans to swap the two names in the next standard, which it did.

It's important to note the cultural sea change in this capitulation. Not only were Mumpsters trying to change the name of their language, rather than choosing an original name that conveyed medical informatics in any way they opted for the most anonymous name they could think of - and in clear imitation of C, aping the mainstream in the hope of being accepted by them. It didn't work - it could never have worked - and the important thing about it is not its success or failure as a strategy but the deep and novel insecurity it revealed.

Second, also with modernism on their mind, the MUMPS community opted to begin phasing out the $Next function. It was made inadequate by the introduction of string subscripts in MUMPS 1984, since $Next's start and end values couldn't be changed without breaking existing software, and so couldn't be extended to handle string subscripts. That's why MUMPS 1984 introduced the $Order function, which was defined with start and end values to cover all conceivable subscripts now or in the future. That raised the problem of what to do with the $Next function. There were only two options: (1) to redefine $Next so that it made sense within the new subscripts, even though it had to remain as limited as ever, or (2) to remove $Next. The former would have allowed existing software to continue to work, but it would have left the old function as a historical appendage. The latter would make the language look ahistorical and "clean" - "modern" - but it would break all the existing MUMPS software that used $Next. MUMPS software is designed to develop over very long periods of time, so backward compatibility has always been a crucial guiding principle. With MUMPS 1990, the MUMPS community announced its intention to phase out $Next and required Mumpsters everywhere to rewrite all their $Next code to replace it with $Order. This was a very non-Mumpsy thing to do, but consistent with the name change it signaled an emerging insecurity so deep that they were willing to cause problems in order to improve their appearance.

Third, and in hindsight somewhat astonishingly, this MUMPS standard was not supported by a new Standard MUMPS Programmers' Reference Manual, nor a new Computer Programming in Standard MUMPS, nor a new MUMPS Primer, and the state-transition diagrams were removed from the standard rather than being updated. This was a third break with the past, and in some ways the worst of all. Without the MUMPS Primer and Computer Programming in MUMPS, the standard teaching material needed to train a new generation of Mumpsters was missing; we didn't notice at the time in part because there were excellent MUMPS training vendors at work in the community, but now the gap has become apparent and painful. Likewise, without the Programmers' Reference Manual the community lacks a fuller explication of what the standard means; the standard itself is extremely terse, so programmers need the fuller elaboration of its significance to fully master the new techniques. This is the first MUMPS standard that was never fully mastered by a surprising number of Mumpsters, many of whom still don't fully grasp how the New command or call-by-reference works, for example.

Since ANSI and ISO feel very proprietary about the text of the MUMPS standard, the Reference Manual is the only complete explanation of the MUMPS standard the MUMPS community itself owns. Leaving it out of date has put the MUMPS community in an awkward position, since now we don't have a ready-to-publish explanation of MUMPS that we have a right to publish ourselves.

The MUMPS Books project has made these problems so clear that I'm astonished we didn't notice at the time. Why didn't we update these three books again, as we did when we created the 1984 standard? Why only the standard and the pocket guide? Couldn't we see what the consequences would be? I don't know the answers to these questions - I would love to hear whether the principal players at the time know the answers - so I'm going to speculate based on what was happening at the time, and this is my fourth issue with MUMPS 1990.

Fourth, this was the first MUMPS standard not designed to be self-sufficient, to stand on its own even if no further standards came along. With the name change and the phase-out of $Next, MUMPS 1990 needed the standard that would follow it to finish what it started. We had become focused so much on the process of improving MUMPS rather than a specific result, that we were willing to release a standard that was not 100% stable, that depended on the future to complete what it started. Further, we had become so focused on being accepted more broadly and on the appearance of modernism that we were willing to break our commitment to backward compatibility and even try to change our identity.

None of that's speculative; it's right there in black and white in the text of the standard itself.

Here's the speculative part. I think the reason we didn't update the three works that were supposed to accompany the standard is that we either forgot or dismissed the issue, that we either didn't notice the omission or forgot its importance, that we'd lost track of the fundamentals because we were so focused on and proud of the standard itself. When the 1990 standard was approved by ANSI, we were already working on getting it approved by NIST and ISO and more to the point we were working on what would become the 1995 standard, which even in 1990 we knew would be full of exciting MUMPS extensions. We were too busy preparing for the next generation of MUMPS to finish the current one. I suspect we as a community decided either consciously or unconsciously to put off updating the supporting works until the next standard - not realizing that we were going to make the same decision after the 1995 standard was completed.

As we'll discuss in the next generation, the release of the 1995 standard was accompanied by an almost delirious excitement, pride, and sense of progress. I don't think that came out of nowhere.

It's worth noting that the 1995 standard had the same kinds of strengths and weaknesses this one did - revolutionary new extensions, problems with backward compatibility, and a failure to update the three supporting books - only more pronounced. The 1990 Standard MUMPS Pocket Guide was at least complete; the 1995 Standard M Pocket Guide, which I wrote, was published before we could finish describing the 1995 language, and the other 1995 standards never got any supporting material at all. We started work on the 1995 Reference Manual, but we were spread too thin, working too hard on putting the new standard to work and on creating the next one, to have the time to really focus on it, so it never got beyond an outline.

Further, the 1995 standard contained errors in the standard itself. The $Reference extension didn't make it into the 1995 standard, even though it was meant to, and even though part of the standard actually names the missing system variable. As we discovered later, the error-processing extensions were full of ambiguities that later MUMPS extensions had to clean up. And we're currently exploring the transaction-processing extensions looking for similar but subtler problems.

My fourth point, then, is that MUMPS 1990's revolutionary qualities came with and perhaps were even symptomatic of and driven by a growing insecurity among Mumpsters that led to a change in focus toward progress and modernization that led to sacrifices being made in some of MUMPS's fundamentals. In our race to get to the future, we'd lost track of the importance of creating a stable, sustainable present.

Mumpsters from this era tend to embody that enthusiasm, insecurity, and confusion. They're modernists, focused on improving the old code and finding ways to demonstrate their modernity and high-tech credentials. They're the first generation of Mumpsters who really feel shame about MUMPS, specifically about "old" MUMPS, but they're also proud of "new" MUMPS. They write code using the new scoping features, which lets them create innovative and complex architectures, and they think a lot about how to "modernize" MUMPS and VISTA. Though they're as excited as any other generation about the chance to write a new package from scratch, they don't often get that opportunity because so much architecture has already been created in the systems they work on. Refactoring is a big attraction for these Mumpsters, because with so few new packages to write this is how they can master the software they work with. They're change agents who work to revolutionize what already exists.

I know this because when the 1990 standard came out I and most of my peers fully embraced this culture and internalized it. It was the logical progression of the work I'd already done refactoring Task Manager, and it offered me the tools I needed to take that work to the next level. I and most other Mumpsters eagerly embraced the many good things about this standard, even as many of us also unfortunately unconsciously absorbed the insecurity and focus on modernism and popular acceptance. The balance on this standard was easily, overwhelmingly on the good side.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Third Generation MUMPS and Mumpsters - Subscript Indirection
PostPosted: Wed Nov 17, 2010 10:30 am 
Site Admin
User avatar

Joined: Mon Nov 01, 2010 1:58 pm
Posts: 205
Location: Seattle, Washington
Real Name: Frederick D. S. "Rick" Marshall
Began Programming in MUMPS: 15 Jun 1984
Taking a step back to the third generation, MUMPS 1984 also introduced subscript indirection, also known as partial indirection. Here's an example:

Code:
S U="^"
S TITLE="Cordelia's Honor"
S AUTHOR="Bujold,Lois McMaster"
S ENTRY=42
S ROOT="^TMP($J)"
S @ROOT@(ENTRY,0)=TITLE_U_AUTHOR
S @ROOT@("B",TITLE,ENTRY)=""


Subscript indirection allows you to use indirection for the first part of a local or global reference but then use direct subscripts for the last part of the reference. It is extremely useful for writing database-management applications, in which the same routine may modify different files (with different global roots, thus the indirect part of the reference), all of which share a common structure (with the same fields placed on the same subscript and node structures, thus the direct part of the reference).

It was specifically added to MUMPS at the request of George Timson, who served for a while on the MUMPS Development Committee, to make it easier to write File Manager.

Subscript indirection allows you to replace some powerful but fairly ugly name-indirection code, in which you concatenate together all the pieces of the global or local reference into a string and use the indirection operator on the whole thing every time. The final three lines of the code above look like this without subscript indirection:

Code:
S ROOT="^TMP($J,"
S @(ROOT_ENTRY_","_0_")")=TITLE_U_AUTHOR
S @(ROOT_"""B"","_TITLE_","_ENTRY_")")=""


With all the extra parentheses, quotation marks, and concatenation operators, the second-generation approach to writing database-management code required a higher degree of MUMPS expertise to read, making it less accessible.

I wrote before that fourth-generation MUMPS was the first that many Mumpsters never mastered, but upon reflection I've come to realize I was wrong about that. Subscript indirection was introduced in MUMPS 1984, third-generation MUMPS, but for a long time it didn't catch on the way it should have. Through the 1980s and early 1990s, File Manager and the rest of VISTA largely continued to be written with the older, more awkward form of name indirection despite the availability of subscript indirection.

I was as guilty as everyone else of failing to use the newer, clearer syntax. Honestly, I didn't even notice it was there, despite studying MUMPS repeatedly using all the books available. As part of the MUMPS Books project, I'm going to have to review all these works to find out whether they fully explained it or not; I suspect I'll find it was presented at best briefly without a clear explanation of how and why to use it, though it's certainly possible it was fully explained and I and everyone else just missed it.

I believe I had a hand in finally pushing the spread of subscript indirection in VISTA. The story goes like this, in two parts.

First, by the time I was hired by the File Manager team in the early 1990s, I had become a big believer in refactoring, and I had studied MUMPS 1990 very closely and begun applying its improved scoping tools to Task Manager. When Maureen Hoye told me of the difficulties the team had had with some of the difficult code in File Manager, I proposed resolving the problem by refactoring all of Fileman using the new 1990 features, a proposal that was at first greeted by the team with horror and dismay. Eventually (a story for another time) we compromised by creating the new File Manager Database Server (DBS) calls using the new 1990 features. The whole Fileman team added to this new API.

Second, early in this period I had a conversation with George Timson about our intentions, which he supported. He pointed out the existence of subscript indirection and explained its history, which convinced me to make it central to our new Fileman DBS calls. Thus, the spread of subscript indirection, a third-generation feature, wasn't rolled out into File Manager until the spread of the MUMPS 1990 features, during the fourth generation of work. Where the classic File Manager calls, most of them created before 1984, are built on open global roots, like ^DPT(, that are suitable for concatenating together strings for doing name indirection, the Fileman DBS calls are all built on closed roots, like ^VA(200), that are ready for subscript indirection. As other VISTA packages began using the new DBS calls, they also began using subscript indirection. Today, subscript indirection still hasn't spread nearly as far throughout VISTA as it should.

It has the potential to significantly improve the readability of indirect MUMPS code, which would greatly increase its maintainability by making troubleshooting easier and also making extension of the code less prone to errors due to misunderstanding the meaning of the existing code. What spread it has had so far was largely due to the modernizing impulse of the fourth-generation Mumpsters, including the third-generation Mumpsters who adopted that culture after 1990, but those of us in the third generation during the 1980s almost universally missed the boat at the time it was first introduced. Until the 1990 standard transformed us, we in the third generation were not modernists at all; we were moved by different priorities, and it wasn't until those priorities changed that we fully began to appreciate the power of this overlooked feature.

Spreading this third-generation feature throughout VISTA will be one of the important ingredients in the MUMPS and VISTA renaissance coming with the seventh generation.

_________________
Frederick D. S. "Rick" Marshall, VISTA Expertise Network, 819 North 49th Street, Suite 203, Seattle, Washington 98103, (206) 465-5765, rick dot marshall at vistaexpertise dot net
"The hidden harmony is best." - Heraclitus of Ephesus


Top
Offline Profile  
 
 Post subject: Re: Generations of MUMPS (and Mumpsters)
PostPosted: Sat Aug 20, 2011 5:59 pm 
User avatar

Joined: Mon Nov 01, 2010 1:39 pm
Posts: 51
Real Name: John Willis
Began Programming in MUMPS: 01 Apr 2010
This series of posts is very fascinating and enlightening! I have thoroughly enjoyed reading it.

_________________
John Willis, Founder
Coherent Logic Development
http://youngmumpster.wordpress.com/
jwillis@coherent-logic.com


Top
Offline Profile  
 
 Post subject: Re: The First Generation of MUMPS (and Mumpsters)
PostPosted: Thu Sep 01, 2011 4:14 am 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 104
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
toad wrote:

I would love to see descriptions of the original MGH MUMPS and of the many implementations that followed it. This was before my time.


I have in nearly pristine condition:
Code:
MUMPS-11 Release Notes
Order No. DEC-11-MMGSA-B-D
First Printing, January 1976
Revised:            May 1977

Sundry Digital Software News and Small Buffer Articles

MUMPS-11 Operator's Guide
Order No. DEC-11-MMOPA-E-D
First Printing, October 1972
Revised:        October 1973
                October 1974
               February 1976
                    May 1977

INTRODUCTION TO MUMPS-11 LANGUAGE
Order No. DEC-11-MMLTA-C-D
First Printing, June 1973
Revised:         May 1974
                July 1974
            Janurary 1976

MUMPS-11 Language Reference Manual
Order No. DEC-11-MMLMA-D-DN1
April 1977 UPDATE NOTICE NO. 1

MUMPS-11 Programmer's Guide
Order No. DEC-11-MMPGA-E-D
First Printing, October 1972
                October 1973
               November 1974
                January 1976
                  April 1977

Note: Some documentation includes later updates



Top
Offline Profile  
 
 Post subject: Re: Second Generation of MUMPS (and Mumpsters)
PostPosted: Thu Sep 01, 2011 4:21 am 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 104
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
toad wrote:
2: 1977-1984 (MUMPS 1977). 2,000-character routines and symbol tables and strictly-interpreted code made storage and performance the paramount architectural concerns. This is very terse code.


Actually the big save here was single character variable names with the more commonly used at the front of the sort order. Hence the most commonly used variable name was percent (%).

Of course ALL commands were written as one character.


Ray


Top
Offline Profile  
 
 Post subject: Re: Second Generation of MUMPS (and Mumpsters)
PostPosted: Thu Sep 01, 2011 4:38 am 
User avatar

Joined: Mon Nov 01, 2010 3:33 pm
Posts: 104
Location: Australia
Real Name: Ray Newman
Began Programming in MUMPS: 01 Jul 1976
toad wrote:
2: 1977-1984 (MUMPS 1977). The execution stack is short, so the foundational routines are all using the Goto command to keep as much of the stack as possible free for the application routines to use. Later Mumpsters are shocked by all the use of the Goto, but it made far more complex software possible by preserving the stack for additional, independent applications to use.


No - the Goto command was/is used because it is an efficient way to program IF YOU KNOW WHAT YOU ARE DOING!.

The stack (even on things like DSM-11) was reasonably deep.

I have just noticed that I have the Source of DSM V2 (16 Nov 1982)
and the source of MUMPS 4B dated 3 Sep 1979 both on (probably 800BPI) tape.

and great heaps of Microfiche (mainly RSTS though).

AND 8 inch floppies from 1977 that say MUMPS.COM and MUMPS.ASM that I think I got from Richard Walters.

How was that for getting off the topic.


Ray Newman


Top
Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ]  Go to page 1, 2  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 27 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net