Designing Interactive Systems

The Craft of Text Editing, by Craig Finseth, is on-line. I remember reading Craig's MIT technical memo, which is a progenitor to his book, in the early 1980's.

If you like reading code, you probably also like reading about designs and patterns. This book is not just a description of an Emacs-like editor, and it is not just about text editing in particular.

This book is about software design and patterns that can be implemented in interactive systems in general. If you are designing an interactive system today, you should have this book digested as part of your vocabulary and design pattern library. Period.

Excercise to the reader: if you typically buy a book that explains how to use a specific language, library, or framework, you will additionally benefit from reading older sources like this. Try translating these ideas into your system of choice. This excercise includes low level details like translating from a pull-based command loop to push-based event handlers. So for example what would an event handler system look like to incorporate Emacs-like keymaps? How might this make your design simpler and more flexible for advanced users with modes and sub-editors, etc.?

What is, er, was Hypercard? A rare gem...

From a software architecture point of view, HyperCard had a number of interesting ideas which might bear reexamination. At a time when persistent object stores were still novel, HyperCard was built around one. It's not going too far to say that its user interface was simply a reification of the object database. HyperCard's programming model was object-like, but didn't fall neatly into either the class/instance or delegation styles. Individual visible cards in a stack were created as instances of prototypic backgrounds and could be pre-populated with text fields and action buttons. Default message passing was an odd hybrid of visual containment and fixed object hierarchy. These features, plus a very texty scripting language, seem to have made for a very approachable tool for the nonprofessional coder or database creator. (To my knowledge there was never a study of programming usage and usability of HyperCard. A real gap.)

If you've never created an interactive stack in Hypercard, you've missed one of the rare treats in the history of software development.

I hope some of the lessons you taught are passed on to new projects that allow just plain folks to try out coding and authoring.

Peme

Danny Ayers passes on a meme about images googled from your first name. Yeah, but look at Danny's compared to mine...

Works for Danny, I guess. 8^)

More Debunking of the Dynamic Language Myths

From lemonodor...

Lisp is Slow (NOT!) summarizes a comp.lang.lisp thread in which some knucklehead said “lisp is slow”, and furthermore that

The best known non-stupid (real problem, any algorithm) benchmark is probably the Coyote Gulch test. There are many languages that it has been translated into. If you can produce (write or find) and post a Lisp version that is within 10% of C performance, I will admit that #1 [lisp is slow] is incorrect.

Within a few days a collaborative programming and optimization effort paid off with a lisp version of the benchmark that was about 2% faster than the C version.

More on the Rise of the Continuation

News via Ted on a potential Kali-like mechanism for Stackless Python...

One interesting(?) thing I learned is that you'll be able to pickle tasklets, which could be used to simulate continuations (this seems like it would be slow), and could also be used to migrate tasklets to a different machine where they could be unpickled and resumed.

His entire Day 2 report from PyCon 2004 is action packed.

Code Reading

Blaine reads code, especially Smalltalk.

There's such a plethora of code out there in Smalltalk land that is entertaining to see how "they did it". For instance, I was surprised to see how small the continuation class used in Seaside was.

Agreed. (Too much?) time can be (well?) spent clicking around the code browsers.

I think it's a good thing. Also trying to get it to execute to a point you don't completely understand. Put a self halt in there and see what happens. Why didn't it get there? Poke around, oh, I think... cool! Look up the stack.

There's never a question of "Did they compile this with -g?" and "Did they provide the source code?"

Irony Dept.

Listed among the proposals for future Mozilla features...

creating a XUL builder plug-in for the Eclipse platform

You and Me and the FCC

From Blaine's site... say no to censorship.

Open Source Desktop and Components

Miguel gets all postmodern on us...

I personally think that we should move away from the "Linux Desktop" view of the world, and more into the "Open Source Desktop and Components" (I first heard this idea from Nat a few months ago).

It may sound like a trivial difference, but it is not. As much as I love the Linux desktop, and as much as I love our tools, the most successful desktop components today are OpenOffice and Mozilla because of their cross-platform nature.

Windows NT, XP, MacOS X and Longhorn will be with us for a long time. The best possible outcome of open source will likely be a segmented market like 33/33/33 for the desktop market.

Contrary to his previous statement about the Longhorn API, the quotes here nail the only workable reality head on...

The best bet today is to share as much as possible on your "engine" and redo the OS integration components for each OS you support.

By the way, since this postmodern approach is inevitable, the light cast onto the Longhorn approach (seemingly "all or nothing") appears very dim indeed.

The End of Days: Pisces to Aquarius?

From Miguel, looking through his Mono-cle

In the Longhorn world, APIs are no longer your C/C++ grandmother APIs. Every new API introduced for the operating system is built on top of .NET. If you want to take advantage of it, you must write .NET code.

I'm not sure what to think of this yet.

Consider right now CPython, VisualWorks Smalltalk, Haskell (GHC), PLT Scheme, etc. all access dotnet from the "outside looking in".

Consider also that by the time of Longhorn ships (what? 2007?) that interoperability between processes and nodes will be some N times faster and it is already quite acceptable. Passing messages to Longhorn services will be a common mode of leverage.

I have no doubt that an Internet OS can yet be built in a vendor-neutral, post-modern fashion, of which a Longhorn computer is just one small legacy library. Think about it.

It's all about the wire, right? Isn't Longhorn the last gasp of a PC mindset? (BTW, Longhorn can't suck until it's released... reportedly three years from now. This should be plenty of time to reduce suckage.)

Excercise for the reader: Look through the Longhorn material. Make a note of every feature that appears to be caught in the muck of the 1980's PC, or at best the 1980's high-end workstation.

A post-modern Internet OS lives above that muck, diving down as necessary, threading all the pieces together in new ways.

Roll On Floor, Laugh Out Loud

From Steve Martin's "script notes" on the Passion... hilarious...

Merchandising issue: it seems the Cross image has been done to death and in public domain -- we can't own it. Could the Cruciifixion scene involve something else? A Toyota would be wrong, but maybe there's a shape we can copyright, like a wagon wheel?

Another Human Interest Story

I'm sure glad they caught Martha Stewart lying about, uh, not commiting the crime she was found not guilty of. Meanwhile, Dan reports more of the real sleaze.

It never ends? Not according to ABC's John Stossel. He says markets will always regulate themselves.

Oops. Looks like Stossel himself needs some regulation. Caught in a few "misleading" statements.