Ironically the acronym often becomes the name. Everybody knows what NASA is. What the CIA is. But people have to think to figure out what the real name is. Take ICE. I'll bet that half the people don't even know what the actual name of the ICE organization is. A long name, particularly with lots of words in it is like many objects, not one object. Did you know that "grep" is an acronym for "globally_search_a_regular_expression_and_print"? A non-unix person could understand the full self-documenting name but not the acronym. But one would still be in the dark as it didn't say what a "regular_expression" is. And I don't think I would want to type all that whenever I did a search, even with auto completion. Intelligent acronyms are fine when are commonly used. Long names built by compilers to assure uniqueness are awful.
As to tacit. Which is easier to read? range =: (>./ numbers) - (<./ numbers) range =: (>./ - <./) numbers Actually it depends on the reader's background. For me the second line the use of a tacit fragment makes it easier to read as "numbers" is one object, not two. And the fragment is easy to read knowing the definition of a fork. Self-documenting code makes me nervous because it is inadequate. It misses references to company documents, legal issues and technical papers describing algorithms. It misses the "why". Documentation and naming conventions are necessary but not easy to do properly. But a programming language should not define and enforce standards for documentation and naming conventions. Leave that up to the company or individual. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm