This page is dual to "Effective ways to request help with Tcl-related problems". The contributors to comp.lang.tcl (c.l.t) generally are exceptionally helpful and well-meaning. At the same time, they share a great depth of common understanding which occasionally presents surprises to petitioning newcomers. If you have posted a question to c.l.t, keep these possibilities in mind when reading follow-ups:
Follow-ups often respond to questions with more questions. This is well-meaning, not an attempt at cuteness or condescension. Gathering pertinent information is one of the best ways we know to help. Kevin Kenny writes at length [L1 ] on this, and introduces an appropriate philosophy of debugging. [...]
Answers are often in a dialect peculiar to c.l.t. Again, there's no deliberate attempt to exclude; it's simply that many posters misjudge how much they have in common with readers. If advice to "check the Wiki" or "listify" perplex you, just say so. Regulars treat the newsgroup more as a collection of conversations, at their best when extended over several volleys, rather than as a delphic tome. One crucial survival skill you'll want to learn early in your programming life, though, is to "Google". If a term mystifies you, ask Google [...] about it. This often is more rewarding than cycling glossary enquiries through the newsgroup.
Some posters appear to expect this sort of interaction: they post a description of desired software, and someone follows up with a finished solution. They're likely to be disappointed. While this occasionally happens, it's not a particular strength of c.l.t. Far closer to the center of the local ethos are brief, even gnomic, explanations of what the helper speculates is the crucial idea of a correct solution. Bruce Hartweg once explained a particular instance of this: "That basic suggestion was to introduce you to the toplevel command and the -command options on buttons. To get your full program going you need to do a little more work. In general read the documentation and poke around on https://wiki.tcl-lang.org to get many good ideas/examples."
Some answers are of the form, "You don't really want that." Most often, these are accurate, however abrupt they might seem to newcomers. Programmers with deep experience recognize common errors [...], and recognize times when it's a greater favor to help someone realize he deserves a new destination, than to direct him or her into a swamp. There are several varieties of this answer, including "That book is four years old, and that particular recommendation is no longer a best practice", "studies have shown that the technique you describe confuses end-users", and so on.
LV: I'm confused about the relationship between bbh's remarks, which are useful and the title of this page.
Still, Larry?