Re: Jargon [<- Re: On the "Darwinian Theory of Legal Obfuscation"]

[Mike Newhall <address@hidden>]

>I think the prefered solution is to employ user modeling and let peopple choose which notation system works best for them. Then you can serve up a circumlocution to an end user *and* tell him or her what the correct "term of art" is.

	Jargon usually orginates in a very small context, a narrow headwater, with an individual researcher coining a term for a concept discovered in the course of research, or engineers coining a pragmatic term for a concept encountered in the course of building something.  These circumstances are not amenable to an orchestrated user modeling project to pick the best terms -- the terms are tangential to the central, and much more important, project; in general no-one has the time or resources to embark on such a project.  Other jargon terms precipitate out of the aether from decentralized social interaction, and certainly in those scenarios there's no-one to orchestrate anything.

	More to the heart of the matter, I think the idea of a group choosing their "own" terms is missing the point of having terms.  Words are for communication, so that when one talks to a colleague or another person in the field at a conference, or reads an article or paper or book, the same terms will be used consistently to describe the same concepts.  I don't think the obscurity of continuations would be helped by trifurcating the word into three separate ones.

>
>There is no reason why a block of code can't be mapped to more than one surface structure, S-expressions for Scheme folks, C type definitions for others, and semi-verbose English for End Users just getting their feet wet with high level application scripting.


	I agree that multiple code views are a good thing, but that is something for automated tools like program editors, and won't help in human conversations or communication, as noted above.  Also there is more to the difference between different languages than simple string transformations; how do you represent recursive types in C syntax?  Scheme macros?  Closures and continuations?  I would submit that learning Scheme syntax and looking at the original code in its native language and as written by the original author is a surer path to understanding the code than trying to decipher it auto-mapped to a less capable and more verbose syntax.

	As an aside verbosity is actually often a hindrance to understanding: it creates a smaller window onto the framework of the program, and creates more syntactic objects for the mind to parse for the same concept.  As seen in another thread on this list, verbose languages can befuddle even experienced programmers; COBOL was infamous for these effects.