Tuesday, March 11, 2003

AOP Patented?  Please. There's been a few posts about that, mostly referring to this patent. Karl Lieberherr wrote an entire book published in 1996 (PDF online at that link) that was the precursor to AOP -- except he called it adaptive programming instead.  It's a classic work.  I bought the thing years ago and schmucked my head against the wall trying to understand it.  Kiczales wrote the foreword to the book, for cripes sake.  He is fully aware of the prior art in this area, and seems to be ignoring it.  Or, he considers it to be sufficiently distinct from his own work that it merits not even a mention.  I like the work they've done, but this is a bullshit patent and they know it.  It's like patenting wood construction with 2-and-a-half inch nails, when the prior art is with 2-inch nails. 5:00:41 PM

Naked Objects. Ted Neward has looked at Naked Objects, and finds it deficient.  I've been thinking about this problem for a while, and I think that the Naked Objects approach is correct in the long run.  Usability is a tough nut to crack.  You are always trying to balance flexibility and task specificity.  You want your software to excel at the tasks you anticipate the user will perform, but retain the ability to do things you didn't, hopefully easily. There are some similarities between REST and Naked Objects.  In both cases, you have a relatively small number of verbs, and you try to do some fairly complex things with them.  There are a small number of gestures you can perform in NO -- things like drag, double click to edit, and so forth.  The thing is, most of the time when you're working with objects you are altering state (editing), or linking (connecting) things together.  Sometimes you're creating new things, and sometimes you're deleting things. These common operations can and should be "written for you" or done for you, by a framework.  A common vocabulary can serve us well.  More specialized tasks can have more specialized interfaces. So what I'm saying here is that a hybrid of the two approaches will probably turn out to be an optimal thing in the future.  You will let the basic behavior of the system happen by default, and will provide specialized, task-specific interfaces to get certain things done quickly, or provide non-standard behavior. The REST/NO approach seems to play well with ad hoc information manipulation.  Repetitive entry tasks and/or unusual kinds of data probably won't. You can always extend the basic "vocabulary" of the system to do more complex things, of course. Put me on record as being pro-NO.  Of course, the data being manipulated should not necessarily be classic objects.  There are much more flexible means of manipulating and storing information than OO. 4:49:07 PM

FM RadioStation. No sir, I don't like it.  Why does everybody think that the Outlook-style single-message view is such a great thing?  It blows.  You have to read every item individually.  You can't follow the complete flow of messages.  Your screen keeps blinking and updating all the time as you get through things.  And what do you gain?  Nothing. What I want is a list of new stuff that I'm interested in.  Show it to me in document form, in parallel.  Allow me to click on the title of any story in a list, then scroll to that story in another pane.  Simple. So I uninstalled it.  But, it changed something about my Radio settings, and my news aggregator is messed up.  The aggregator no longer has the ability to retrieve just the new postings; it retrieves everything it can off of each weblog now.  Poop.  I am trying to figure out how to put back the old behavior. So if you like FM RadioStation, beware -- you might be stuck with it for a while. 4:40:39 PM