Comment by kqr | Hacker News Reader

Comment by kqr | Hacker News Reader

Parent Full thread

TFA is based on a false dichotomy. You can have both.

At one of my latest workplaces, there was a system of loosely connected, branching event-driven processing nodes where the events accumulated additional data as they rippled through the system.

In the code and UI, this was represented as "heroes", coming from "guilds", "embarking" on "quests", eventually meeting their "reaper". On their quests, they entered "locations" containing "pickpockets" that pulled things out of (and put things back into) the hero's "inventory".

This cute-but-descriptive vocabulary really helped less technical people grasp how it all fit together -- even if it was a complete lie and gave the wrong picture of how the system worked under the hood.

(In particular, it is a common misconception that the heroes are driving the action by choosing locations to go to, when in fact it is the locations (processing nodes) that pull heroes (event data) along. But that misunderstanding never caused a problem in the four-ish years I worked with the system.)

Brew tries this:

You write software formulas (packaging scripts) into bottles (binary packages) in your Cellar (installed packages directory). Some software, such as GUI applications, uses casks, because casks are a different type of container. If you want a new source of packages, you add a tap.

I would take packages, packaging scripts, package repository, binary packages and GUI packages any day over brew's attempt at cutesy terminology.

I think there could be a difference here: you're already familiar with the domain brew operates in.

The system I'm speaking of were extensively used and configured by people who had no prior experience with event-driven, branching logic, nor any familiarity with the terms involved.

You can still argue it would have been more efficient to teach them that domain first, then teach them this particular system for it. Maybe. I'm saying as far as I can tell, there was no drawback to the cutesy terminology for the intended users (nor for developers other than in isolated cases) and it seems to me they learned quicker with that framing than without it.

I'm not sure assuming people are familiar with the process of alchohol brewing is any better.

I agree -- that's exactly what I was saying. The target audience of brew is more likely to be familiar with package management than alcohol brewing, so the choice of terminology was poor. On the other hand, the target audience of the system I was discussing is more likely to be familiar with a fantasy-like narrative than an event loop, so the choice of terminology was beneficial.

This describes absolutely nothing to me. It just confuses and excludes me. Then if and when I understand what it means I then have constantly translate mentally between the cute-yet-infuriating names and their actual meaning in the context.

Along similar lines, we had a hell of a time getting various product people to understand template strings for translations. Eventually I got the idea to just call them "madlibs" and all of them understood it immediately.

This is a great anecdote. I'm firmly on the "call things what they are" side of this debate, but this example shows a thorough domain design that was cleverly shifted to a narrative format. Impressive.

Great idea!

Reply on news.ycombinator.com