MUMPS is a powerful language when used correctly, and there are more systems written in MUMPS than I would have imagined before getting involved with it. Even changing its name to simply `M' (notice the resemblance to `C') doesn't change it. I have worked with good MUMPS programmers that are aware of the side effects of MUMPS and avoid them making their code very maintainable. The reason for changing to another language should not be just because it is written in MUMPS.
Programmers coming out of college have learned the current coding techniques and languages. In our society, newer is better, in fact, some companies give old technology new names to make it seem new, like they just invented it.
There are schools that teach MUMPS , and there are Web sites where MUMPS programmers can be found. Unfortunately, not all MUMPS programmers are good programmers. I have examined the code of many of MUMPS programmers, and am disappointed with the quality of the code and of the lack of design. The quality of the code is a reflection on the programmer, not the language.
I would never recommend switching to another language just because the system is written in MUMPS. The most important part, design, is missing from the systems written in MUMPS that I have analyzed. One of the systems (for a distribution wherehouse) I have analyzed was easy to read, it made good use of the structured constructs, had good comments, and white space to make it readable and maintainable, but unfortunately, it was poorly designed. Either by intent (legal action should be involved), or through lack of knowing how to design a database, a programmer was required to modify the code to add a new customer. This practice is very expensive for the distribution wherehouse, but a good source of income for the company that supplies the programmers.
MUMPS programmers typically will rewrite a section of code rather than fix it. This practice will usually fix one bug only to introduce another.
MUMPS code is so easy to write that programmers do not feel that it is necessary to do a design. This may not always be the case, but the only designs I have seen to date are the designs that I reverse-engineered by analyzing systems programmed in MUMPS.
There are modern systems being written in MUMPS today. I have taught design to MUMPS programmers, and some of them were eager to learn. Some older systems are written by programmers that use obscure coding practices that rely on side effects. In the early days of programming, side effects were used to enhance the performance of systems and to help reduce the number of instructions. Since the instructions were sent to an assembler, these side effects were heavily documented in comments that preceded the code.
In an interpreted language like MUMPS, comments take execution time and memory and are to be avoided. This has changed in modern interpreters. The source code can be tokenized, and the comments stripped from the executing program to enhance performance and memory usage.
Usually legacy systems are systems that have been around for a while. I think this must make them good systems since they have survived the test of time. Unfortunately, as a system ages, even if it had an initial design, the requirements and design have not kept pace with the system as it evolved to its current state.
Without a good set of requirements and good design documentation, no system can be tested. In his book, Berzier mentions `pachinko code', and I have seen more of code of type `pachinko' written in MUMPS than in any other language. These systems need to be designed and rewritten, and it doesn't matter which language is used.
I have worked on many systems where the language is decided before the requirements have been written. These decisions unfortunately are made for political reasons instead of technical knowledge. I can make any system work. However, the most successful systems I have worked on, were systems where there was intelligent, technically aware management that trusted the engineers to do the requirements and high level design before deciding on a language.
The best language will depend on the type of application. I have found that people that think that their computer language, or computer operating system is best, know only a single computer language or a single operating system. I know many computer languages and have worked with many operating systems. There is no best. There are intellegent choices to make depending on the application or system that is being designed.