3 ms·

Built-in hierarchical DB? Neat! DB access using same syntax as local variables? Neat! Datetime epoch in 1841? Ok, sure. Stringly typed with literally no othe

Built-in hierarchical DB? Neat! DB access using same syntax as local variables? Neat! Datetime epoch in 1841? Ok, sure. Stringly typed with literally no other types? Uh… Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night It had some neat ideas, some alright ideas that were reasonable in the context it was created for, and some absolute nightmare fuel.

geocar 4mo ago
> Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night I don't know mumps very well, but this seems pretty straightforward if you put the primer next to it, and I am troubled by your (common!) reaction to alien technology... > Stringly typed with literally no other types? Uh… like this example here; SQLite made this choice too. Everyone knows about SQLite by now, right? All types are strings when the user types them in, whether you are talking source code text, or the patient's weight in kilograms. Pretending you can have other types is something the source code of your application (or the language your application is written in) does. This is something that makes total sense when you are thinking about things the right way (whatever that means), so when something makes you go "uh" try inverting this equation, and ask yourself, in what way (or under what circumstances) would this decision make sense? That sort of thinking will get you the right ideas to understand everything else in the software world, and make you less avoidant about filling in the gaps in your own abilities. > It had some neat ideas Has. Multiuser support is still almost nonexistent in mainstream programming (and just recently starting to actually show up in SQL implementations!). And besides SQL, the most popular language with global variables you've might have heard of is perl. Understanding these ideas is still in the future. Putting the ideas in the past, and framing them with such harsh judgement -- especially the ideas like this that you don't fully understand yet -- keeps them out of your mind, and denies you access to what these ideas can do for you. As an example: A lot of people make a "users" table in SQL for the users of their application. Of course most SQL implementations have "users" of their own, and have a robust implementation that is already there, and yet almost nobody uses it and chooses to make their own rather than learn how to use the one SQL gives them. Now: SQL exfiltrations are only possible because of this, and when you fully understand why that is you'll probably never make another users table again. > and some absolute nightmare fuel. but nightmares? Seriously? There was nothing in that example code that I am going to have nightmares about. It seems very well thought out (unlike say, Python's). It's even Y2K compliant. There is even a few ideas in there I'm going to steal for my own parser. There is good stuff here; don't give up.
Rochus 4mo ago
Already discussed here: https://news.ycombinator.com/item?id=48707444 https://news.ycombinator.com/item?id=48707444
- kstrauser 4mo ago
  I don’t think that’s the same discussion.
