Language design / Usefulness / microarticle
Tools Should Understand the Work
Why build a tiny language? To put the expertise of a craft into the tool.
Microarticle. The argument in outline: familiar words, shared context, intelligent defaults and useful checks can reduce the distance between knowing what you want and getting it done.
01 / Expertise is already compressed into language
“Skinny caramel latte.” A few words carry an order because customer and barista share the context. Crafts have their own versions: a panel, a shot, a character level, a trust boundary.
Start by finding out what practitioners mean, what they leave unsaid, and which distinctions matter. The working language is evidence of the expertise.
02 / Stop making people explain the obvious
A tool should use the vocabulary of the work and carry the context forward. Re-entering the same facts, reconstructing known relationships and spelling out routine choices consumes effort without necessarily improving the result.
The aim: say what matters, refine what differs, and let the tool remember the rest.
03 / Defaults are a place to put knowledge
Intelligent defaults encode the ordinary case. Scoped defaults let a particular scene, room or situation refine it. Explicit choices remain available when the ordinary case is wrong.
My role-playing example: ask for the 9th-level fighter you need, then backfill the decisions. A tool should support the shortcuts expertise makes possible.
04 / Check the things the craft cares about
A useful check understands a meaningful relationship. Does this character exist in the reference Bible? Is the location declared? Does the page contain the number of panels its layout specifies?
GraphicNovel already checks consistency in its class. Catching a defined inconsistency during compilation can bring a question forward, before it becomes a correction shared between writer, artist and letterer.
05 / Keep the source recognisable
The source is part of the work. Practitioners should be able to read it, discuss it and change it in terms they recognise.
TeX supplied the early lesson: computerise the terms of a craft and its practitioners can still understand the code with very little relearning. Readability is a practical benefit.
06 / Let one description do more work
Once meaning has structure, a tool can check it and produce useful views of it. GraphicNovel provides script output and a printed reference Bible. Other languages may support diagrams, tables or further outputs where those serve the craft.
The principle is to avoid maintaining several competing descriptions of the same thing.
07 / The tool carries knowledge; the practitioner exercises judgement
Put repeatable rules, named distinctions and routine bookkeeping into the tool. Keep the decisions that require judgement visible to the person doing the work.
A consistency checker can identify a broken reference. Deciding whether a scene works, an adventure is enjoyable or a threat model is adequate still requires expertise.
08 / Make the language earn its keep
A tiny language is useful where recurring work has a vocabulary, repeated decisions and relationships worth checking. It also brings design, learning and maintenance costs. Those costs need to buy something.
The test is practical: less repetitive input, sensible defaults, meaningful checks, readable source and more attention available for the craft. That is why we do it.