$ZCONVERT(stringVar, "O", "JS")

Which escapes stringVar into a valid JavaScript string without quotation marks doesn't escape line separator or paragraph separator (U+2028 and U+2029), when it should.

This was also a bit of a problem in browsers, JSONP and the JSON spec a while ago. Life in the MUMPS world isn't as bad as you'd think. Except for a lack of nice libraries. You do not want to know when regexes made it into the language. Last year. But there has been something similar - pattern matching - which alleviated the need for them a bit. And calling out to DLLs is fairly easy. It's really driven more by the healthcare industry than anything else.

Also, here's a short FizzBuzz I wrote:

  f i=1:1:100 w ! w:'(i#3) "Fizz" w:'(i#5) "Buzz" w:'$x i

  for i=1:1:100 {
    write newline
    write if not i%3 "Fizz"
    write if not i%5 "Buzz"
    write if not cursorposx i
  }

for i in [1..100] console.log(['Fizz' if i % 3 is 0] + ['Buzz' if i % 5 is 0] or i)

http://stackoverflow.com/questions/4151554/need-mumps-sample...

I've actually decoded it. Turns out that the thing most useful for this, by far, is an ASCII table :P

This is kind of a litany of relatively-unstructured programming languages and sounds like a relatively one-dimensional view of computer program organization techniques. Of those listed, PHP is the one with the most advanced code-organization and object model, but its object model is hardly renowned.

Have you ever considered learning something like Ruby in depth and messing around with intensive object-oriented techniques and write-your-own-DSL metaprogramming and the like, so you can know how the other half of the world gets to program?

(ed) oh, and here's me getting -1'd. wonder what that's about. probably someone with thin skin thinking that asking about highly structured programming implies a put-down on the other kind. maybe I could put in some words of praise for Matlab's awesome matrix handling and it'd help? :P

I don't have any formal background in computer science, so thank you for pointing this out, and it's true. In a nutshell, you're telling me to work through SICP, right? :P

Edit: Yes, you need to mention MATLAB's matrix handling. Probably also say something about NumPy and PyPy, I'm sure that'd help too.

I bring it up, not because I think you're likely to be looking for work, but because I thought the others reading this discussion thread might be interested in the fact that it is difficult to hire qualified MUMPS programmers.

I work at a bank, and our banking system (the system that keeps track of the balances in the accounts) is written in MUMPS -- probably because it dates back to the time when that was the shiny new programming language.

But it adds a big bunch of things from error handling to better variable scope to classes to, I wish I was kidding, proper 'if'.

Something that's also been added (to GT.M as well, afaik), because it is so tightly integrated with its database, are tcommit, trollback and tstart as commands, which are strictly speaking database commands and not the kind of thing you'd expect to find in a programming language.

What (if anything) does MUMPS proper have for 'if'?

There's two different types of if constructs, and it's awful, the older one is with a dot syntax.

What's a dot syntax, you may ask? Well, for each level of the if you just prefix a dot:

http://docs.intersystems.com/cache20131/csp/docbook/DocBook....

Makes you want to stab your eyes out. Note also that the comments need to have a dot prefixed as well. That bit me before.

>Makes you want to stab your eyes out.

I dunno...

http://tinco.pair.com/bhaskar/gtm/doc/books/

It's easy to put a CGI interface on top of GT.M - performance is quite good.

http://71.174.62.16/demo/TestCGI.htm

Personally I am working on a utility that wraps GT.M in an "environment" similar to a Python virtualenv, but I'm not sure I'm ready to show my baby to the world yet...

InterSystems Caché ships with Apache as an administrative web server for its Management Portal, through which you can also run all applications.

It ships with modules for Apache and IIS (ISAPI), and probably others. These come with a little ini file that's meant to sit in the same directory.

Do you live in a place that rhymes with 'Radisson'?

Also, if it wasn't for the sheer number of libraries PHP ships with, I'd without a moment's hesitation say Caché + Caché ObjectScript >>> PHP + MySQL.

As far as I know, no, apart from the shared ANSI M featureset. They're pretty divergent.

Sorry if I'm not going into that much detail :P

So, while we do have a huge pile of legacy code not using SQL you can map your NoSQL data structures to SQL tables and you can also later on convert to a more efficient format that gives you bitmap indices and so on, while still using the global storage backend.

So, it may have been NoSQL until some point in the nineties and after that it was really NotOnlySQL.

There's something a bit therapeutic about seeing the indices, including bitmap indices, and all the data on disk in a format that's intuitive and usable for humans that you can use without going through SQL, but either by accessing it directly or through the built-in ORM system. You don't get that with PostgreSQL or MySQL, or conversely, MongoDB or CouchDB. It's both worlds. Sure, there's a lot of stuff from PostgreSQL that I would kill for - any volunteers? - but as a compromise between the two worlds it works quite well indeed.

Edit: Here's more info:

http://docs.intersystems.com/cache20131/csp/docbook/DocBook....

The awesomest points are the %ID pseudo-column, implicit joins, embedded SQL (which compiles SQL down to native MUMPS code, including cursors and all), near enough complete SQL-92 and DDL compliance. And the ORM stuff.

In other words, MUMPS is a platform and an ecosystem as much as a language. Think of Java or Ruby — for a lot of companies, including MUMPS shops, staying with a specific "sub-ecosystem" is simply the most rational choice because they have so much invested it already.

If you look beyond tech that is currently considered "bleeding edge" — Go, JavaScript, Ruby and so forth — you will find a lot of companies who rely on what you may consider weird or even legacy software. For example, Delphi (a descendant of Borland's Turbo Pascal which is still based on ObjectPascal) is still very popular. In finance, languages like K are still popular. I believe finance still has a ton of stuff based on object databases such as Objectivity/DB, Versant, Matisse and GemStone (Smalltalk), which actually look a lot like today's document-oriented databases. InterSystems Caché, which is based on MUMPS, is a hybrid SQL/OODBMS. In other words, the software market has a lot of aging technology that is still working superbly for the parties involved. Old code is usually proven code.

[1] https://en.wikipedia.org/wiki/K_(programming_language)

This system was originally put together in the 80s and while a complete reimplementation from scratch in Python is possible, it wouldn't really give us that many benefits that we don't already have. We don't have to worry about algorithms all that much - we may just write an SQL query which takes care of things for us. One of the more complex things we do in new code is maybe two levels of $order, the equivalent of your for x in y loop.

We're programming on a level quite a bit higher than C, nor are we exposed to the sheer verbosity of Java, thank god. You think Caché ObjectScript is awful? I think Java is awful.

What Caché gives us is tight integration between the language and the database system, so in that way the choice isn't really between Caché ObjectScript and Python, it's more between PL/pgsql or PL/Python and Caché ObjectScript. Once you go there you'll realise that the code that's written in ObjectScript isn't really affected that much by the choice of programming language anyway. And PL/Python isn't really something you'd want to write a production system in anyway. Between that and built-in ORM, things really aren't that bad.

And 100x readability improvement is just wrong. Sorry, it is. Sure, that may apply to some old MUMPS code that survived the 70s when disk space was sparse but even this is fairly straightforward to expand into something quite readable. We do have syntax highlighting, function calls look the same, and assigning a value to an object is 'set object.Property = "blah"' instead of 'object.Property = "blah"', a difference that's quite trivial.

That's not to say the lack of libraries isn't annoying, but everything really important is there in the right places. I've written a decompressor for tar.gz in about 34 quite readable lines, with error handling and all. gzip is built in these days so it's really mostly .tar I needed to worry about. Alternatively, calling out is just a matter of $zf(cmdLine, -1). Similarly, I've just put chosen (https://github.com/harvesthq/chosen) into our web application, based on Caché. It was easy enough to do.

And it's a pretty top-notch fast SQL implementation with a nice built-in language and a nice ORM and lots of other bonuses like full-text search and bitmap indices and OLAP cubes (yes, it speaks MDX even) if nothing else.

If Caché had no strengths, I would agree with you, but as a non-relational database, it's pretty good. Sparse associative arrays are the default data structure, so it's very popular in, e.g., medical applications, where you would want to be able to store thousands of different things, but any given patient will only need a few of them.

Caché has really been moving away from that though... CacheStorage stores data in a big list in the *D globals.

I think the power in CacheStorage really comes from the indices and - very relevantly to the healthcare industry - all the relationships. They've got a very complex schema they need to support and Caché continues to be pretty good at that kind of thing - see the implicit joins in their SQL variety for example or Zen.

We do make a lot of use of indices, though. Finding records can be incredibly fast.

I'm so sorry. Nothing more fun than manually keeping indices in MUMPS :|

We're pretty happy with it. If, theoretically, we'd need to start from scratch, it'd would definitely be in our top very very few choices. Not least of all because of things like DeepSee.

I could certainly think of things much worse than Caché.

I liked the one-letter verb abbreviations, even if it made the code feel somewhat write-only. Data right next to your front-end language was neat too.

There's no substantial change in readability in going from:

if condition: print "Hello World"

Or: if (condition) { console.log("Hello, World\n"); };

To:

w:condition "Hello, World",!

I never type 'write', but just 'w' instead. Here's a list of commands: http://docs.intersystems.com/cache20131/csp/docbook/DocBook....

> Data right next to your front-end language was neat too.

Don't know about neat, it made it very hard to separate your model from your logic and while convenient at the time that's also quite a bit of a pain.

set foo=^config("foo")

The '^' means it's a persistent variable.

Now do this with in the same number of characters either by reading in a flat file or doing an SQL query in any language. I don't think you'll succeed.

And, yes, it is possible to parameterise this ^config, like so:

set location="^config"

set foo=@location@("foo")

Just like "one letter abbreviations". Again, just "let w = printf" if that's what you're into. I do that kind of stuff all the time, with limited scope.

Sure, you can do import json; json.load(open('config.json')); json['foo'] and I have code like that in production right now, but put pickle in comparison to the above and I'd know which one seems nicer, and not least of all changing ^config("foo") is fully concurrent, caching, network transversable, auditable, with Caché supporting these things like an operating system should, but in a built-in way.

val fooConfig = "config" ^ "foo"

Of course, there would be some config required. There are various ways to handle that, but it could be as minimal as a single line of code. I don't want to be critical of your work, but my own preference is for languages which are DSL-friendly. Although there are some disadvantages (possible lack of fluidity, mildly more verbose), I feel the advantages (lack of vendor lock in, composable with the rest of the language) are worth the trade-off.

Admittedly I've never had experience with MUMPS, but I have used PHP. Until pretty recently, that was a language which attempted to break down the barriers between its syntax and the runtime environment at the expense of the language. Reams have been written on the PHP argument, and I won't contribute further here; just noting that my preference for languages with a flexible syntax and a "do it in a library" attitude is based on having experience with the opposite.

Have you had experience with any of the embeddable-DSL languages (Ruby, Clojure, Scala, Haskell)?

It's not traditional MUMPS, but it adds things like macros, error handling, sane variable scope, regular expressions and so on.

http://docs.intersystems.com/cache20131/csp/docbook/DocBook....

Also see: http://www.mgateway.com/docs/universalNoSQL.pdf

I wouldn't bother.

Ask me again in two or three decades, but our codebase is continuously being touched in all places and there is an ongoing drive to weed out legacy code all the time. But just on the side I've been able to get rid of about 30% of all the legacy code here without spending that much time on it at all mostly with the help of grep, in part because our system has now moved to being 100% web from a desktop client.

As for salary, never enough :P, but considering my age, the economy, and my lifestyle I'm pretty happy.