6 ms·

Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day. There are modern ANSI standards for the langu

by z3ugma 10y ago

Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day. There are modern ANSI standards for the language, and several private vendors and open source implementations. There are 2 things I like about M: 1. It has limited commands and is whitespace-aware - Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures. It's easy to memorize the standard library and easy to read code (because it's whitespace sensitive like Python). 2. The NoSQL database built right into the code - You access the built-in, persistent database the same way you access regular data structures. When setting values into an array you do something like "set foo(bar)=1". In order to persist that same data to disk, you just do set ^foo(bar)=1. This means less worrying about query languages and ORMs. The database is a sparse B-tree structure so it's wicked fast at reads and writes. Great for a fast key-value store. There are people using M's battle-hardened NoSQL database with Node.js drivers, and you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance. Check out Rob Tweed's work with M: https://robtweed.wordpress.com/2012/10/24/i-have-seen-the-future-and-its-node-js-shaped/ https://robtweed.wordpress.com/2012/10/24/i-have-seen-the-fu...

jacquesm 10y ago
> Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day. I know people that love working in COBOL. For the most part that is because it is what they know. Do you have extensive experience with other platforms/languages? How do you rate them side-by-side? > and you're very unlikely to find a bug because it's been in production so long. This goes for anything that's old. But that does not equate to 'good', it's just old. Just like new isn't necessarily better old isn't either. And there are usually plenty of bugs in those codebases, just not in the runtime. But the user supplied code usually pre-dates any kind of automated (or even at all) testing other than 'try stuff and see if it produces the right results'. The MUMPS codebase I worked on in the 80's was so fragile that deleting a single global string could cause the whole system to break down in ways that required a restore from backups. Don't ask me how I know that ;)
- nobodyorother 10y ago
  I'll second that unpopular opinion and claim I have experience with many other languages that I also enjoy. The fun part about Mumps is that it's basically Lisp's ugly sibling, without meaningful scoping rules. You can easily do lots of terrible things in Mumps, but those things are usually more straightforward than the terrible things you do in other languages. You can also do elegant things, though a little less straightforwardly. My single biggest complaint about Mumps codebases is that they're usually old, which means they have shitty documentation. Not that new ones are necessarily any better, but at least there's a chance new things are written in Orgmode or something :)
  - jacquesm 10y ago
    I've yet to see a MUMPS code base that would qualify as 'elegant', do you have any pointers? I'd love to see how it should be done, the only things I've seen are examples of how things (any things!) really should not be done.
    - roywiggins 10y ago
      I witnessed a DSL for querying a MUMPS database. It used MUMPS to parse a DSL, generating more MUMPS to then query the MUMPS db. I'm not really criticizing because I'm not sure there's an elegant way to do it, but I fled screaming.
    - mabynogy 10y ago
      https://github.com/robtweed/EWD/tree/master/m_apache https://github.com/robtweed/EWD/tree/master/m_apache
      - jacquesm 10y ago
        I hope that wasn't meant sarcastically?
        mabynogy 10y ago
