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.

Hacking, before the Internet

The term hack has existed for quite a long time in various forms. MIT uses the term to describe playful pranks some members of the community have played. These tricks are intended as benign although they have sometimes played out in unexpected ways. If you want some samples, you can find summaries around the net (for example, click here) or you can see the movie Real Genius, which is a lot more true to life in many respects than you might imagine.

When I arrived on the MIT computer scene in the latter part of the 1970's, the term “hack” had taken on an even more generic meaning than this prank sense. For all intents and purposes, a “hack” was simply a synonym for “do”, often with a sense of cleverness or inventiveness, though at MIT that aspect was so taken for granted that it was rarely spoken. Not surprisingly at an engineering school, it was all about doing things, leading someone later on to coin the phrase “hackito ergo sum”—that is, presumably, “I hack [or do], therefore I am.”

Note: The New Hacker's Dictionary will describe the meaning of the term slightly differently, but not in what I think is a material way. Even so, since I lived through the era, I'm exercising my right to describe things as I perceived them directly and not to be burdened by references written by others.

In that era, which was still that of an older, non-public network called the ARPANET that preceded the public Internet, someone might routinely be heard to ask, as a simple greeting and with no intent to challenge, “what are you hacking?” It meant, literally, “what are you doing?” but really in a more figurative and non-confrontational way, as if the speaker had asked just “what's up?”

A hacker, then, was just someone capable of doing something, and the term was often used with great reverence as in a doer of great deeds. Our online profiles on one of the computers contained the fill-in-the-blank “Hacking task-name for supervisor” where you would fill in the task-name and the supervisor, where mine might have said “Hacking the time/space continuum for the future of mankind.” (We weren't always very good about putting in actual supervisor names.)

Of course, as these things go, the computer community got bigger and not all deeds done (not all hacks hacked) were good. After a while, there were people doing bad things, too. I was around when this happened generally, but did not witness whatever event it was that caused the sudden shift of the use of the name. I've only managed to piece together what I think must have happened.

I imagine that one day someone finally did something bad with computers, and someone from outside the community asked who had done it, my bet is that a terminological confusion resulted from someone responding “probably one of those hackers,” leading the listener to believe that the purpose of being a hacker was to do something destructive, perhaps with a machete, rather than that the purpose of being a a hacker was merely to do things and that some things one might do are good and some things one might do are bad.

I do know that it was around the time of the movie Wargames and that I was working at the MIT AI Lab as a programmer. I had gone out for a walk around Boston, as I often did in the afternoons then. I returned to the lab and a bunch of people rallied around me and said, “Kent, Kent, Ted Koppel called. He wants to interview a hacker about the movie Wargames. We said they should talk to you.” (To this day, I don't know why in such a community of much more talented folks than I, they picked me, especially since I wasn't to be found, but so it goes.) I tried to call back, but we couldn't get them on the phone. I later figured out they'd gotten someone from Carnegie-Mellon University (CMU) and so didn't need me any more. Ah, the chance for fame can be so fleeting.

But it was just as well because they were apparently operating under this new meaning of “hacker” and I would have been totally thrown by the questions they were asking, which seemed to presuppose that if I was a self-identified hacker, I was the sort who'd be breaking into computers or something. That wasn't what hackers I'd known did, and I didn't either. We had things to build. So they interviewed this guy from CMU. It was someone I knew of, I just don't now recall his name.

This is how we came to the belief they don't do those things live, because we saw he was logged in to his console in the interview and we all quickly scrambled during the broadcast (hackers came out at night, so we were all watching from the Lab) to try to send him a message (the equivalent of an instant message) hoping it would come out on his screen while he was on the air. But it didn't. Another chance at fame lost.

Fortunately for ABC News, this person seemed to know the new meaning of “hacker” and gave them a competent interview. But we were all saddened at the tarnishing such an important word had taken. It was part of our daily vocabulary and veritably wrenched from us for this stupid use.

There was an attempt by a number of hackers to get the media to use the term “crackers” instead, but it failed. And the term was essentially lost. From time to time, you'll still see someone of my generation refer to themselves as a “hacker (original meaning)” in some wistful attempt to reclaim the memory of a time when hacking was just doing.

The moniker “netsettler” that I use in some discussion forums (such as Slashdot) harkens to that era. I often feel an empathy, even if the experience is only metaphorically equivalent, with the displacement Native Americans must have felt when the modern world moved in and took their land. The net, and indeed the whole world, was such a different place before it was the Internet. Most people see the arrival of the Internet as the beginning of something, but some of us saw it also as the ending of something.

---

Author's Note: If you got value from this post, please “Share” it.

This article was originally published November 16, 2008 at Open Salon, where I wrote under my own name, Kent Pitman. A discussion thread is attached there which I did not port forward to here, but you can still read by clicking through to the version on the Internet Archive's “Wayback Machine.”

Tags (from Open Salon): hackito ergo sum, hackity-hack, hacks, hack, cracker, hacker, clever, programming, technical, prank, pacific tech, caltech, mit, history, linguistic evolution, linguistics, language, terminology, jargon