Making it stick.
Friday, March 26, 2004
  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.  

Wednesday, March 24, 2004

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^)  

Monday, March 22, 2004
  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  

Sunday, March 21, 2004
  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

Patrick Logan's weblog.

March 02, 2003 / March 09, 2003 / March 16, 2003 / March 23, 2003 / March 30, 2003 / April 06, 2003 / April 13, 2003 / April 20, 2003 / April 27, 2003 / May 04, 2003 / May 11, 2003 / May 18, 2003 / June 01, 2003 / June 08, 2003 / June 15, 2003 / June 22, 2003 / June 29, 2003 / July 06, 2003 / July 13, 2003 / July 20, 2003 / July 27, 2003 / August 03, 2003 / August 10, 2003 / August 17, 2003 / August 24, 2003 / August 31, 2003 / September 07, 2003 / September 14, 2003 / September 21, 2003 / September 28, 2003 / October 05, 2003 / October 12, 2003 / October 19, 2003 / October 26, 2003 / November 09, 2003 / November 16, 2003 / November 23, 2003 / November 30, 2003 / December 14, 2003 / December 21, 2003 / December 28, 2003 / January 04, 2004 / January 11, 2004 / January 18, 2004 / January 25, 2004 / February 01, 2004 / February 08, 2004 / February 15, 2004 / February 22, 2004 / February 29, 2004 / March 07, 2004 / March 14, 2004 / March 21, 2004 / March 28, 2004 / April 11, 2004 / April 18, 2004 / April 25, 2004 / May 02, 2004 / May 09, 2004 /

Powered by Blogger