MishMash

The user is dead, long live the user-developer

Martin Fowler has interesting summary of OOPSLA2005. Among other things, he says:

Mary Beth Rosson had a keynote suggesting that we think about ditching our notion of 'users' and thinking instead about 'use-developers': people who build their own tools such as mail filters and spreadsheets. These use-developers require a different approach to thinking about usability and features. These use-developers need better tools (hello Language Workbenches) and better practices that incorporate much of what we've learned about software development.

Hear hear. This is precisely the sort of approach I'm trying to take with the modelling and simulation framework I'm building trying to build, which now goes by the name ReFrame.

These different features have profound implications right down into the heart of the software we create. The accumulation of hacks approach to writing software breaks down here even more badly than it does with non-programmable software. Instead, it is critical that the software implements a simple, pure metamodel, which provides much of the abstract syntax and semantics for the language(s) exposed to the user-developer (I prefer this to use-developer, it sounds better and seems to make more sense; perhaps I'm missing something).

In my own work this has led me, slowly but inexorably, to the situation I now find myself in of working out this metamodel as a logical theory. That approach might not be appropriate in all cases, but it is certainly paying dividends in mine. It can then be wrapped up in custom syntax, and explained in more accessible terms.

Room for at least one more big leap

Via Lemonodor:

Guy Steele is writing a new language. Called Fortress, it's intended as a replacement for FORTRAN — a language for mathematical/scientific computing.

This could be interesting. It overlaps with what I'm trying to do, but I don't think there's any need to get scared (yet). It may well be, for example, that Fortress provides a sensible target language for the higher level stuff that I'm working on. If a load of money is poured into optimising Fortress compilers, then that work could be used by targeting Fortress as a sort of assembly language.

The idea of making it look like math is interesting: that presumably means it can't be programmed except with dedicated editors. Not good for uptake, I wouldn't have thought.

This is apparently Sun saying, "Java isn't and will never be a great choice for scientific computing."

Kay Interview

Via James Robertson, an interview with Alan Kay at ACM Queue:

  One of the things that people realized from these extensible languages is that   there is the unfortunate difficulty of making the meta-system easy to use. Smalltalk-72   was actually used by children. You’re always extending the language without   realizing it when you are making ordinary classes. The result of this was that   you didn’t have to go into a more esoteric place like a compiler compiler—Yacc   or something like that—to add some extension to the language.

As ever from Kay, some lovely ideas. Well worth a read.

I didn't realise quite how much Smalltalk had changed through the 70s. Sounds as if I could do to get my head round Smalltalk-72 at some stage.

And Lisp begat Smalltalk, and Smalltalk begat …

Funny timing. I tried to print out this family tree of programming languages (printable PDF version s available) the other day, and somehow failed (sometimes things just don't get through, and there are too many computers between me and the printer, managed by somebody else, for it to be worth doing anything other than shrugging), so I tried again this morning. I had a browse, said "ah!" a few times, and went back to my morning engagement with bloglines. Next up, Smalltalk weblogs, and James Robertson linked to the same diagram, while in a comment gabriele renzi points to an alternative, slightly whimiscal but nonetheless worthwhile view.

I have to say I'm slightly surprised at how little influence seems to be shown from Smalltalk (and Lisp) out. There's a limit to what can be shown on a diagram like that, I guess, and the connections are all at the conception of a language (so the ongoing slow accretion of Lisp/Smalltalk features in various "agile" languages doesn't appear). Still, I'd have thought C++ owes a lot to the modifications Smalltalk made to the Simula model of computation, for example.

Then again, perhaps it's better not to show such things when they are so badly corrupted in transfer, lest the source of the ideas be blamed for the result.

There would be an interesting linguistic study in how the concepts established in the development of Smalltalk were diluted as they spread; how the same words came to have weaker meanings more in keeping with what people knew already.

Heisenbugs, Schroedinbugs

I'm horrified that I hadn't come across these concept/terms before. From the Free On-Line Dictionary of Computing:

Heisenbug: (From Heisenberg's Uncertainty Principle in quantum physics) A bug that disappears or alters its behaviour when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code, such as that which relies on the values of uninitialised memory, behaves quite differently.)

Schroedinbug: (MIT, from the Schroedinger's Cat thought-experiment in quantum physics) A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harboured latent schroedinbugs for years.

Follow the links for more related terms.

Eiffel is for building towers!

Pascal is for building pyramids -- imposing, breathtaking, static structures built by armies pushing heavy blocks into place. Lisp is for building organisms -- imposing, breathtaking, dynamic structures built by squads fitting fluctuating myriads of simpler organisms into place. [Alan Perlis, Foreword to SICP]

Eiffel (it has just occured to me) is for building towers (of course) -- imposing, breathtaking, static structures built by hundreds of employees riveting carefully crafted pieces of iron into place.

You can do a lot more with iron than you can with blocks (though if you want to build a breathtaking pyramid, you're probably as well sticking with blocks) but still at times you just can't do enough. It took me three years of writing code in Eiffel before I realised it just wasn't going to take me where I nedeed to go, which is depressing given that I already knew Smalltalk. In the end it was reading SICP that opened my eyes.

It's worth continuing the quote:

The organizing principles used are the same in both cases, except for one extraordinarily important difference: The discretionary exportable functionality entrusted to the individual Lisp programmer is more than an order of magnitude greater than that to be found within Pascal enterprises. [Alan Perlis, Foreword to SICP]

Discretionary exportable functionality is key — functionality such as the ability to compile and install code at run time, as I just mentioned. While non-Free licensing can get in the way a bit, it is only in languages like Lisp and Smalltalk that there is any hope of blurring the boundary between developer and user, and it is only when this is done that computers can hope to fulfill any significant fraction of their potential. This, of course, was one of the fundamental drivers for Smalltalk. Lisp supports it (in my interpretation) for the simple reason that, given that it is possible, it would be perverse to do otherwise.

There's a lot of perversity around.

Abstraction Tax

Intruiging. I've had the phrase "abstraction tax" in my head for a while, and was about to use it in a report, so I thought I'd see if I could find out who else used it. Google doesn't help if water-related uses are eliminated.

The idea I'm referring to is that, at least in naive implementations, the use of layers of abstraction in software carries a performance penalty. The argument I'm making is that generative programming — through Lisp style macros, for example, or, in the case I am discussing, by generating, compiling, and installing code at run time — provides an opportunity to sidestep it.

If anyone knows of this or another phrase being used in this way, do let me know.

Croquet progress

Having used Squeak a bit in the past and followed its progress, I had come across Croquet before, but hadn't seen that web site until it was pointed out on Cooking with Lisp and picked up by Patrick Logan.

If you're interesting in online collaboration and shared environments, you must take a look at the set of screenshots.

Looks to me as if the Croquet team have been quietly preparing something truly spectacular.

I've been wondering for a while if anyone would pick up on the power of Groove and start work on the Free and cross platform infrastructure which would be necessary for its potential to be fully realised. Could this be it? It sounds as if Croquet is quite focused on simultaneous presence in shared spaces, but presumably it is not restricted to this.

Update (2004-07-05): Updated the links to point to the new web site.

Update (2004-07-07): Summaries of a Croquet demo by and via James Robertson.

This reconfirms my belief that writing a test suite tests not only an implementation, but also a specification. Untestable requirements are bugs. [pfdietz]

"One serious obstacle to the adoption of good programming languages is the notion that everything has to be sacrificed for speed. In computer languages as in life, speed kills." [Mike Vanier, quoted in the OCaml tutorial, linked from Andrew Birkett's blog via Lispmeister]