ivraatiems 10y ago
Do you by chance work for Epic?
derefr 10y ago
> You access the built-in, persistent database the same way you access regular data structures. Have you ever used Erlang? If so, how would you compare MUMPS' tables to Erlang's ETS/DETS tables?
play2computers 10y ago
i actually like it as well. not too unpopular after all it seems. sure, some things are a bit ugly, and language development is largely controlled by a single company (intersystems), but especially working in healthcare you can't get around it. And it does certain things quite well.
elnygren 10y ago
1. Doesn't this make business logic quite a mess because normal and standard abstractions are missing? Won't new coders make horrible solutions to "reinvent the wheel" problems? 2. It would be trivial to implement a key-val data structure that is persisted to disk in almost any nice modern language. And there are very good No-SQL key-val stores to choose from that are backed by very large and credible industries. The Node.js drivers. Are you sure those are not mainly due to legacy integrations rather than "we really just wanted to use the MUMPS db" ? http://thedailywtf.com/articles/A_Case_of_the_MUMPS http://thedailywtf.com/articles/A_Case_of_the_MUMPS
rnprince 10y ago
Sorry, I can't hop on board. My opinion is that implementing anything complex and new in ANSI MUMPS would be irresponsible given the better options available. > It has limited commands and is whitespace-aware Limited commands to a certain extent just means a more dangerous language. Being able to give functions private scope is something that's really important to me personally, as is having named constants, and objects with methods. About whitespace awareness, I consider it a fascinating design choice that the difference between one or two spaces between tokens within the same line of code can mean different things. > Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures. The language does not support first-class functions, but it does support the "xecute" command for running arbitrary code strings, which is particularly risky if you ever use user inputs as parameters in the strings you try to xecute. Also, I primarily want knowledgeable developers working on my healthcare and financial systems, not the newer ones who would somehow be incapable of using a first-class function. > wicked fast at reads and writes. Great for a fast key-value store. This isn't a differentiating feature. > you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance. What happens when you need to change the code? Do you wait a long time until bugs are no longer found?
- __float 10y ago
  You can have variable scoping, just use `new`? I think that fast reads/writes actually are a reasonably differentiating feature--if you want something like that in JS, Python, .... you're going to have to drop down to a C extension, and you'll have to put a lot of effort into that being portable. In a MUMPS interpreter, it's already there and it already works reliably.
  - rnprince 10y ago
    The scoping issue I mentioned was function scoping, not variable scoping. The language would be better for organizing code if it supported functions as methods of particular classes of objects, or functions with private scope. As a codebase gets large, how well organized the code is makes a big difference in how easy and how risky it is to change things, so it really pays for your language to make code organization as natural as possible. I am actually not able to find statistics matching up M databases with non-M databases at the moment, but I'd be interested in seeing something like that. I don't know what you mean about having to roll your own C extension to talk to your database.
int_19h 10y ago
A lot of what you're describing - in particular, "you access the built-in, persistent database the same way you access regular data structures" - was also true of many DBMS of the dBase era - dBase itself and its clones (Clipper, FoxBase/FoxPro), Paradox etc. But I think they still made better languages than MUMPS. The biggest difference, it seems, is that instead of key-value stores, you had indexed tables. However, indexes were effectively key maps - there was no SELECT as in SQL (well, there was eventually, but not at first); instead you explicitly specified the index to use - unless you used the default index for that table - and performed a lookup, and it would position the current cursor for that table to the appropriate record. You would then access fields of that record as regular variables: https://msdn.microsoft.com/ru-ru/library/bz5ys9dy(v=vs.80).aspx https://msdn.microsoft.com/ru-ru/library/bz5ys9dy(v=vs.80).a... It might sound weird, but it actually worked really well for stereotypical CRUD form-based desktop apps - your cursor corresponds to the record currently being edited/displayed.

by z3ugma 10y ago

jacquesm 10y ago

> Unpopular opinion: I actually really like working in MUMPS, which is now just called M. I develop in M every day. I know people that love working in COBOL. For the most part that is because it is what they know. Do you have extensive experience with other platforms/languages? How do you rate them side-by-side? > and you're very unlikely to find a bug because it's been in production so long. This goes for anything that's old. But that does not equate to 'good', it's just old. Just like new isn't necessarily better old isn't either. And there are usually plenty of bugs in those codebases, just not in the runtime. But the user supplied code usually pre-dates any kind of automated (or even at all) testing other than 'try stuff and see if it produces the right results'. The MUMPS codebase I worked on in the 80's was so fragile that deleting a single global string could cause the whole system to break down in ways that required a restore from backups. Don't ask me how I know that ;)

nobodyorother 10y ago
I'll second that unpopular opinion and claim I have experience with many other languages that I also enjoy. The fun part about Mumps is that it's basically Lisp's ugly sibling, without meaningful scoping rules. You can easily do lots of terrible things in Mumps, but those things are usually more straightforward than the terrible things you do in other languages. You can also do elegant things, though a little less straightforwardly. My single biggest complaint about Mumps codebases is that they're usually old, which means they have shitty documentation. Not that new ones are necessarily any better, but at least there's a chance new things are written in Orgmode or something :)
- jacquesm 10y ago
  I've yet to see a MUMPS code base that would qualify as 'elegant', do you have any pointers? I'd love to see how it should be done, the only things I've seen are examples of how things (any things!) really should not be done.
  - roywiggins 10y ago
    I witnessed a DSL for querying a MUMPS database. It used MUMPS to parse a DSL, generating more MUMPS to then query the MUMPS db. I'm not really criticizing because I'm not sure there's an elegant way to do it, but I fled screaming.
  - mabynogy 10y ago
    https://github.com/robtweed/EWD/tree/master/m_apache https://github.com/robtweed/EWD/tree/master/m_apache
    - jacquesm 10y ago
      I hope that wasn't meant sarcastically?
      - mabynogy 10y ago