rybosome 4mo ago
Quite agree. Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it. But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a number when the programmer didn’t intend it, or vice-versa, is a reasonably common class of bugs in MUMPS programs. The tutorial seems really good, but I’m frustrated with parts like that (or the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing. In this sense it reads like the autobiography of a presidential candidate; written in a calculated way to minimize flaws.
- Rochus 4mo ago
  My intention was to present the MUMPS 76 standard so it can be appreciated by today's software engineers; it should be obvious that this is a historical treatise, not a guide for today's systems; as mentioned elsewhere, MUMPS 76 was designed to work on PDP machines with 8K to 24K of core memory. Your coercion concerns apply to any dynamically/weakly typed language, and the same coercion-class bugs are rampant in JavaScript, Perl, PHP, and shell scripting, all of which survived and thrived. MUMPS made deliberate simplicity trade-offs to be usable in 4K of memory in the 1960s. Many early languages made the same choice. And I appreciate that you regard me as presidential candidate.
  - rybosome 4mo ago
    Thanks for the reply! I agree with your points about weak typing and coercion being prevalent. Having had direct negative experience with it across 3 of the 4 languages you named, I was prepared to marshal an argument about it most definitely being a source of bugs. > it should be obvious that this is a historical treatise It wasn’t obvious to me. Might I suggest amending it to make that more clear? I do appreciate the tutorial and your commentary though, it gave me a new perspective on MUMPS.
- benj111 4mo ago
  > the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing. Is it a bad thing? Or is it different? I literally spray brackets about because Im not sure of the precedence. Explicit over implicit is generally regarded as a good thing. Why is there a blind spot when this comes to operator precedence?
agumonkey 4mo ago
Strange it feels worse than both raw asm and apl.
- iberator 4mo ago
  which assembler? modern assemblers with macros are quite easy
  - agumonkey 4mo ago
    I was hyperbolic somehow. It's just that people usually hate on asm.

geocar 4mo ago

> Appendix 7 on this page http://www.faqs.org/faqs/m-technology-faq/part2/ http://www.faqs.org/faqs/m-technology-faq/part2/ : runs screaming into the night I don't know mumps very well, but this seems pretty straightforward if you put the primer next to it, and I am troubled by your (common!) reaction to alien technology... > Stringly typed with literally no other types? Uh… like this example here; SQLite made this choice too. Everyone knows about SQLite by now, right? All types are strings when the user types them in, whether you are talking source code text, or the patient's weight in kilograms. Pretending you can have other types is something the source code of your application (or the language your application is written in) does. This is something that makes total sense when you are thinking about things the right way (whatever that means), so when something makes you go "uh" try inverting this equation, and ask yourself, in what way (or under what circumstances) would this decision make sense? That sort of thinking will get you the right ideas to understand everything else in the software world, and make you less avoidant about filling in the gaps in your own abilities. > It had some neat ideas Has. Multiuser support is still almost nonexistent in mainstream programming (and just recently starting to actually show up in SQL implementations!). And besides SQL, the most popular language with global variables you've might have heard of is perl. Understanding these ideas is still in the future. Putting the ideas in the past, and framing them with such harsh judgement -- especially the ideas like this that you don't fully understand yet -- keeps them out of your mind, and denies you access to what these ideas can do for you. As an example: A lot of people make a "users" table in SQL for the users of their application. Of course most SQL implementations have "users" of their own, and have a robust implementation that is already there, and yet almost nobody uses it and chooses to make their own rather than learn how to use the one SQL gives them. Now: SQL exfiltrations are only possible because of this, and when you fully understand why that is you'll probably never make another users table again. > and some absolute nightmare fuel. but nightmares? Seriously? There was nothing in that example code that I am going to have nightmares about. It seems very well thought out (unlike say, Python's). It's even Y2K compliant. There is even a few ideas in there I'm going to steal for my own parser. There is good stuff here; don't give up.

Rochus 4mo ago

Already discussed here: https://news.ycombinator.com/item?id=48707444 https://news.ycombinator.com/item?id=48707444

kstrauser 4mo ago
I don’t think that’s the same discussion.

rybosome 4mo ago

Quite agree. Some very novel ideas for the time. I’m not a PL historian but can’t think of an earlier language with such a complex runtime to support it. But, woof - no thanks to the stringly typing. The article under discussion treats this as a positive, saying it eliminates conversion and having to worry about it. I don’t believe that’s possible, and would bet my life savings that MUMPS interpreting a string as a number when the programmer didn’t intend it, or vice-versa, is a reasonably common class of bugs in MUMPS programs. The tutorial seems really good, but I’m frustrated with parts like that (or the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing. In this sense it reads like the autobiography of a presidential candidate; written in a calculated way to minimize flaws.

Rochus 4mo ago
My intention was to present the MUMPS 76 standard so it can be appreciated by today's software engineers; it should be obvious that this is a historical treatise, not a guide for today's systems; as mentioned elsewhere, MUMPS 76 was designed to work on PDP machines with 8K to 24K of core memory. Your coercion concerns apply to any dynamically/weakly typed language, and the same coercion-class bugs are rampant in JavaScript, Perl, PHP, and shell scripting, all of which survived and thrived. MUMPS made deliberate simplicity trade-offs to be usable in 4K of memory in the 1960s. Many early languages made the same choice. And I appreciate that you regard me as presidential candidate.
- rybosome 4mo ago
  Thanks for the reply! I agree with your points about weak typing and coercion being prevalent. Having had direct negative experience with it across 3 of the 4 languages you named, I was prepared to marshal an argument about it most definitely being a source of bugs. > it should be obvious that this is a historical treatise It wasn’t obvious to me. Might I suggest amending it to make that more clear? I do appreciate the tutorial and your commentary though, it gave me a new perspective on MUMPS.
benj111 4mo ago
> the explanation on a lack of operator precedence) which try to frame a bad thing as a good thing. Is it a bad thing? Or is it different? I literally spray brackets about because Im not sure of the precedence. Explicit over implicit is generally regarded as a good thing. Why is there a blind spot when this comes to operator precedence?

agumonkey 4mo ago

Strange it feels worse than both raw asm and apl.

iberator 4mo ago
which assembler? modern assemblers with macros are quite easy
- agumonkey 4mo ago
  I was hyperbolic somehow. It's just that people usually hate on asm.