the trouble with anonymous gizmos
This post considers what the gizmo-naming insights from the first three posts in this series have to say about anonymous gizmos.
The first three posts built up my concept of the gizmo: some kind of automatic behavior attached to a free-form label. Many things fit under this umbrella, but I've focused mainly on functions, CSS classes, and tagged markup (like HTML).
My focus on functions took it for granted that functions have names, but many programmers use languages with anonymous functions like these:
I won't dwell on these, but I do want to answer the most obvious question:
Strictly speaking, you'll answer this question upstream from my recommendations.
Because my focus is re-use, my recommendations (use new names when you call a function for new reasons) are irrelevant to anonymous functions until you decide to DRY an unnamed function's code. When you commit to factoring it out into a named function, weigh whether each instance has the same purpose.
That said: just factor identical anonymous functions out and name them. The name(s) will clarify whether the functions do the same thing for the same or different reasons.
So far, this series referred to tagged/labeled markup languages like HTML, but now I'd like to turn to unlabeled markup. I imagine most readers will be familiar with Markdown--but I want to call out a few things about the following Markdown sample:
1- we love lists
3 _especially_ when they contain **3** paragraphs
5 > and a block quoted
7 > code block
- The markup elements are unlabeled.
- The automatic behavior associated with these unlabeled gizmos is triggered by symbols and whitespace.
It's not present in the example itself, but I also want to note that the lack of free-form labels:
- Leaves us no way to distinguish different reasons for using the same presentation, hampering our ability to translate into formats with distinct markup for each reason.
- Focuses authors on presentation, making it more likely that they'll mix reasons.
Bridging anonymous functions and unlabled (~lightweight) markup makes it clear that they have more or less the same value and problems. As with anonymous functions, unlabeled markup formats prioritize authoring speed over future re-use. That'll be a good trade for many uses--but not always.
This is an attack on most unlabeled lightweight markup languages (well, on using them as source languages)--but it's a narrow one. They are convenient! (I'm writing this post in Markdown!)
Much as anonymous functions are fine when you don't need labeled functions for re-use, unlabeled LWMLs such as Markdown and AsciiDoc are fine if you don't need to translate to more-functional formats. It's important to understand where our technical choices begin to creak.
Over the course of this series, I've tried to sketch out some big ideas about how to practice ~namescaping, but here's the pocket-reference version:
- Name your gizmos to reflect why you're using them.
- Prefer languages that make this easier.
I stumbled onto the core ideas in this series while wrestling with how to write about some tools I've been working on for documentation single-sourcing. More specifically--for generating multiple heterogeneous , idiomatic documentation outputs from a single source corpus.
Stay tuned if you found any of this interesting. The journey has been fruitful so far, and I imagine I'll make several more posts building on these ideas in the coming months. In particular:
- At least one post on the 8-letter S word that I've left out of this series.
- A series on where and how separation of concerns goes awry in the HTML/CSS ecosystem, including why almost everyone gets this wrong.
- One or more posts on how templating toolchains aren't up to the task of handling source and output formats with very different whitespace requirements.
- A few puff pieces on fun/quirky little languages I stumbled on while looking to see if I could avoid reinventing a wheel.
- And, finally, one or more posts on what I've made.