Some Hurried Thoughts

Given that people aren't always mindful about what they do, sometimes almost preferring that people make suggestions they can just passively agree to, it's quite a responsibility to make really casual choices sometimes.

For example, in Facebook, the choice of metaphor where we call people “friends” if we connect to them socially there has some amazing ramifications. People dither endlessly about whether to “unfriend” someone, or they lament being “unfriended.” These follow from the choice, though, for the system to refer to these people as in fact friends, like we have in real life. It's a weighty decision to make someone a friend, and a lot of work to hold a friendship.

But what if Facebook had called them “guests” instead? What if the metaphor had been that of a dinner party? Would our expectations of them be different? They'd be the same people with the same capabilities. Would it seem like the same huge thing to disinvite someone, or to ask them to leave the party? People do this, and friendships survive. Also, people invite people who are not really full-fledged friends to a party. Our expectations guide us in weird ways. I've come to think of people I'm connected to on Facebook as my party guests, and it leaves me feeling freer to not worry it's so heavyweight to decide that maybe they weren't right for this party.

In fact, though, I wanted to talk about computer keyboards. There are some subtle and interesting influences there. Some keyboards have a notion of BACKSPACE or DELETE, as well as arrow keys. So people rush to make editing commands that make use of these. There isn't always just one single interpretation, so some keys are jump-off points for imagination.

I used to use Lisp Machines decades ago. Special computers that had support for the Lisp programming language in hardware. But they also had interesting keyboards that were evocative in various ways, with fanciful keys labeled SUSPEND, RESUME, ABORT, etc., as well as even stranger keys like ones with roman numerals (I through IV) or with thumbs pointing in various directions (up, down, left, right).

The SUSPEND key was interesting because it strongly suggested the need to suspend a program in the middle, that one might later RESUME. ABORT presumed you needed to stop things, as often the ESC (“Escape”) key does on conventional keyboards. Prominently featured metaphors that made one want to make their programs use them.

Though I often wondered why there was not a corresponding key marked HURRY. Ought stopping a program without intermediate results be the only way to stop them? A lot of programming technology concerns itself with various ways to communicate stopping a program that's running, but always it's assumed that it has to give up on the idea of a graceful answer if you stop prematurely.

For example, there's a technique in graphics called interlacing where when sending a large image, the bits are sent in an order so that you can start to see the image early in fuzzy form and as more bits are received you can display it in crisper and crisper detail. It seemed to me that there might be occasions where you got tired of waiting for a download and pressed hurry to say “stop gracefully, the fuzzy image is fine.” This technique is perhaps not as relevant now that networks have gotten faster, but when first developed was quite important, and anyway I'm just offering it as a way to illustrate that there can be notions of partial results.

Or you might be doing a search and know that something has searched half of something and is waiting to the end to report results but you just want to see what's done so far, so again you could say HURRY and maybe get partial results instead of the full results.

If output is only to the screen, there's little difference between the abort and hurry concepts I'm describing, but if it's an API that returns a structural value, aborting usually means not returning a value, so having a way to interrupt in a way that caused the running program to return a well-structured partial result instead might create some different interaction styles. Here's a sketch in Python:

from collections import namedtuple

class HurryException(BaseException):
  """
  An exception that could be connected to
  a Hurry key interrupt, if we had such a thing.
  """
  pass
  
searchresult = namedtuple('searchresult', 'found,complete')
    
def hurryable_search(tester, collection_to_search):
  found = []
  complete = False
  try:
    for x in collection_to_search:
      if tester(x):
        found.append(x)
    complete = True
  except HurryException:
    pass  # Allow what may be a partial search
  return searchresult(found=found, complete=complete)
  
def hurry_up():
  try:
    raise HurryException()
  except Exception:
    # If there's no handler, then don't hurry after all.
    pass

Note that there are other possible implementations that, rather than raising an exception, might just dynamically adjust a parameter that controlled the degree of care taken on a search step. I'm not suggesting a specific strategy, just that such strategies exist.

And I could be wrong about the particular examples I've chosen being good ideas. Maybe they aren't the best illustrations. But I'm in a hurry to finish this essay and they were what I came up with in the time I alloted myself, before I told myself to just hurry up and go with what I had.

What I'm really trying to say is that I think the absence of a HURRY key on the keyboard means people mostly don't give a second thought to this question of whether programs should be possible to ask to “hurry up.” People just assume that if the key isn't there, the functionality is probably not needed from the keyboard. In effect, they assume the key is not there for a good reason. But maybe it's just an accident or a failure of imagination.