ivraatiems 10y ago

Do you by chance work for Epic?

derefr 10y ago

> You access the built-in, persistent database the same way you access regular data structures. Have you ever used Erlang? If so, how would you compare MUMPS' tables to Erlang's ETS/DETS tables?

play2computers 10y ago

i actually like it as well. not too unpopular after all it seems. sure, some things are a bit ugly, and language development is largely controlled by a single company (intersystems), but especially working in healthcare you can't get around it. And it does certain things quite well.

elnygren 10y ago

1. Doesn't this make business logic quite a mess because normal and standard abstractions are missing? Won't new coders make horrible solutions to "reinvent the wheel" problems? 2. It would be trivial to implement a key-val data structure that is persisted to disk in almost any nice modern language. And there are very good No-SQL key-val stores to choose from that are backed by very large and credible industries. The Node.js drivers. Are you sure those are not mainly due to legacy integrations rather than "we really just wanted to use the MUMPS db" ? http://thedailywtf.com/articles/A_Case_of_the_MUMPS http://thedailywtf.com/articles/A_Case_of_the_MUMPS

rnprince 10y ago

Sorry, I can't hop on board. My opinion is that implementing anything complex and new in ANSI MUMPS would be irresponsible given the better options available. > It has limited commands and is whitespace-aware Limited commands to a certain extent just means a more dangerous language. Being able to give functions private scope is something that's really important to me personally, as is having named constants, and objects with methods. About whitespace awareness, I consider it a fascinating design choice that the difference between one or two spaces between tokens within the same line of code can mean different things. > Newer developers can jump right into M, precisely because it lacks higher-level abstractions like first-class functions or closures. The language does not support first-class functions, but it does support the "xecute" command for running arbitrary code strings, which is particularly risky if you ever use user inputs as parameters in the strings you try to xecute. Also, I primarily want knowledgeable developers working on my healthcare and financial systems, not the newer ones who would somehow be incapable of using a first-class function. > wicked fast at reads and writes. Great for a fast key-value store. This isn't a differentiating feature. > you're very unlikely to find a bug because it's been in production so long. This makes it good for mission-critical applications like healthcare and finance. What happens when you need to change the code? Do you wait a long time until bugs are no longer found?

__float 10y ago
You can have variable scoping, just use `new`? I think that fast reads/writes actually are a reasonably differentiating feature--if you want something like that in JS, Python, .... you're going to have to drop down to a C extension, and you'll have to put a lot of effort into that being portable. In a MUMPS interpreter, it's already there and it already works reliably.
- rnprince 10y ago
  The scoping issue I mentioned was function scoping, not variable scoping. The language would be better for organizing code if it supported functions as methods of particular classes of objects, or functions with private scope. As a codebase gets large, how well organized the code is makes a big difference in how easy and how risky it is to change things, so it really pays for your language to make code organization as natural as possible. I am actually not able to find statistics matching up M databases with non-M databases at the moment, but I'd be interested in seeing something like that. I don't know what you mean about having to roll your own C extension to talk to your database.

int_19h 10y ago

A lot of what you're describing - in particular, "you access the built-in, persistent database the same way you access regular data structures" - was also true of many DBMS of the dBase era - dBase itself and its clones (Clipper, FoxBase/FoxPro), Paradox etc. But I think they still made better languages than MUMPS. The biggest difference, it seems, is that instead of key-value stores, you had indexed tables. However, indexes were effectively key maps - there was no SELECT as in SQL (well, there was eventually, but not at first); instead you explicitly specified the index to use - unless you used the default index for that table - and performed a lookup, and it would position the current cursor for that table to the appropriate record. You would then access fields of that record as regular variables: https://msdn.microsoft.com/ru-ru/library/bz5ys9dy(v=vs.80).aspx https://msdn.microsoft.com/ru-ru/library/bz5ys9dy(v=vs.80).a... It might sound weird, but it actually worked really well for stereotypical CRUD form-based desktop apps - your cursor corresponds to the record currently being edited/displayed.