Neil Mix

I’ve always thought that there’s a convenient symmetry between generators and Erlang-style processes. So it’s neat to see that Alex Graveley has been exploring Erlang-style “concurrency” in JavaScript by piggy-backing off my generator based “threading” library.

I sometimes wonder what it would take to expand JavaScript generators to become truly concurrent. Maybe something as simple as a “start” method on a generator object:

function myConcurrent(param) {
  yield wasteTime(param);
}

let gen = myConcurrent(someValue);
gen.start();
let result = wasteMoreTime();
result += gen.next();
gen.close();

where start() causes the generator to begin execution concurrently, and next() or send() act like a thread join.

It’s such a small but powerful extension. It seems appealing up-front, but the devil is in the details. What’s the memory model? Much of Erlang’s appeal stems from its shared-nothing semantics. How would you replicate that with JS generators? Enforce pass-by-value? If next() and send() join, then how exactly do we get the Erlang-style message passing going?

Or maybe there’s no enforcement of shared nothing and caveat emptor? But then you need synchronization for shared objects. Blech.

An interesting thought experiment. To be clear, there’s no talk of anything like this (AFAIK) amongst the JavaScript language designers. Just a random Friday daydream.

If it’s a good idea, go ahead and do it. It is much easier to apologize than it is to get permission.

- Admiral Grace Hopper

Auto-updating software is neat. It saves the customer from painful manual updates, and it helps the vendor by keeping people up-to-date with their software.

Unfortunately, the auto-update feature got off to a bad start in UI. Due to mindless follow-the-leader mentality, it’s had a hard time recovering ever since.

Case in point:

While this is an extreme case, it also illustrates a problem that we’ve all had with auto updates, namely how they manage to interrupt at the most inopportune times.

The problem boils down to 2 factors: a) permission, and b) timing. A little forethought solves both problems fairly easily, but bad precedent of previous implementations casts a long shadow.

Programmers often get snagged on the concept of permission. The (non-conscious) line of thought is: we wouldn’t want to disappoint someone, so let’s make sure it’s OK before we proceed. What’s missing is opportunity cost: people like having their chores done for them. By thinking that doing-without-consent is risky, we miss the opportunity to make the customer to be pleased as punch that someone is quietly getting-things-done for them.

Early on in the history of software auto-updates, someone decided that it was very important to interrupt the customer to make sure that they don’t object to having their software updated. Early versions of auto-updates went something like this:

• start the app
• app says, “Updates to your software may be available. Would you like me to go check?”

First off, how lazy! This comes straight from the playbook of how to ruin your career: when a simple but helpful task needs doing, check with your manager before doing anything. He or she will be impressed with the amount of reassurance and micro-management you require.

At some point someone realized, “hey, that’s kind of annoying.” And thus the auto-update question was no longer asked on startup, but instead asked at some random time on some random interval — but the same time and interval each time, so as not to be confusing.

Did you see the bait-and-switch? The problem was with asking too much permission. But “fix” was to change the timing. I quoted the word “fix” because the solution didn’t improve things much. We went from an annoying every-time-I-start-the-app question to an annoying randomly-interrupt-me-in-the-middle-of-my-workday question.

After a while, someone made the startling realization, “hey, we could check for updates automatically!” No doubt someone objected that permission should be asked first, but thankfully the objections were overridden. So now we have: randomly-interrupt-me-when-updates-are-available. Which is better. And this is pretty much state-of-the-art for auto-updates these days.

But we’re not quite there yet, are we?

So what to do?

1. Just grab the update already! Beg forgiveness rather than ask permission.
2. Don’t interrupt me while I’m working! Wait until the next time the app is started, then perform the update and let your customer know what you’ve changed.

So now we’re at: annoying-interruption-on-startup-only-when-updates-have-been-made. But how annoying is the interruption, really? Presumably you’ve got great new features for your customer that they’ll be happy to hear about. Perhaps rather than being annoyed, your customers will feel pleasantly surprised by the gift of new features they’ve received this morning. Your software just made their lives easier, on multiple levels.

Still sound too aggressive, too risky? Consider this: there’s already strong precedent for the auto-update process I described, just not on the desktop. It’s on the web. Websites don’t ask permission before updating the software. (They can’t, really.) In some cases, when the updates are really big, they might let you know about the changes your first time in. (And occasionally they may provide a graceful “downgrade” to the old version if you protest.)

But most of us never really noticed this subtle distinction between desktop and web auto-updates. That’s because we’re too sympathetic to the underlying technology. But when we wipe the technical details away (as we should when designing our UIs), the truly-auto-update isn’t so scary after all, now is it?

Here’s a little something I’ve seen around the web a few times:

What does this mean to you? What pictures form in your head when you see this?

Now before anyone accuses me of being naughty, I can assure you that this is a Safe-For-Work post. The story behind this image is hardly controversial.

If the phrase “rollover for more” seems perfectly innocuous to you, stop for a moment and consider how your grandmother would react if you told her to “rollover for more.” Mmmmmaybe you aught to find a way to reword this.