So, just to estate something I said already, but now that you have a bit more context: We spend a lot of time passively accepting that these metaphors we are offered, whether in terms of models of interaction or markings on a keyboard, are the right way to think about things. And we spend far too little time asking ourselves if they're the wrong metaphor or if some interesting metaphor has been omitted. Out of sight, out of mind, I guess.

It's a small point. But I figured if I said it out loud, you might end up passively accepting that it's something you really should think about.

 

---

Author's Notes:

If you got value from this post, please “Share” it.

The Suspend/Resume/Abort image is cropped from a photo I took of my own Lisp Machine's keyboard.

The HURRY image was generated at abacus.ai using Claude Sonnet 3.5 and FLUX 1.1 [pro] Ultra. Light post-processing was done with Gimp.

Should Fix Climate

On Mastodon, Bookchin Bot, a bot that posts book quotes, circulated this quote:

---

 “The term ought is the stuff out of which ethics is usually made—with the difference that in my view the ‘ought’ is not a formal or arbitrary regulative credo but the product of reasoning, of an unfolding rational process elicited or derived eductively from the potentialities of humanity to develop, however falteringly, mature, self-conscious, free, and ecological communities.”
  —From Urbanization to Cities

---

I found this philisophical discussion of “ought” interesting. I learned philosophy from various people, some of whom seemed to grok its importance, and others who lamented its impotence, openly fretting it might have practical value only at cocktail parties.

As a computer professional who's pondered ethics a lot, I've come to see philosophy as what makes the difference between right and wrong answers or actions in tasks involving complex judgment. It can be subtle and elusive, but is nonetheless necessary.

I was Project Editor for the Common Lisp programming language, in effect holding the quill pen for reducing a number of technical decisions about the meaning and effect of the language that were voted by a committee in modular proposals but needed to be expressed in a coherent way. Nerd politics. They decided truth, and I had a free hand in presenting that truth in a palatable way, time and budget permitting. Programming languages are complicated, and implemented by multiple vendors. Some effects must happen, or must not. Others were more optional, and yet not unimportant, so we struggled as a group with the meaning we would assign to “should”.

Computer programs, you see, run slower, or cost more to run, if they are constantly cross-checking data. In real world terms, we might say it's more expensive to have programs that have a police force, or auditors, or other activities that look for things out of place that might cause problems. But without these cross-checks, bad data can slip in and get used without notice, leading to degraded effects, injustices, or catastrophes.

Briefly, a compiler is itself a program that reads a description of something you'd like to do and “compiles” it, making a runnable program, an app, let's say, that does what the description says.

A colleague criticized my use of “should” in early drafts of the language specification, the rules for how a compiler does its job. What is not an imperative has no meaning in such a document, I was told. It's like having a traffic law that says “you should stop for a red light”. You might as well say “but it's OK not to”, so don't say it all. And yet, I thought, people intend something by “should”. What do they intend that is stronger?

As designers of this language, we decided we'd let you say as you compile something that you do or don't want a safe program. In a “safe” world, things run a bit slower or more expensively, but avoid some bad things. Not all bad things. That's not possible. But enough that it's worth discussing whether the expense is a good one. Our kind of “safe” didn't mean safety from everything, but from some specific known problems that we could check for and avoid.

And then we decided “should” was a term that spans two possible worlds. In a “safe” world, it means “must”. That is, if you're wanting to avoid a list of stupid and easily avoidable things, all uses of “should” need to be interpreted as “must” when creating safe applications, whereas in an unsafe world the “should” things can be ignored as optional.

And so it comes down to what kind of world you want to live in.

Climate change, for example, presents us with problems where certain known, stupid, avoidable acts will put humanity at risk. We should not do these things if we want better certainty of survival, of having a habitable planet in which our kids can live happily or perhaps at all. Extinction is threatened if we don't do these things.

But they are expensive, these actions. They take effort and resource to implement. We can do more things more cheaply without them, by being unsafe, until we are blind-sided by the effects of errors we are letting creep in, letting degrade our world, letting set us up for catastrophe.

So we face a choice of whether to live knowingly at risk of catastrophe, or do the costly investment that would allow us to live safely.

We “should” act in ways that will fix Climate.

But we only “must” if we want to sleep at night knowing we have done the things that make us and our children safe.

If we're OK with mounting pain and likely catastrophe one day , perhaps even soon, then we can ignore the “should”. The cost is that we have elected an “unsafe” world that could quickly end because we'd rather spend less money as we risk such collapse than avoid foreseeable, fixable problems that might soon kill us all.

That's how I hear “should”. I hope you find it useful. You really should.

---

If you got value from this post, please “Share” it.

This post is a mirror of a post I wrote yesterday (March 11, 2024) on Mastodon.