- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Not if you are using "use strict" like you should be. Ruby and PHP have similar behavior, though. "autovivification" is what perl calls it.
PHP arrays can contain both hash keys and integral indices at any given time. If you use a Boost variant as the key into a C++ STL map you might be able to do something weird as well.
Boost variants in C++, etc.
Admin
Admin
Unless that hunk of crap executes 20 times faster than C, it needs to be eradicated from the planet. I mean suspend the consitution, and take "We're fighting for survival of the human race, damnit!" EXTR3ME measures.
Admin
I always felt sorry for the AS/400 (sorry I meant iseries, no wait I meant system i....) folks that only knew RPG. How useful is RPG in an era of Unix/Linux/Windows?
This MUMPS monstrosity puts RPG in perspective for sure.
Admin
You must be joking. You've never heard of INTERCAL? or Brainf*ck?
Admin
You got that right. It's like Dr. Frankenstein put a brainfuck brain into a Perl body... It's aliiiiiiive!!!!
Admin
Ok... this WTF... it hurts. Physically.... oh god, the pain!
As to the guy who said "use strict" for Perl... yes. If you are writing in Perl and not using "use strict" then stop right now and never code again.
I've never heard of MUMPS until today but it sounds kinda like this proprietary language we have at my work. I won't name it, obviously, but there is one guy here who swears it's better than any other language out there for text parsing. Yeah right, give me Perl any day.
I never really had to write scripts in it but I did have to try and understand some of the older scripts. It was pretty painful though MUMPS sounds infinitely more painful.
Admin
I'm dismayed at the number of people working in the field who think that this is somehow acceptable. Even to the point of arguing that popularity is a direct measure of quality, or that allowing almost the entire recruitment process to be left in the hands of people incompetent in, or completely ignorant of, the field. Has anyone ever come across a recruitment consultant who does know what they're talking about? or who can analyse a CV at a slightly deeper level than fgrep?
Sometimes I think the whole damn software industry behaves like an abused wife who insists that her husband has every right to beat her senseless, because she's headstrong and keeps stepping out of line.
Admin
It seems to me that MUMPS isn't remarkably different from any other language that was state-of-the-art 40 years ago; the microcomputer BASIC I myself was weaned on had several traits in common with it.
The strict left-to-right evaluation of expressions is surely a WTF though. It's algebraically incorrect to perform an addition before a multiplication.
Admin
I thought IDX (LastWord) was cobol based, but I could be wrong.
Lots of alternatives! Meditech, Cerner, McKesson, Epic....
Admin
Admin
... Yeah, I still vote APL as much much MUCH worse. :(
I mean .. come ON! More than half the symbols they use in the code aren't even letters!! WTF!
Admin
Admin
Well, I'm almost 55 and don't mind working on stuff like this at all. Technologies like MUMPS aren't mainstream, so the jobs are unlikely to be offshored. Here where I am in Western PA there are MUMPS jobs going begging.
Work is work, so suck it up and take the paycheck. Go spend it on some books and nice computer gear for home where you can play with Linux or Python or Ruby or whatever your heart desires. Then start a small consulting business and sell your skills with the new stuff there. That'll give you some independence and also some money to spend on those nice girls you meet on MySpace.
Author Chad Fowler calls this type of niche work "technology hospice". It's not glamorous, but as with maintenance, there's always a need for folks to work on older systems that many people (especially those right out of school) won't touch. It can pay nicely and can be quite stable, too -- there are usually enough older systems and applications around that you can jump from one to another as they get phased out. And some take YEARS to die.
Admin
I work for a large regional health care company that uses MUMPS, Cache and other ancient languages and databases. I interviewed for a .Net position, but had to interview with the division that used the stone age software. All prospective developers had to interview with that division. They didn't talk about the languages they used, deferring that to the next round of interviews. Of course, there was no next round because I walked out of the first one feeling as if I had just talked to three people who'd had all the joy of life beaten out of them.
Admin
Admin
My first interview out of college was for a MUMPS shop. The issue that made me decide against was that each routine (or maybe it was file) was limits to something like 2k characters, including comments, variable names and whitespace.
The practice at tis shop was to abbreviate evreything: "i" for if, "d" for do and variables named "x", "y" and "z". Sometimes "x1", "x2", ... if you had many.
I ran a mile and never looked back!
Admin
We need an old priest and a young priest.
Wait. I...I understand what they're trying to do there. Not the text, but what the point was.
MUMPS predates C, Unix, and just about everything else. This thing is ancient by anybody's standards.
The original specs were for a PDP-7. The goddamned thing was put together with wire wrap! They couldn't have comments, because that would eat space. Condensing everything to one character saves space. They didn't have TBs of HDD space to run their programs.
It was from a time when this was good code.
Brr.
It's not sane, but it makes sense. Or it did, 40 years ago. Now it's got senior managers and hospital bureaucrats who "have a computer system that works, has worked, and will continue to work." Think about how long it takes to get a surgical technique to change. Now apply that thinking to something that they don't understand.
It makes you think - what will the programmers and engineers in 2047 think of our antiquated workmanship? "You have to remember that they had only 2 dimensional displays, and the neural interface was still 20 years away."
Admin
Some of those language features sound like REXX, one of my favorite work experiences and one of the most readable languages. It's inspired by PL1, ANSI standard, still on all IBM OSs and most others, small but loyal user base.
I've seen people build REXX program by concatenating conditional subroutine files into one file but that's rare and scary. On the other hand, programs that write programs and return code are tremendous fun. :)
The M samples do look like hell on earth, tho.
BTW: BASIC was invented by a mathematician (first math dept president of an Ivy League college) and x=x+1 was originally "Let x=x+1" which I can picture any math prof saying. The "let" keyword was later made optional.
Admin
"It actually made vi look user-friendly."
That wouldn't be hard, VI is user friendly. Some are thrown off by the whole two-mode thing, but the commands make sense once you learn them. Do the tutorial and in a matter of hours you will be faster than notepad or pico etc.
Now if it made Emacs look user friendly... (*ducks while running away).
captcha: kungfu - ah yes, if you don't know VI, then your kungfu/kungfoo is weak.
Admin
Please call an ambulance.
Admin
If Brian's still wondering where to steer his career, I recommand he consider going out for embedded systems work.
MUMPS was designed to be written and run on systems we today would consider tiny (hence the wacky syntax -- it's way easier to parse). Living in MUMPS for two years tells me you can A) work in a very constrained execution environment that is B) highly idiosyncratic -- the very definition of an embedded environment.
Go visit Freescale's or Cypress' Web sites and have a look at their systems-on-chip and development tools. And no fair using the C compiler; read up on the assembly code.
Admin
Me too, and not just because I value job security over the chance to be a Star(tm). (After all, these pages are filled with the contributions of stars...)
No, the reason I like doing maintenance programming is that it's actually fun (for me) working out what the hell is going on in a language, or a chunk of code, I've never seen before. Especially when you have a specific problem to solve; debugging other people's code (or even your own, once you've forgotten writing it) is like a cross between solving a crossword puzzle and weaving an enchantment. I'm looking at the MUMPS examples here and thinking "you know, this actually sounds like fun"...
(Trouble is, I'm in Yorkshire, and I don't think anyone uses MUMPS around here...)
Admin
After working with several GUI languages and SQL databases I have found myself in a Mumps position. At first I was a little reluctant as the language is a bit cryptic. However, having cut my programming teeth on microcode and assembly language I figured WTF give it a try (besides, I'm over 50 and needed a job).
When the work began it wa slow going trying to get used to the concept of sparse arrays. This turns out to be a very efficient database structure and the strength of a well designed M system shines through when creating report extracts.
Yes, SQL is more user friendly. Yes, a custom interface is neede to access Mumps from a GUI. But the Mumps code is simple to write and executes very fast, Many of the restrictions no longer exist. Many of the people who have criticized Mumps here either have no experience with the product or have had a bad experience (often do to their own design). Just because a language is old, this does not make it bad. I would not attemot to write a game in Mumps, but in certain nitch applications it cannot be beat.
Admin
I actually agree with everything you said, but I read this:
I don't think the 2d display is going anywhere. How much depth does the letter 'A' normally have...? Even if we do live in 3d holographic virtual utopia, we'll still be reading our information from the virtual pages of digitised books in rendered libraries. ;)
Admin
Look at the Wikipedia page.
I've only used REXX a little bit (on IBM's CMS), but the PARSE keyword is damn sweet. Only other thing that I've seen with similar uses are regexs with backreferences, but PARSE doesn't require you to learn a new language to use.
Admin
Of course, editors such as vim and elvis have complicated things to the point where you do now have two modes... but originally (and certainly on SunOS 12 years ago) vi wasn't like that.
As for being user-friendly - very... but only to users of vi (or to those who've never seen a text editor before). It's pretty damn hostile to users of emacs or Wordstar, even though the interaction model is to all intents and purposes the same. The only difference is that printable characters are mapped not to a range of different commands, but to just one - "insert this character into the buffer".
Admin
Checkout what Cache has done with M. They call it "Post Relational" databases.
And while you may be dissing this stuff, your EHR Backend WILL be written in this shit.
Admin
if(Progress == BARF) { No Query optimization } else { You haven't used it }
Admin
Mumps is 1960s technology. If a system is still around that's written in mumps, it is probably at least 20 years old and possibly 30. Or the owner of the system is too poor to buy anything new (like some hospitals).
It was designed for PDPs holding masses of text data with hundreds or thousands of users on dumb VT terminals. The restrictions on memory were crippling (there's probably more computing power on your mobile phone). Hence the 8 character name limit (and the one-letter commands).
So yeah, it was cryptic, but that's all they had until the 1990s and OO started to take off.
Admin
Admin
Yes, but the bad habits learnt in those years can be deadly and worse than nothing. It's not just the language; the general quality and culture of a place can strongly affect how a programmer thinks. For instance, suppose you want to develop a new system from scratch. The fresh-faced neophyte out of (a good) college may miss some "obvious" things and require some guidance, but they're probably used to building things on their own, thinking ahead, and designing before coding. On the other hand, somebody who spent 3 years maintaining Windows code from 1996 may well have already resigned themselves to arbitrariness and cleaning up other messes by generally trying random things until the bug seems to go away.
As for languages... again, it's like human languages. If you know 24 different words for snow, then you naturally pay more attention to snow because you have more ways to classify and decipher it. If you come from a langauge that uses GOTOs, you'll find yourself thinking in GOTOs; if you come from an object-oriented language, you'll think in objects. Obviously, this can be overcome, but it is relevant.
Paul Graham has a rather harsher opinion on this than I do. Check out http://www.paulgraham.com/avg.html ; as far as he's concerned, if you're using a "weak" language, you are closing your brain off to the possibilities of what you could do in a stronger language.
Admin
I'd tell the guy to put those two years back on his resume. Either:
Admin
A tutorial and "hours" to learn how to use a TEXT EDITOR? That's the antithesis of "user-friendly" to me.
Let me guess, you see no reason why peoples' grandmas shouldn't be forced to use a command prompt, right?
Admin
As far as production-use obfuscated languages go, nothing really compares to BANCSTAR. MUMPS looks like a walk in the park by comparison.
Admin
MUMPS sounds like Perl!
Admin
Use a real programming language!
Admin
It's the Web 2.0 version.
Admin
I'd tell the guy he should have kept his MUMPS programming job and searched for another job while still staying employed.
Admin
I'm too tired to actually think of something useful to do with it but don't diss the "post-relational" bit. While the underlying technology (M I guess) might be old, the idea is pretty newish and definitely not 60s technology.
Admin
Admin
And of course they have a support organisation for anyone who suffers from MUMPS - the MUPS User Group. Go on, spell out the acronym ;-)
Admin
I also worked there. Call it Ep*c Syst**s.
So, yeah. All storage are in a giant automatically sparse global arrayo. So what you do is you have ^data[ attribute one, , , attribute four] = x
where you aren't specifying attributes 2-3. The whole scheme works like this, so it's very hard to convert to SQL. That would be, for example, a way of storing data about someone if attribute one were SSN, etc.
Better yet, the attributes themselves can be the data -- ie attribute 1 is SSN, attribute 2 is sex, etc. So you can actually store / query data from the attributes.
NB: my syntax may be off, it's thankfully been years.
Funny story: someone accidentally took down a major hospital by mistyping. Everything is done on production servers; this person was typing k ^varname to delete (k is short for kill = delete) over a remote connection. Instead of completing the varname and the attributes to delete, this person accidentally hit enter or the connection gremlin decided to screw him.
What was sent over the terminal was: k ^enter
which deletes all data. Everywhere. In the middle of a day in a hospital. There was a screamed "OH SHIT" then he ran down the hall to the recovery team.
Haha.
Admin
Sounds kind of like Zope (the framework on which Plone is built). Zope uses a transparent object database. Zope has accrued its own share of WTFs since 1998, but there are still some really cool things about it.
Admin
When/which team did you work for? I was in EDI over in the mall.
Admin
You're joking right? I mean, why on earth doesn't the compiler optimize anything well but the stuff in a global array? These days, it's the compiler's job to figure out which pieces of code get called most often, and to try harder to optimize those pieces of code. Surely the MUMPS compilers could be upgraded to handle this better?
Same with the arcane syntax. Surely some de-obfuscators could be written that change back 1-letter commands to full-length commands? Surely restrictions that code has to be on a single line can be lifted, maybe adding braces?
Perhaps (optional) declaration of types could be added, with type-checking on the variables that do have a declared type? Perhaps some sort of built-in module namespace-functionality, arrays that aren't global to every piece of code, but with local scopes? How about lifting length restrictions on variablenames, significance of whitespace, make case sensitivity saner etc. etc.
That's all pretty easy to do using, say, some sort of "pre-compiler". Convert your code to the new language specs, and voila, it's indented, syntactically sugarified, easier to maintain, and, most important of all, harder to break. Write according to the new and improved conventions, and let a precompiler spew out old-style unreadable MUMPS.
It's not like this hasn't been done in other languages. C++ was precompiled into C back in the day. An erstwhile toy language like PHP (any one remember PHP2?) has been extended so much that it's getting almost enterprisy. Perl has use strict and objects. Java added stuff like templates, and just-in-time compilation using hotspots. Languages change for the better all the time.
And then there's IDEs that color-highlight code, do lookups on variable names and functions, pretty-print, validate..
But such changes, that in other languages are universally regarded as improvements, would, when applied to MUMPS, suddenly somehow sully the greatness of MUMPs?
If that's the case, why not switch from MUMPS right back to, say, PL/1 on punch-cards? Or just soldering radiotubes together?
I mean, come on, I read one comment here saying that using comments has negative performance impact on MUMPS..
Admin
I can totally relate.
I used to program Delphi.
Admin
In my (admittedly limited, because I have to deal with a third-party package) experience, for well-designed structures, it can be extremely fast, but at the cost of massive disk consumption and no normalization... And if you decide to use its SQL-ness, and want to do something wacky like one o' them new-fangled join thingies, performance tends to go down the toilet.
Admin
I actually think more of Tcl than Perl when reading descriptions of MUMPS (especially Tcl with the metakit DB package).
All Tcl commands run on one line, but there's a string quoting syntax which looks a lot like C, but isn't. Consider:
which is an infinite loop, because it's equvalent to
and since 5 is always greater than zero, it runs forever. You can also see why comments would be frowned upon in performance-critical environments.
Tcl has no reserved words. All commands are procedures written in either C or Tcl, bound to string names. The interpreter starts with a bunch of predefined procedures implemented in C code. Procedure and variable names can be any string, including the empty string. Procedures can even be renamed. So one could do something like
You can also create a nested hierarchy of Tcl interpreters within Tcl, each one running a slightly modified version of the language implemented using procedures available to the outer interpreter. You can create alias procedures (so you can have both "w" and "while" bound to the same procedure) and you can also redirect a procedure from one interpreter to another (which allows you to do restricted sandbox type secure code, or write Tcl scripts that transform other Tcl scripts by executing them with a specialized custom Tcl interpreter).
Want to execute a command that doesn't exist? No problem, Tcl will run a procedure named "unknown" and give that procedure your command name and arguments as parameters. The "unknown" procedure can dynamically load code, generate code on the fly, execute the command as a function call in a different language or as an external command. You could for example send unknown Tcl commands and their arguments as query strings to some SQL database (although since many SQL command words are already defined as procedures in Tcl the results would be a whole new level of WTF). The interactive Tcl interpreter by default sends unknown Tcl commands to a shell for execution as shell commands.
Tcl's variable types all have a type-specific representation (UTF-8 string, 32/64-bit integer, double, list, byte-array, compiled byte code) and a common representation (UTF-8 string) which is used to convert variables of different types as required. I suspect this is similar to what MUMPS does with its "optimized global arrays" (assuming that the truth is not that MUMPS's local arrays are just incredibly slow).
Unlike M, there are only the usual 32-bit implementation limits on line or string lengths in Tcl, whitespace is mostly insignificant except for newlines, and everything is uniformly case sensitive. There is also no GOTO in Tcl, or at least it doesn't come with one (anything's possible if you start mucking with the language at runtime).
Above are some of the most horrible examples of Tcl code I've yet seen. It's startling how compact they are, and how easy they were to write...
Admin
Except that in Perl you can use declarations if you want to, and you can turn off support for undeclared and unscoped variables.
Perl still allows undeclared scoped variables ($::global or $somePackage::someName) though, with only a warning if the undeclared scoped variable name is used only once.