Well, I think Wittgenstein’s ladder is a useful way to defuse the naming‑conventions debate without pretending it has one universal winner.
In Tractatus 6.54, the ladder is a means of ascent, not a permanent part of the structure: you use it to get to a clearer view, and then you can (and should) throw it away once it has done its job. Applied here:
- For many people, early in their Tinderbox learning curve, prefixes like
p_,t_,f_can function as a ladder: a quick, low-friction way to keep infrastructure notes legible (“this is a Prototype”, “this is a Template”) before their internal model of Tinderbox’s built-in semantics (containers, prototypes, attributes, badges, outline context) is stable. - The danger is when a ladder becomes a doctrine. If we present prefixes as the best practice, we risk hardening a temporary aid into a permanent constraint, and we get the social backlash we saw (“Hungarian notation”, “nerdy turnoff”, “misdirection”, etc.).
- Conversely, if we insist on “purist” tool-immanent semantics from day one, we can also alienate people who need something that works immediately, even if it’s not the most elegant long-term mechanism.
So the emergent “best practice” might be stated in a Wittgenstein-friendly way:
Use naming conventions as scaffolding to reduce confusion until the document’s structure and Tinderbox’s native context cues do the work for you. Then be willing to refactor: keep the ladder only if it still pays rent.
That also ties back to “Begin With the End in Mind”: the end is not “I will always use prefixes”, but “I want my infrastructure to remain findable and unambiguous as the file grows.” Prefixes are one possible ladder toward that end, not the end itself.
In other words: the real advice is not “prefix everything” vs “never prefix”, but “recognize when you’re using a ladder, and don’t confuse the ladder with the building.”
Dave — thank you, and thanks to the whole community, for projects like the Hitchhiker’s Guide and for the meetup and forum discussions around it, which keep giving us substantial material and a recurring occasion to sharpen our thinking by working together on topics that can easily look “pretentious,” like best practices.
Because when we do our thinking openly, on stage, it becomes real work rather than drifting into a private language that only its inventor could understand — and therefore, in the end, no one.
In other words: the best practice is to craft a solution that works for us, while remaining at least plausible — and ideally genuinely usable and extensible — for others. Learning and using that shared lingua franca, in public rather than in private idiolects, is the spirit you’re starting to distill so invitingly with this Guide.
My thumbs‑up is both recognition and a request: let me travel along for a while.
Thank you.