Latests Drafts of The Hitchhiker's Guide to Tinderbox

I think we’ve covered this ground before, and it’s been sufficiently caveated in the text.

I disagree that we are presenting these ideas as “implicit rules.”

I believe that thinking about names can be useful. I believe there have been a few productive practices developed by experienced and talented Tinderbox users that are worth mentioning/sharing, rather than simply allowing or expecting the less experienced user to stumble upon their own solutions when they encounter the challenges that others have already met. Otherwise, what am I even doing here?

I shall add additional front matter to the entire document to point out that it’s the typical software warranty, it’s of no particular value, it may not do what it purports to do, and I’m not responsible for anyone wasting their time reading it. I think that should sufficiently cover our asses.

This is a very new project, and right now I think it’s best viewed inside Tinderbox. You can read the guide in the Tinderbox demo, though you’ll need Tinderbox to extend it.

If you have questions about Tinderbox, this forum is a great place to ask them!

Software developers face this problem all the time when that are writing code — how to name things and how to describe things using comments. The challenge is not in coming up with names or descriptions, but coming up with names and descriptions that are meaningful in the current and future contexts. The current context is ephemeral and starts to decay once we switch to another context (I.e., writing some other program. Given enough time that current context becomes a completely new context for the next person (even if that person is you). While your intent was obvious when you wrote the code is — more often than not — not at all obvious in the future. We have this very same problem in Tinderbox.

2 Likes