Oops, I guess you are saying "line oriented" about the code flow, not the data types...
Well, anyway that it no longer true since 2000 (Cache' version 4).
You may think MUMPS is worst, but VistA has been written and it still works nationwide. The team of VistA creators was amazingly small. And you maybe do not know how big and complicated the VistA system is...
You should not judge the language if you don't know even the basics. Your statements are not correct:
a) That is not true. Classic MUMPS is a data tree-oriented language. Trees may be "global" (persistent) or "local". Data elements may be string or numeric. There is no strict typization - data types are converted on-the-fly. (Notice, that is not true about Cache'). Cache' is an object-oriented platform.
b) Operators priority is not a universal law. You should use parenthesis if you cannot memorize the rules, or to make the code more clear).
c) That is not true. There _are_ local variables. Actually there are 4 types of "local" variables as of today:
- "local" variables - visible only to one process
automatically destroyed when the process quit.
- "new" variables - visible only within one block of code (and all blocks it executes). "New" variables are automatically destroyed when exiting from the block of code.
- Formal parameters are also "local" unless they passed by reference.
- "PRIVATE" variables (new in Cache 4). Same as new but only visible within the block of code. Not visible from above or below stack levels.
Maybe I missed something but this is enough.
If you really knew MUMPS, you would never say it is "worst". Especially regarding Cache' which is probably the best and most elegant DBMS/ Application Platform ever made.
This is not a bad language. Just someone's very bad code. Either a bad programmer, or this code was intentionally written unreadable.
Some people are talking about languages they don't know and don't understand.
Assume there is a slight difference between the BASIC from 1960-s and VB.Net. There is also a difference between the MUMPS from the 1970-s and today. The latest platform from InterSystems is likely the most advanced and elegant DBMS ever created. And it is still MUMPS.
There are three "big problems" about MUMPS that make it difficult to transfer applications to other languages.
1. The development speed in MUMPS is several times faster. So where it was enough just one mumps developer, you would have to hire 4-5 developers on a common language.
2. The MUMPS application are extremely fast. I know many unsuccessful transitions from MUMPS to relational DBMS. After the transition the reporting speed is normally slower by 30 (!!!) times. Compare - 10 seconds and 5 minutes. But notice that MUMPS _is_ relational: it supports SQL since mid-1990s or so. And it is still fast.
3. Many people just do not understand the idea of MUMPS. They think it the a problem of the language, not their own.
So it you really want to quit MUMPS, prepare to spend $$$$$ to upgrade your hardware and hire 5 times more developers. But your customers maybe will not be happy anyway.
Slashdot Mirror
Oops, I guess you are saying "line oriented" about the code flow, not the data types... Well, anyway that it no longer true since 2000 (Cache' version 4).
You may think MUMPS is worst, but VistA has been written and it still works nationwide. The team of VistA creators was amazingly small. And you maybe do not know how big and complicated the VistA system is... You should not judge the language if you don't know even the basics. Your statements are not correct: a) That is not true. Classic MUMPS is a data tree-oriented language. Trees may be "global" (persistent) or "local". Data elements may be string or numeric. There is no strict typization - data types are converted on-the-fly. (Notice, that is not true about Cache'). Cache' is an object-oriented platform. b) Operators priority is not a universal law. You should use parenthesis if you cannot memorize the rules, or to make the code more clear). c) That is not true. There _are_ local variables. Actually there are 4 types of "local" variables as of today: - "local" variables - visible only to one process automatically destroyed when the process quit. - "new" variables - visible only within one block of code (and all blocks it executes). "New" variables are automatically destroyed when exiting from the block of code. - Formal parameters are also "local" unless they passed by reference. - "PRIVATE" variables (new in Cache 4). Same as new but only visible within the block of code. Not visible from above or below stack levels. Maybe I missed something but this is enough. If you really knew MUMPS, you would never say it is "worst". Especially regarding Cache' which is probably the best and most elegant DBMS/ Application Platform ever made.
This is not a bad language. Just someone's very bad code. Either a bad programmer, or this code was intentionally written unreadable. Some people are talking about languages they don't know and don't understand. Assume there is a slight difference between the BASIC from 1960-s and VB.Net. There is also a difference between the MUMPS from the 1970-s and today. The latest platform from InterSystems is likely the most advanced and elegant DBMS ever created. And it is still MUMPS. There are three "big problems" about MUMPS that make it difficult to transfer applications to other languages. 1. The development speed in MUMPS is several times faster. So where it was enough just one mumps developer, you would have to hire 4-5 developers on a common language. 2. The MUMPS application are extremely fast. I know many unsuccessful transitions from MUMPS to relational DBMS. After the transition the reporting speed is normally slower by 30 (!!!) times. Compare - 10 seconds and 5 minutes. But notice that MUMPS _is_ relational: it supports SQL since mid-1990s or so. And it is still fast. 3. Many people just do not understand the idea of MUMPS. They think it the a problem of the language, not their own. So it you really want to quit MUMPS, prepare to spend $$$$$ to upgrade your hardware and hire 5 times more developers. But your customers maybe will not be happy anyway.