A Trifle Absurd

Activity Invention

Don Norman (yes, that Don Norman) proposes a shift in attitude from Human-Centered Design to Activity-Centered Design. He contends that the basic tenet “adapt the technology to the person”, while noble-minded, ignores the simple fact that “people do adapt to technology”:

Learn the activity, and the tools are understood. That’s the mantra of the Human-Centered Design community. But this is actually a misleading statement, because for many activities, the tools define the activity. Maybe the reality is just the converse: Learn the tools, and the activity is understood.

This is most evident in the ineffable realm of software. Suppose someone wants to learn how to browse the Web; how are they going to learn the activity apart from learning the tool (the browser)? The browser’s capabilities and limitations define the activity of browsing the Web.

Great innovations don’t just improve a preexisting activity, they define a new activity. This ought to set software designers thinking: what new activity, what new category, what new mode of thought is hovering just on the edge of consciousness, waiting to be called into concrete existence? The limits aren’t inside the computer—they’re in our imaginations.

Out of the Reference-Counting Stone Age

As I suspected, my honeymoon with Objective-C is ending. The dual nature of C gunk and sorta-Smalltalk-esque objects leaves me pining for a simpler, cleaner language. And I’ve just had the inevitable blowup of circular references mixed with refcounting, which makes me wonder how many other refcounting bugs I haven’t caught yet because stuff is just silently leaking. Refcounting may be better than nothing, but I’d rather let the computer manage my memory, thank you.

Speaking of which, I’ve been taking a glance at region inference (see the MLKit for more info) as an alternative to garbage collection. Looks interesting, but I wonder how well it generalizes to the concurrent case. Perhaps some combination of linear types (which don’t need memory management), region inference, and garbage collection will prove more powerful than any of those techniques alone.

Linear Values

A linear value is a value that can only be used once. Put another way, its reference count is guaranteed to always be 1. That means no sharing, and no aliasing: if a function receives a linear value x as an argument, then x can appear only once in the body of the function.

So if x is passed down to another function, it’s gone unless that function returns it. There’s a concrete physical metaphor: if you give x away, you don’t also still have it (which would be the case with a normal, nonlinear value).

Okay, then, what are linear values good for? Assume you have a purely functional language, with immutable data structures. Linear values can be destructively updated behind the scenes, while still preserving referential transparency, because no other pointers are pointing at the value. Similarly, linear values can model external (non-functional) objects in a functional way. And as a bonus, linear values don’t need garbage collection: since there’s only ever one reference, any function that takes a linear value and does nothing with it is implicitly freeing it.

Henry Baker has written a good introduction to linear values, as well as several other papers about them. The ever-readable Philip Wadler has tackled the subject as well—see in particular “Linear types can change the world!”.

The Clean programming language uses linear values to handle I/O and other outside-world interaction. In essence, Clean uses linear values where Haskell would use monads. Clean also, unfortunately, shows how clunky linear-value passing can be; you often have to explicitly pass extra arguments around.

Are linear values a useful idea? Yes, if you want to preserve referential transparency. Of course, you could argue that they’re a bit of a cheat: sure, they preserve the rule that a function always returns the same value when given the same arguments, but they do it by making sure that a function is never given the same arguments twice.

No, Really, It’s Evil

Some days I need a four-foot sign hanging over my desk: “Premature optimization is the root of all evil.” We all keep saying it, but how often do we act like we believe it?

I tied myself in knots working on Overleaf’s proportional-font-indentation feature. Each scheme I came up with seemed expensive in time, or space, or both. I started wondering if I should just give up on it. But yesterday, in a fit of pique, I decided to hack up a ludicrously inefficient implementation just to see if it would even work. And what do you know, it does.

It’s got some bugs, of course, and there’s no way it will scale to large files the way it stands. But now that I can actually see something real and working, I’ve got the motivation to slog through the work to make it right.

That’s the underappreciated benefit of avoiding premature optimization: by getting something up and running that much more quickly, you get the incremental forward motion of accomplishment that motivates you to do the next thing.

REST Beyond the Web

(via Tim Bray) Benjamin Carlyle wants to broaden the REST vision, by using REST as a model for all kinds of software (not just Web stuff). He’s experimenting with a glade replacement for building non-web UIs, and musing on the contrast between REST and OO:

REST says that the set of operations you can perform on resources should be almost completely uniform. Instead of defining new operations, REST emphasises the creation and naming of new resources. As well as limiting verbs, REST seeks to reduce the number of content types in play.

Reading that, I realized why REST always seemed so familiar to me: Many of its basic ideas are present in Plan 9. Uniform operation: Plan 9 tries to make everything look like a file, accessible by the same few system calls. Naming new resources: any new service or resource is attached to the filesystem namespace. Few content types: simple, textual protocols rule the day.

Even though Plan 9 predates REST, it does give evidence that REST’s ideas can lead to good design. As a language guy, that makes me start thinking about whether this stuff merits inclusion at the language level. Joe Armstrong (one of the main designers of Erlang) has had some thoughts in this direction, and the array language K already has a tree-structured namespace (search for “K-tree” in this article).