It was great to meet up with you in person. We have since moved house a couple of times and haven't managed to find a curry house nearby that is anywhere near as good as the Royal India.
MUMPS tends to win out over other technologies when the data set is large and / or where a large number of records need to be updated as part of overnight / regular processing runs. I have used the language commercially in the financial services industry (many clients and accounts and then lots of transactions such as deals, dividends, corporate actions, banking transactions etc.) Every night our application would run through every bank account on the system (several hundred thousand of them) and then add daily notional interest to each account and then turning the notional interest into actual interest at the end of each month. This is the sort of thing that can be performed very quickly using the MUMPS $ORDER command to iterate through all of the accounts. Another commercial example is when I worked (briefly, fortunately) for a company that offered software for the shipping industry. Very large data sets are created when you get into the realms of creating manifests for containerized transportation / shipping and the analytics behind calculating profit / loss and working out what fees should be to transport containers indirectly between ports involves a lot of data and is well suited to being addressed using MUMPS.
The language is really in its element when it comes to medical records - it was written with this use case in mind. The MUMPS database that held all of the records for Vietnam vets (military, medical, pension) was for a while the largest database in the world (so I was told). Many hospitals and other medical facilities in the US and UK still use systems that are written in MUMPS.
If you wanted to build a database tracking the purchase of lottery tickets, I think that MUMPS would be ideally suited. ^TICKET(DrawDate, Sel1, Sel2, Sel3, Sel4, Sel5, MegaBall, Stack) = StoreID * DateTime of Purchase * TicketID This table would return winners for a given draw in a fraction of a second.
On a forum I frequented years ago, a member asked for a CSV that he could send to a printers to produce tickets for an event that included a unique code that could be typed in to a website after the event for a chance to win prizes. 80k codes were needed. Each code was to be 14-characters in length, unique (of course) and could not contain certain characters so that there wasn't an issue when typing in the code of getting mixed up between the letter O and the number 0 for example. Several of us had a go at putting some code together using a language of our choice. This particular task was well suited to MUMPS and nobody could get near the execution times that I was seeing (80k codes sub 1 second, 250k codes sub 4 seconds).
I've found a MUMPS emulator that runs in a browser
here. Carl (or anyone else for that matter) - maybe you would like the challenge of writing some code to meet the above spec using this emulator
I have coded it up in the emulator and I can share here (if anyone is even remotely interested).
The emulator is memory bound when it comes to screen output. I was able to create 80k records, but it will only allow me to display about 6k of them to the screen.
)