OK. It's been six months or more since I last updated this blog.

Astute readers will probably have realized that I've fallen out of the Cache world. My day-job is now working with Python and Django which, of course, makes me very happy.

But I have a bit of sadness too. I learned a LOT from working with Cache and ObjectScript. Some of it was painful. Some of it was weird. But much was enlightening. I often found myself realizing how different a programmer's world could be from that which I considered mainstream. I'm grateful that I had the chance to experience that. It made me a better (and humbler) programmer. Humbler because it doesn't matter how bad something looks, chances are it may have seemed, or even been, the right solution to some problem, somewhere, somewhen. Seeing that, teaches perspective.

Furthermore, I stand by the things I've written before. I still believe that both the theme of old-skool legacy medical systems coming to terms with the modern web 2.0 environment, and Intersystems' platform's potential for reinventing itself, are interesting.

I'd like to know more and follow both. OTOH, my new day-job and new set of concerns are taking up way too much time. If I could, I'd have attended the Slipstream Workshop this coming week, but as it's a work-day, I won't be able to. Good luck for everyone who's attending, anyway.

Finally, this is not goodbye. If any MUMPS related thoughts or news comes my way, I'll still pass them on. And if anyone else out there in the Cache or MUMPS communities would like to take over and continue this blog, I'd be happy to add you as a co-author. Just drop me a note in the comments here.

L8r peeps ...

PS : I'm extremely impressed with GitHub at the moment. So much so that I've decided that it's worth moving Twistah across to it from the rather unexciting Google Code. The new repository is http://github.com/interstar/Twistah/tree/master.

The anti-MUMPS troll at the Daily WTF? (admittedly, we've all been there) has another anti-MUMPS story.

If you've been following the discussion over Mumps : the IT world's best kept secret? you'll have noticed that one thing that stands out about Caché / MUMPS is its unusually structured data-store of persistent, multi-dimensional ragged-arrays. And Rob Tweed makes a case that this is a better fit than a relational database for internet scale applications. He cites Google's BigTable and Amazon's S3 as examples of a trend away from relational dbs in favour of key value pairs.

Today Steve Yegge has an interesting meditation on a similar theme, about "domain modelling schools" and the need for programmers to have experience of multiple tools and organizing principles. (And while he doesn't note the MUMPS model, it would be another interesting one to add to the list.)

Worth reading, also, this Cringely piece on how relational databases don't work so well in a parallel cloud where disk-access is often a bottleneck so more of the live database is moved into memory. (Killer quote : "Google has THE ENTIRE INTERNET IN MEMORY AT ONCE.") Disk is just used for backup / persistence."

More discussion of Rob's future of Mumps is going on on the mailing list and in comments to his original post.

Rob Tweed asks if MUMPS is dead

Worth reading his thoughts. Some intriguing ideas, such as his own work making the MUMPS db accessible from Python and other scripting languages, and the parallels between the MUMPS db and Google Application Engine and Amazon's AWS.

Workaround for the Scoping Gotcha

My colleague pointed out to me today that you can get around the scoping issue I mentioned by writing your method like this :

 
  Method f() {
    set x = 6
    set m = "write !,"_x ; difference
    xecute m
  }
 

What's the difference? Instead of including the name of the variable x inside the string, you concatenate the value of the local variable x with the string at run-time, before the string is finally evaluated. Because the value of x is resolved before the xecute, things work as you'd expect.

That's true. But I still regard this as a serious bug. An equivalent python program :

 
class A :
    def f(self) :
        x = 6
        m = "print x"
        exec m

x = 9
a = A()
a.f()
 

prints what you'd expect : the number 6.

What's really going on to cause this issue in Caché? My guess is that the OO layer in Caché is compiled down to plain Caché .int routines which don't have a significantly different semantics or scoping rules to Caché ObjectScript. In order to get the effect of the private world inside the object, at compile time the variable x is renamed to some object-specific equivalent. Of course, this renaming affects the real references to x, but not the string assigned to m.

When the VM then tries to xecute the string, it encounters the name x but finds no binding in the local execution frame and so, according to COS's dynamic scoping rules, has to look down the stack for a frame which does have a binding, the place from which we call y.f(), where x is bound to 9.

Of course, this hypothesis might be completely wrong. Expert correction is welcome.

Don't be confused. This is NOT Caché ObjectScript. :-)