42 Astounding Scripts

Make sure Script Menu is enabled in Script Editor.

I am an information packrat; I never throw out emails, and have messages dating back to the last century. I manage this using hierarchical mailboxes to keep the archives from cluttering up my Mail window.

I have Rules set up to send various messages directly to the mailbox where they should be stored, and then Smart Mailboxes to display unread messages of various classifications: Unread Mail, Unread Mass Mails, Unread Spammy, and Unread Junk, each less critical than the previous.

In the past, it’s been easy enough to see where any message is stored. The macOS Mail app has acted like any other application on the Mac: documents (i.e., messages) could display the full path to the document by option-clicking the document’s title (i.e., the message’s subject) in the window’s title bar.

As far as I can tell, this is no longer possible. Mail has been moving away from a document-based model toward a flat, search-based model, and no longer makes it easy—or even possible—to find the full path to a viewed message. The immediate parent mailbox’s name is displayed in the sidebar, but the mailbox’s parent is nowhere to be found. So that I can see easily enough that the order I’m waiting on is in the eBay mailbox. But not that the eBay mailbox is in the Purchases mailbox of the Finances mailbox. The latter two are completely hidden.

Obviously, however, the Mail app itself knows where these messages are, and that information can be displayed using AppleScript.

All this for a script that will be used no more than a handful of times, to restore long-replaced data from the nineties. It’s time to quote Douglas Adams again.

I have a well-deserved reputation for being something of a gadget freak, and am rarely happier than when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand. Ten seconds, I tell myself, is ten seconds. Time is valuable and ten seconds’ worth of it is well worth the investment of a day’s happy activity working out a way of saving it. — Douglas Adams (Last Chance to See)

In A HyperCard Time Machine I wrote that I also seriously considered writing the script as a JavaScript (JXA) app. In fact, I did write the script as a JavaScript app. It was a toss-up to the end which version I was going to use, so they’re both fully-working versions.

One advantage the JXA version has is not requiring old-school, BASIC-style manipulation of strings to extract the current card number and the total card count from the window title. Instead of grabbing the location of the final slash, which required serious gymnastics in AppleScript, the JavaScript solution can use a regular expression that is both shorter and more reliable:

JXA also doesn’t use tell blocks. It places the application in a variable, and the things we want to tell it to do can be handled at any point without worrying about how a tell block affects the syntax. At the beginning of the app, I did:

This gave me the current application and System Events. The current application is necessary for dialog with the user, which is why I’ve also included the Standard Additions on it. The Standard Additions include Display Dialog and Choose Folder.

This was a tool for an early role-playing game. And looks it.

My second programming job out of college started as a HyperCard stack. HyperCard was an amazing tool not just for programmers, however, but especially for the weekend programmer or even the weekend non-programmer. It didn’t require any programming to get started. Just put some text placeholders on a background card, some buttons, maybe add a pre-created action to a button such as “move to next card”, and you had a very simple visually-oriented application that responded in a manner customized for you and your data.

There were a lot of non-programmers who used HyperCard and graduated to weekend programming. Because after you wrote your text or placed your graphics or added a button with a standard action, if you wanted to add code to that object, you could. You might start with slinging messages from object to object, or performing simple math on one of the text placeholders.

HyperTalk was not object-oriented in the sense that programmers mean when they talk about object-oriented programming. But it was object-oriented in the sense that programmers explain object-oriented programming to non-programmers. Every object on the screen could contain code that responded to specific actions. Each card could respond to keystrokes. A text box could respond to typing. Cards, text boxes, buttons, and images could respond to mouse actions. Keystrokes, mouse actions, and custom functions were all messages. And each object could send messages to other objects.

HyperCard was often used for databases; the card metaphor was especially apt for that. For example, I had a database of superheroes and supervillains in the Men & Supermen superhero role-playing game.

The game used meters, but clicking on the word “Height” on the character sheet would calculate and then display the character’s height in feet and inches:

I’m dividing my promised sequel to Future Snark into three parts, one each for three very smart views of a future that became our present. These are the anti-snark to that installment’s snark: Vannevar Bush (1945), Norbert Wiener (1954), and John G. Kemeny (1972). I was going to title it “Snark and Anti-Snark” to extend the Toffler joke further than it ought to go. But these installments are not snark about failed predictions. These are futurists whose predictions were accompanied by important insights into the nature of man and computer, what computerization and computerized communications mean for our culture, and what responsibilities we have as consumers and citizens within a computerized and networked society.

These authors understood the relationship between man and computer, before the personal computer existed. Their predictions were sometimes strange, but their vision of how that relationship should be handled embodied important truths we must not forget. Their views of our cybernetic future focus heavily on not just the interaction between user and machine but on the relationship between computerization and humanity in general.

Surviving the ongoing computer and communications revolution requires understanding that relationship.

I’m going to handle these authors in reverse order, starting with John G. Kemeny. Kemeny published Man and the Computer in 1972. If Kemeny’s name sounds familiar, you might recognize “Kemeny and Kurtz” as the developers of the BASIC programming language. Much of this book, while it wasn’t designed as such, is an explanation of why BASIC is what it is—a unique programming language unmatched even today as an interactive dialogue between the user and the computer. Unlike most programming languages—including BASIC itself on modern computers—Kemeny’s BASIC didn’t require creating programs in order to get the computer to do stuff. The same commands that could be entered into a computer program could be typed directly to the computer with an immediate response.