Rambles around computer science
Diverting trains of thought, wasting precious time
Mon, 07 Apr 2008
Why static state shouldn't be a bad thing
Gilad Bracha's recent-ish post about eliminating “static state” from (imperative) programming languages is interesting. My first objection was that he didn't define what he meant by “static state”, since I got there from a link which didn't provide much context, but I guess if you just assume a Java-like setting then it's clear enough.
My second reaction is: surely there shouldn't be any disadvantage from defining some data as your program as static, if it really is static? “Static data” simply means that the lifetime of the data is exactly that of your program, and specifying this up-front is surely useful for analysis. Object-oriented languages are well-known, in fact, for introducing too much dynamism, forcing the programmer to write code which dynamically sets up state which we would rather specify statically. As a stupid example, consider that Java has severely restricted support for complex literals, such as array literals and object literals -- typically they're limited to initialiser expressions. Eide et al provide some more realistic examples concerning design patterns, and the potential for static conformance checking thereto. This paper is one with which Bracha might well be familiar, given that it came out of Utah which is where he got his PhD.
All of his listed criticisms can be answered by a similar but different approach: instead of eliminating static state, give static-ness orthogonal treatment. If collections of static state complicate memory management, it's because they're needlessly treated differently from collections of dynamic state (i.e. objects). If they're bad for reentrancy, the same code operating on an object would not automatically become re-entrant. If they're causing problems for distribution, it means you haven't designed your program correctly. If they're bad for initialization, you'd get the same problems with an overly large object. Clearly, the security argument boils down to the fact that static variables have needlessly wide visibility. The real problem is that real-world uses of static state tend to also be instances of bad encapsulation or bad modularisation.
Surely we can have a language which encourages good modularisation by giving orthogonal treatment to static versus non-static objects, allowing multiple statically-defined instances of the same module (sorry, I mean object), and so on? And as shown by my momentary apparent mix-up in that last sentence, the real target of Bracha's elimination urge should be the artificial distinctions between program, module and object. However, it does sound like this is exactly what he's doing with Newspeak, and indeed this approach was very much foreshadowed by his PhD work on Jigsaw. So I suspect he knows all this all too well, and has for some reason decided to put an overly naive (or at least clumsily-expressed) version of the argument on his blog. How annoying.
[/research] permanent link contact
