Timeline for The "blub paradox" and c++
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 11, 2011 at 13:38 | comment | added | Mike DeSimone | Operator precedence is something people (i.e. new developers) learn in math class, so discarding it to make the MUMPS interpreter easier to write seems like a way to create bugs where none were before. And, yes, full names will look weird to developers who have been using abbreviated forms exclusively. That's not because long names are good or bad, but because the experienced developers have expectations as to what they see. The net result is that it only frustrates new developers. It's not natural, it's arbitrary habit. Perl has this same issue with variables like $_. | |
| May 11, 2011 at 6:37 | comment | added | ern0 | There's only one math difference from the usual: MUMPS evaluates expressions left-to-right order, e.g. 3+4x4 results 7x4=28. That looks lame, but we have unlimited free brackets, we should use them. The one-letter abbrevation is not mandatory. You can use full function names, altough, some of them begins with letter "Z", e.g. ZSAVE or ZLOAD, ohh. Once I've written a short prg with full names, and surprisingly, everyone said, that it is confusing, it's harder to read than one-letter style. The readibility does not depends on word lenght, rather depends on "naturality" of expression. | |
| May 11, 2011 at 5:18 | comment | added | shuttle87 | @Mike: very entertaining links you posted, I had a good laugh while reading them. | |
| May 11, 2011 at 1:36 | comment | added | Mike DeSimone | "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." -- Donald Knuth. What you describe sounds to me like a legacy language whose emphasis is backward compatibility, and that's okay. Personally, in those applications, I consider maintainability more important than optimization, and a language with non-algebraic expressions and one-letter commands sounds counterproductive. I serve the customer, not the language. | |
| May 10, 2011 at 12:57 | comment | added | ern0 | MUMPS is originally a Basic-like language with associative arrays (may directly stored on the disk!). Later versions contain procedural extensions, which makes it very similar to core PHP. One afraid of Basic and PHP should find Mumps frightening, but others don't. Programmers don't. And remember, it's a very old system, all strange things, like one-letter instructions (altough, you may use full names), L-R evaluation order etc. - as well as non-strange solutions - have only one goal: optimization. | |
| May 10, 2011 at 10:23 | comment | added | Mike DeSimone | In Python, you can use either the built-in dict type (e.g. x = {0: 5, 1: "foo", None: 500e3}, note that there is no requirement for keys or values to be the same type). Trying to do something like a[x][y][z] = 8 is hard because the language has to look into the future to see if you're going to set a value or create another level; the expression a[x][y] by itself doesn't tell you. | |
| May 10, 2011 at 10:17 | comment | added | Mike DeSimone | Full disclosure: MUMPS is not for everyone. Quote: To give a little more “real world” example of the horror that is MUMPS, start by taking one part International Obfuscated C Code Contest, a dash of Perl, two heaping measures of FORTRAN and SNOBOL, and the independent and uncoordinated contributions of dozens of medical researchers, and there you go. | |
| May 10, 2011 at 7:59 | history | answered | ern0 | CC BY-SA 3.0 |