In late 1992, my manager, that had recently left the company called me and asked me if I had any knowledge of MUMPS. My immediate reply was "not since I was a child". He was serious, and I seemed to remember someone mentioning it as a computer language. Next, he asked me if I could evaluate it since I had experience using a multitude of computer languages, and so, I purchased my first MUMPS book.
My feeling of languages is that they cannot be learned or evaluated by looking through a book. The price of a MUMPS interpreter being more than I wanted to pay, I decided that I would write an application so that I could write MUMPS code, and convert it to `C' in a manner similar to the early Ada `compilers'.
I had previous experience writing assemblers, interpreters, and translators, I even created my own special purpose language (REDR) for a large project at one time. When I tried to apply the standard techniques to translating MUMPS to `C', I found that MUMPS was a very non-standard language. I did learn enough about MUMPS so that I could give an evaluation.
I was hired in mid 1993 to work for my previous manager at his new company. My assignment was to introduce analysis and design techniques to the programmers / analysts. Unfortunately, before I arrived, a rumor had started that I was coming in as a "MUMPS killer". The majority of the programmers there were not programmers at all. They did not come from an engineering or computer science background, but from medical backgrounds. Because MUMPS is a very simple language to write, these doctors, nurses, technicians and administrators were able to embed their domain knowledge into MUMPS code. Unfortunately, the code was the documentation as well.
With the constraint that I could not force the programmers to learn structured techniques, and could only attend design sessions if invited, there was very little to do. Fortunately, the customer for the system had a desire to see a design for the large undocumented system. A decision was made to develop a set of analysis tools so that the system could be reverse engineered by extracting the design from the code.
In an effort to maintain ownership of the tools, I was to lead the development, but not take part in the design decisions or actual development. We hired a very intelligent Ph.D. candidate from a local university to do the development. The student majored in compilers, and developed a good set of tools that constructed an Abstract Syntax Tree (AST) from MUMPS code. He also provided a library with an interface so that scripts could be written and linked with the library to traverse the tree.
The student built an interactive mode into most of the scripts he developed, and I offered a class in the use of the scripts. Unfortunately, the biggest question was "why didn't you build it with MUMPS". At that time, I wondered if they realized that MUMPS was probably not written in MUMPS.
I was not constrained from using the tools, so I began to write various scripts. I was also responsible for running the scripts to generate the documentation for the system.
Other companies heard about the tools we had and asked if we could help them document their systems. The first time I ran an analysis for an external customer, I found that our tools were tailored to a single system, with its coding conventions. Since the outside code did not conform to the conventions for the system the tools were developed for, their MUMPS code could not get through the parser.
Fortunately, the tools were developed on a UNIX system so I had access to all the utilities (i.e. awk, sed, grep, and several others) to modify the source code to conform before it is passed through the tool set. I also had to write the scripts to translate the modifications on the output. This helped my design decisions when I decided to design a new set of tools.
In addition to requests for analysis and design extraction, I periodically received requests to use the tools to write a translator to convert MUMPS code to `C' or `C++'. I had many arguments for not writing a translator, including "it should not be done", "it is too difficult" and "it can't be done".
One day (in September 1996), a gentleman I have never met, but had several phone conversations with called and asked if I had developed a MUMPS to C translator yet. I started my normal "why we do not want to do that" speech when he interrupted and challenged me to "quit making excuses and write the translator". Ordinarily, I would have ignored any statement like that, but due to previous conversations with him, I felt like it was a challenge.
My manager gave me permission to take the tools home and port them to Linux. I was happy to discover that because Linux is POSIX compliant, and the UNIX system I worked with at the office was POSIX compliant, all I had to do to port the code was make a slight change to the Makefiles. Having failed writing a translator using the accepted techniques, I decided to try something different. Instead of translating the code to C, I would transform the code to C++. In 1997, when I was contacted by a company that desperately wanted to convert their system from MUMPS to C++, I had a proof-of-concept to demonstrate for them.
Unfortunately, the timing was bad. We had to get the contract approved through the corporate office. At the time we were trying to get the contract to do the conversion from MUMPS to C++ approved, the contract for the MUMPS system the company maintained, was being challenged by another company that wanted to convert it to another language. The corporate office argument to the customer was that since there was no means to automate the conversion, it would be too expensive.
My manager was told that we should "no bid" the contract, and I should seek employment elsewhere as punishment for developing the capability on my own initiative.
Now, I knew how to transform MUMPS code to C++, but I didn't have access to the tools.
It didn't matter, because the tools were not being maintained, and the MUMPS standard was extended since the tools were developed. The students contract expired in 1995 and no effort was made to extend the tools to meet the changes in the language.
I transferred from Software Engineering to Systems Engineering after the student left, and only ran the analysis tools as needed. The tools also provided a means to instrument the code and do dynamic analysis, so I was doing performance analysis on the MUMPS code in a test environment.
After leaving the company, I was able to get a copy of the latest MUMPS standards and wrote the rules for a lexer and parser. Rather than try to incorporate coding conventions into the rules, I chose a very loose set of rules that would create an AST node even if the code had an error. I also reduced development time by not putting in capability for interactive analysis into the scripts, but at the same time, I didn't design the capability out. Allowing the error tokens to be passed to the scripts caused the scripts to become more complex than the previous scripts, but I have the advantage of being able to analyze an entire system without having to wait for the errors to be corrected. The compiler model AST constructor would not include the code from offending files in the AST construction.
I had to redevelop all my scripts since my AST constructor and interface were incompatible, but I had the advantage that comes from doing it the second time (lessons learned and shorter development time). Also, I chose to reduce the number of the scripts by combining their capability in other scripts.
The script that generated the structure charts and annotation files required a very expensive CASE tool that is tied to an equally expensive database. I developed two different scripts to document the control flow. The first is named mflow and it does for MUMPS what cflow does for `C'. But in addition to producing the call tree, it also can show implicit and explicit parameters. The second generates structure charts with annotations using JAVA and HTML that can be viewed by any browser. The month required to add the structure chart and annotation files to the database for the CASE tool is also eliminated since no database is required.
I have located and sent email to the student who developed the tools for my previous employer, but have not heard from him yet. He now teaches computer science at a university on the east coast. The tools he developed are excellent and met the requirements that were given to him. I regret that the way the contract was written I could not work closer with him. But, then my tool development philosophy might have been incorporated in the company tool set, causing a problem with intellectual rights.
Automating the transformation of MUMPS code to C++ is not the end of the story. A translator or transformer for computer languages will not be 100% successful. With MUMPS, there is more to consider than the code. MUMPS globals are really accessing a hierarchical database that is built into the MUMPS interpreter. In the transformed code, I have created a class GlobalData that replaces the global references in the MUMPS code, but it currently only contains the hooks that must be implemented depending on the database engine chosen.
My transformer translates approximately 95% of the code and marks the remainder for manual intervention. The transformer will in most cases attempt the transformation, but will generate compile time switches to turn on the intervention warnings and / or errors to identify the code that needs modification or inspection.