• (cs)

    Oh I'm sure the condoms were just for making balloon animals. And the Jack was for brushing his teeth, of course.

  • Anonymously Yours (unregistered) in reply to Zemyla
    Zemyla:
    Article:
    The application that this company made wasn't written in Java or VB. Oh, it has some Java and VB clients. Clients that didn't actually contain any real code. Clients that asked a MUMPS system, "At pixel (34,53), what should I render?"

    This is the real WTF. How the blazing FUCK is a MUMPS client rendering images?

    I think that meant MUMPS was being asked by the VB/Java clients what it wanted them to do. This is likely a dirty hack, using VB and Java only so much as to extend what could be done from MUMPS. Very WTFy, to say the least.

    CAPTCHA consequat - The consequences of not knowing squat?

  • Dittybop (unregistered) in reply to Daniel
    Daniel:
    No article better defines this site that this article.
    No comment better defines this site that this comment.
  • (cs) in reply to Anon
    Anon:
    Yes, these "features" seem downright idiotic at first, but most of them are comparable to other languages.
    Those other languages are frequently (and in most cases justifiably) trashed on this site on a regular basis, sometimes by people who have used them, and sometimes by people who have only read "feature" lists and code snippets. Why should MUMPS be treated differently, especially if it's comparable, as you so kindly pointed out?
  • Sanity (unregistered) in reply to Anon

    I have to say, from what the actual MUMPS programmers are saying, about all I'm getting is that MUMPS is Turing-complete, and you can build anything in any Turing-complete language.

    Kind of like how, while C itself lacks memory protection, if you're really, really careful about how you use pointers, you'll be fine. Add sufficient wrappers and "best practices" and those potential problems are managed.

    But, given the choice, why would you ever use a language that forces you to jump through the hoops described? I mean, yes, you technically could write a practical, secure webserver in Bash, but why would you want to? I mean, other than the sheer geek cred of writing a fully-functional Tetris in nothing but Bash, I just don't get it -- is the job market really that bad?

  • Anonymously Yours (unregistered) in reply to boog
    boog:
    Anon:
    Yes, these "features" seem downright idiotic at first, but most of them are comparable to other languages.
    Those other languages are frequently (and in most cases justifiably) trashed on this site on a regular basis, sometimes by people who have used them, and sometimes by people who have only read "feature" lists and code snippets. Why should MUMPS be treated differently, especially if it's comparable, as you so kindly pointed out?
    I'm going to have to agree with boog, if only because you mocked the holy trinity that is the ternary operator. Burn, MUMPS heretic!
  • Rodger Combs (unregistered)

    Have you ever tried to decipher ActionScript that was decompiled from a SWF? It's a lot like this, with the upside that functions still have names. Still, all variables are like "loc1", etc.

  • Bourne (unregistered) in reply to Sanity
    Sanity:
    I mean, yes, you technically could write a practical, secure webserver in Bash, but why would you want to?
    You mean there's another way to do it?
    I mean, other than the sheer geek cred of writing a fully-functional Tetris in nothing but Bash, I just don't get it
    Frozen-Bubble is a pretty nice video game with hot sound effects and all -- written in Perl.
  • Phil (unregistered) in reply to Bob
    Bob:
    wtf:
    Ben:
    I really wish there were more languages around like that, and it's too bad no one uses MUMPS any more.

    MUMPS is used quite extensively in hospital administration - I know two people working in different MUMPS shops today, and there's apparently room for more coders there. You might have to move to Massachusetts, but you can indeed work with MUMPS if that's something you'd like to do.

    Up here in MA, a very well known company created their own language based on MUMPS. They call it MAGIC. Unfortunately Im not kidding.

    Plus, MEDITECH has 5-cent soda machines* for their employees (or, at least, did the last time I visited their Canton facility several years ago). Course, now I'm at a company with free soda, so that doesn't seem as great as it once was, heh. Was a nice facility, though, except for everyone apparently having half-height cubicle walls.

    *That is, the soda cost 5 cents, not the machine.

    CAPTCHAm refoveo: refoveo to cherish again, refresh, warm

  • (cs) in reply to boog
    boog:
    Mumps Coder:
    Before you trash a language, try using it a bit first.
    Fair enough; I'll admit I've never used MUMPS before.

    So tell me then, is the article A Case of the MUMPS at all accurate in its description of MUMPS features? How about the MUMPS FAQ (particularly Part 2, Appendix 5)? Because if MUMPS is anything like it is described in either of those sources, then I will happily trash it as much as I feel necessary, despite having never used it.

    The article is not all that accurate, no (and in fairness, I'll add that I work at the company mentioned in that article, and love my job actually). To go point-by-point:

    Case sensitivity - there's one simple rule -- everything that is an intrinsic part of the language is case insensitive -- be that a keyword, function, variable, etc. Everything that is user-defined is case sensitive. There is also a slightly different syntax when calling user-defined functions as opposed to standard (user-defined are prefixed with $$ instead of $)

    Commands - Yes, you can abbreviate them to one letter. That was tough for me for the first two days; after that point I got equally good at reading either way. The only issue this ever raises is that it makes it harder to search for a particular command.

    Operators - Yes, it's left to right. At the time it was created, it was an interpreted language, and computers were much slower than now. So long as you know what you're getting it's really not that hard.

    Data types - Not really an issue. Our DBMS that is built on top handles all data typing anyway.

    Declarations - You're SUPPOSED to declare variables before use; it has scope implications to fail to do so. But yes, you aren't required to.

    Lines - This is the most misleading of the bunch, in that while it's technically true, it omits key information. The article fails to mention the "do block" command. Nobody actually writes one-line loops in MUMPS any more often than they do in C++; you can put in one command that says "execute the following block of code".

    Local arrays - It's basically PHP-style syntax.

    Global arrays - Yes, this is what underlies the DBMS we have. Compared to table-based systems (especially older ones) this method is better for storing sparse information, which is typical of our needs. It also makes it easy to create hierarchical records, and to lock subsets of records without preventing access to other non-overlapping subsets.

  • Roger Garrett (unregistered) in reply to Clementine
    Clementine:
    They should be thankful Darren wasn't hit by a bus. Now he has lots of time to dedicate himself to the project. Like Mr Reiser.

    Mr. Resier? My eighth grade science teacher from Wantage Elementary School?

  • gil (unregistered) in reply to Cat
    Cat:
    The article is not all that accurate, no
    Could you please point out the inaccuracies a bit more explicitly? In your "point-by-point", you go over a bunch of features and basically say "yes, that's accurate, although not that bad if you get used to it" for each. So I'm not sure what the inaccuracies are.
  • (cs) in reply to gil
    gil:
    Cat:
    The article is not all that accurate, no
    Could you please point out the inaccuracies a bit more explicitly? In your "point-by-point", you go over a bunch of features and basically say "yes, that's accurate, although not that bad if you get used to it" for each. So I'm not sure what the inaccuracies are.

    I'd say the big ones:

    1. If and for loops need not be written on single lines; you can use the block syntax to make them execute blocks of code like any other language.

    2. While not absolutely necessary, there ARE variable declarations, which in this language drives scope control, rather than the type control seen in strongly-typed languages (it really wouldn't make sense to do type-control in an untyped language anyway...)

    3. The array syntax (both for locals and globals) is, in my opinion, a positive feature of the language, especially in the niche for which it was designed, medical recordkeeping. Really, any application that makes heavy use out of sparse or hierarchical data sets will benefit from this feature.

    4. The case-sensitivity statement is needlessly complex, when the much simpler explanation of "everything defined by the language is case insensitive, everything user-created is case sensitive" is much easier to understand.

    Really, out of all the list, the only thing that really could be a WTF is the operator precedence, but considering the applications the language was designed for and the era, it's quite understandable.

  • mumpsedtodeath (unregistered) in reply to boog

    Ah, you young whippersnappers just don't know how much of a thrill it used to be to find that your predecessor actually followed published standards and wrote intelligible code. It was rare, but it was delightful... In the land of spaghetti-west MUMPS was far less irritating than unrequited go-sub's in BASIC. At least you knew immediately that you'd have to rewrite everything at the beginning, rather than finding out a frustrating six months later.

    In my younger days I'd have been tempted to choke the guy to death slowly with a code reference guide, but now I'm older and more caring - a simple burning on the cross without a beating would be sufficient... It figures that he'd be a paedophile as well...

  • (cs)

    So, are they gonna convert it to MUMPS.NET?

  • (cs) in reply to Sanity
    Sanity:
    I have to say, from what the actual MUMPS programmers are saying, about all I'm getting is that MUMPS is Turing-complete, and you can build anything in any Turing-complete language.

    Kind of like how, while C itself lacks memory protection, if you're really, really careful about how you use pointers, you'll be fine. Add sufficient wrappers and "best practices" and those potential problems are managed.

    But, given the choice, why would you ever use a language that forces you to jump through the hoops described? I mean, yes, you technically could write a practical, secure webserver in Bash, but why would you want to? I mean, other than the sheer geek cred of writing a fully-functional Tetris in nothing but Bash, I just don't get it -- is the job market really that bad?

    Because for the target applications, it not only works, it works well. The biggest WTF listed is its operator precedence -- but it wasn't really designed for math-heavy applications to begin with (FORTRAN already existed for those applications). It was really built for specific types of database applications, particularly for medical records, and in that, you don't really do a whole lot of math.

    What it does well:

    1. Storage and locking of sparse, hierarchical database records. The language is built around what it calls globals, which are really nonrelational databases. Database interaction isn't just an afterthought, it's the core feature of the language.

    2. Very good string manipulation utilities.

    3. Xecute allows for flexible coding; you can program hooks where your end-user can plug in a piece of code to run at that point during the program flow. This allows extreme customization of the program logic without ever touching the actual source code.

    Addendum (2010-10-27 00:20): #3: I meant the clients' administrators, not end-users.

  • kastein (unregistered) in reply to Cat
    Cat:
    Sanity:
    I have to say, from what the actual MUMPS programmers are saying, about all I'm getting is that MUMPS is Turing-complete, and you can build anything in any Turing-complete language.

    Kind of like how, while C itself lacks memory protection, if you're really, really careful about how you use pointers, you'll be fine. Add sufficient wrappers and "best practices" and those potential problems are managed.

    But, given the choice, why would you ever use a language that forces you to jump through the hoops described? I mean, yes, you technically could write a practical, secure webserver in Bash, but why would you want to? I mean, other than the sheer geek cred of writing a fully-functional Tetris in nothing but Bash, I just don't get it -- is the job market really that bad?

    Because for the target applications, it not only works, it works well. The biggest WTF listed is its operator precedence -- but it wasn't really designed for math-heavy applications to begin with (FORTRAN already existed for those applications). It was really built for specific types of database applications, particularly for medical records, and in that, you don't really do a whole lot of math.

    What it does well:

    1. Storage and locking of sparse, hierarchical database records. The language is built around what it calls globals, which are really nonrelational databases. Database interaction isn't just an afterthought, it's the core feature of the language.

    2. Very good string manipulation utilities.

    3. Xecute allows for flexible coding; you can program hooks where your end-user can plug in a piece of code to run at that point during the program flow. This allows extreme customization of the program logic without ever touching the actual source code.

    you're kidding/trolling on #3 right? Have you ever worked for the Microsoft Internet Explorer team or something? They like inserting those kinds of features too, except replace end-user with "any random hacker on the internet whose web page you view." Passing user input into something like xecute or perl/python eval() with no sanitizing and calling it a feature is pretty hilarious, so I guess I'll hand it to you.

    Oh... as for obscure languages of the 60s and 70s you can make a pretty penny maintaining, go look into JOVIAL. Means Jove's Own Version of the International Algorithmic Language (i.e. some dude's almost-ALGOL...) and the military used it quite extensively for everything from embedded systems in missiles to aircraft flight control systems. It's archaic enough that very few people know it, the authoritative document on the language is MIL-STD-1589C.

  • (cs) in reply to kastein
    kastein:
    you're kidding/trolling on #3 right? Have you ever worked for the Microsoft Internet Explorer team or something? They like inserting those kinds of features too, except replace end-user with "any random hacker on the internet whose web page you view." Passing user input into something like xecute or perl/python eval() with no sanitizing and calling it a feature is pretty hilarious, so I guess I'll hand it to you.

    Sorry, just tired and not being accurate with language. I meant configurability by the clients' administration teams, not the end-users who are accessing the database. Nothing that actually comes from end-user input should ever be passed to xecute.

  • (cs)

    From the MUMPS description here it sounds like it should be relatively easy to do a LLVM mumps-to-mumps compiler that generates much more readable code.

    Can't do much about most of the variable names, but shorthands would be easy to expand, and at least some of the routines could probably gain from some SSA-based optimizations..

  • /dev/null (unregistered)

    I was betting they took on Tyson...oh well

  • Rob (unregistered)

    Yep, all the Mumps side of this story proves is that you can take any language and, if you don't know what you're doing, you can make a right old hash of it and make it incomprehensible to everyone but yourself. The fact that it was Mumps is really neither here nor there. It could have been done in any language. People even do it deliberately - eg in C: http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest

    It's true that the lenient nature of Mumps lends itself to the creation of really terrible code in the hands of the undisciplined or unskilled. But well-written Mumps code can be just as readable and maintainable as most other languages.

    The real problem is that the examples that people such as this article's author use to trash Mumps are legacy applications that date from a time when the language lacked a lot of modern features (we're talking late 70's - early 80's), and the bad practices (which at the time were the only available practices) tend to get continued today as the legacy code is onwardly maintained. That's not the case if you were starting from scratch today - in the right hands it's very quick and efficient to develop in and has one of the coolest databases you'll find built-in.

  • Olius (unregistered) in reply to JamesQMurphy

    And quite lucky too that you are not a lawyer.

    "Aiding and Abetting" means "helping" or "conspiring with", not "knowing", "being friends with" or "working with"

  • Tko (unregistered)

    Wo, and am still laughing.... well explained buddy,

  • keith (unregistered)

    As advertised, this is a curious perversion in information technology.

  • (cs) in reply to Rob
    Rob:
    The real problem is that the examples that people such as this article's author use to trash Mumps are legacy applications that date from a time when the language lacked a lot of modern features (we're talking late 70's - early 80's), and the bad practices (which at the time were the *only* available practices) tend to get continued today as the legacy code is onwardly maintained.

    I don't think it's so much that the language lacked modern features, but that originally it was purely an interpreted language (now it's typically a mix) in a time when the supercomputers of the day were less powerful than today's iPhone. Saving several bytes on every instruction by using shorthand was important when magnetic storage was as low capacity, space consuming, and expensive as it was back then. Plus, cutting down the length of the text (short variable names, etc) saved not only space but it made the program faster, because the additional time needed to pull the extra characters off the disk was nontrivial.

    The language itself allowed programmers to code for readability even at the time, but the hardware limitations punished those who made readable code, so most people coded for efficiency.

  • Anon (unregistered) in reply to SQLDave
    SQLDave:
    So, are they gonna convert it to MUMPS.NET?

    I just threw up in my mouth a little. Seriously.

  • Anon (unregistered) in reply to Ahhnold

    [quote user="Ahhnold"][/quote]She divorced him, re-assumed her maiden name of "Connor", and moved to LA where she was relentlessly pursued by a robot from the future until she met and had sex with a man who wasn't even born yet. Now how's that for pedophilia?[/quote]

    Shouldn't that be called prephilia or something?

  • Aaron (unregistered) in reply to Pete

    It's not all that bad. I used to work in Cache', a derivative of MUMPS.

    You get used to the abbreviations pretty quickly, and as someone mentioned earlier, the data storage model is very easy to work with.

  • Darren (unregistered)

    Esta es una historia estúpida. De todos modos, tengo MUMPS trabajo por hacer...

  • (cs) in reply to Ahhnold
    Ahhnold:
    anon:
    da Doctah:
    I trust that the near future will tell us the story of Sarah, the other original found that the company lost around the same time as Darren last year. She was mentioned briefly and then dropped unceremoniously from the narrative.

    Sarah's his wife. It was pretty clear.

    She divorced him, re-assumed her maiden name of "Connor", and moved to LA where she was relentlessly pursued by a robot from the future until she met and had sex with a man who wasn't even born yet. Now how's that for pedophilia?

    I award you 100 Skynets for that.

  • (cs)

    There are just two kinds of [programming] languages: the ones everybody complains about, the ones nobody uses, and MUMPS.

    My apologies to Stroustrup and counting.

  • Quarantine (unregistered) in reply to Bob
    Bob:
    Up here in MA, a very well known company created their own language based on MUMPS. They call it MAGIC. Unfortunately Im not kidding.

    I can think of no more appropriate name for anything that can make skilled programmers disappear in a single work day.

  • (cs)

    When the first MUMPS article came by to TDWTF, I cringed. I was pretty sure that nobody would advocate a transaction-less "array database" which stores data using something akin to another classic WTF, the Storray engine.

    However, it seems that one of the commenters back then was right: there are two kinds of developers. Those who love MUMPS, and those who hate it. I would add a third category of "never heard of it", but they would probably fall into the hater category as soon as they find out about it.

    Just goes to show that any language can have its fair share of defenders; VB isn't alone in being an ugly monstrosity that still has defenders.

  • PJ (unregistered)

    cough I'll just leave this right here.

    http://www.perverted-justice.com/index.php?pg=wantedbhaskaran

  • (cs)
    It was slow, clumsy, and broke more often than a highway road crew.

    Road crews break? Or is this about them taking breaks? Or is it that they brake a lot because they need to stop?

    Or are they out of money? Is the application out of money, just like the road crew? Are we talking about the collective road crew, or any given member of the road crew, so if one member of the road crew is bankrupt, the whole road crew is considered to be broke?

    Is it slowness and clumsiness also like that of a road crew, or just the brokeness? Is it all three of slow, clumsy, and broke more often than a road crew is all three of slow, clumsy, and broke?

    I'm not sure whether the example MUMPS code is worse than that sentence or not.

  • Zomby (unregistered)

    I want the next person who defends MUMPS to do it in relation to a modern language. Because endless "Well Common Lisp crashing into COBOL while being soddomised by SQL was good enough for the 70s," apologetics make me weep for humanity.

    I have bad news for you, you have Stackholm Syndrome.

  • anonymous coward (unregistered) in reply to ExOttoyuhr

    For the last year i am actually working with intersystems Cache (mumps based), and while you have a point (string handling is slightly easier then other languages), i would rather chew off my own hands and stop programming altogether then start a new project in this mess, the storage model might be nice and easy, but something like the JPA framework will take care of the same stuff just as easily.

    Honestly, cache/mumps is SHIT

  • anonymous coward (unregistered) in reply to Ben
    It seems like once you learn it (and the syntax is *very* straightforward) you can be highly productive and use very little machine resources.

    you have GOT to be kidding. computing performance for the stuff is below that of a javascript engine (i have seen benchmarks by highly skilled engineers working with mumps, showing that javascript is faster) and the IDE/compiler makes being productive a huge pain in the ass

  • The Rob (unregistered)

    ... wow ...

    I had a close friend who worked at a graphics / print company. I have the utmost respect for him due to the following:

    When the manager went on vacation, he left his email and computer password on his desk with instructions that the employees were to keep track of the emails coming in from customers and respond to needs in his absence.

    What they found was to say the least underage and vile material that he had been exchanging. They all got together and agreed it was worth them all having to find new jobs, and they called the FBI.

    The manager got a trip to jail, the company closed, and they all found new jobs.

    That is a level of integrity I respect, knowing the cost, they still could not allow that sin to slide. Apparently the company in question here has less ability to deal with such disease, I wish those of good conscience there the best.

  • (cs) in reply to Zomby
    Zomby:
    I have bad news for you, you have Stackholm Syndrome.

    Isn't that something Forth programmers develop?

  • Onni (unregistered)

    Seems to me he ran the code through an obfuscator before skidadlin'.

  • (cs) in reply to frits
    frits:
    Zomby:
    I have bad news for you, you have Stackholm Syndrome.

    Isn't that something Forth programmers develop?

    You sir, have made my day. Well played.

  • Tko (unregistered) in reply to PeriSoft

    You are excused for failing to read between the lines of that statement, it might be due to your tender age or thick-headedness, but i believe its kind of both.... If you are older, then uuum,

  • Ouch! (unregistered) in reply to Tko
    Tko:
    You are excused for failing to read between the lines of that statement, it might be due to your tender age or thick-headedness, but i believe its kind of both.... If you are older, then uuum,
    Or, mebbe he's not a 'merkin and doesn't know what 'merkins mean with that expression?
  • COBOL-guy (unregistered) in reply to chron3

    Well, that would be more fun, but it's quite hard to find people who would pay you for that. Now on the other hand, MUMPS has the potential to be on the same league as COBOL - nice, steady, safe employment with little competition, little risk of downsizing, and you don't need to strain yourself with 60-hour weeks, since management doesn't have a horde of youngsters who are willing to work insane hours for the same pay [unlike most other programming environments].

  • Confused... (unregistered)

    This story can't be real. Is anything on this site factual?

  • PEBKAC (unregistered)

    ...at least there is a legal remedy for trying to do and/or doing a 13 year old.

    There is no legal remedy for that code. Yeeeech. >_<

  • Rob (unregistered) in reply to anonymous coward
    anonymous coward:
    you have GOT to be kidding. computing performance for the stuff is below that of a javascript engine (i have seen benchmarks by highly skilled engineers working with mumps, showing that javascript is faster) and the IDE/compiler makes being productive a huge pain in the ass

    Do please let us see these benchmarks by these "highly skilled engineers". Here's a few real ones that seem to tell a somewhat different story:

    http://www.redhat.com/pdf/Profile_Benchmark_Results_11_15_2007.pdf

    http://www.intersystems.com/cache/whitepapers/Cache_benchmark.html

    http://tinco.pair.com/bhaskar/gtm/doc/misc/101005-1dthreeen1fFilesystemBenchmark.pdf

    Mind you, given the performance on Google's V8 Javascript engine these days - as used in Chrome and Node.js, maybe a comparison with Javascript might soon be seen as worthy :-)

  • Rob (unregistered) in reply to Confused...
    Confused...:
    This story can't be real. Is anything on this site factual?

    I doubt it

  • Tko (unregistered) in reply to COBOL-guy
    COBOL-guy:
    Well, that would be more fun, but it's quite hard to find people who would pay you for that. Now on the other hand, MUMPS has the potential to be on the same league as COBOL - nice, steady, safe employment with little competition, little risk of downsizing, and you don't need to strain yourself with 60-hour weeks, since management doesn't have a horde of youngsters who are willing to work insane hours for the same pay [unlike most other programming environments].
    ............................................. "MUMPS has the potential to be on the same league as COBOL"... hahaha, its funny what MUMPS is aspiring to be. But you are spot on, MUMPS/COBOL and the other bulky/lazzy languages are for those people who don't like change.

Leave a comment on “Diseased”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article