mel@houxm.UUCP (08/31/83)
"Consistency across all commands" ? When has that ever been tried ?
Is that important ? What a wierd idea. Shouldn't discussions like that
go on net.jokes ? It sure doesn't belong on a UNIX or TOPS-20 system.
(Consistency is the sign of an undeveloped imagination.)
Mel Haas , houxm!mel wex@ittvax.UUCP (Alan Wexelblat) (08/31/83)
Or, to quote Oscar Wilde: "Consistency is the hobgoblin of small minds." Which brings me to an interesting question: To what extent do you think that application programs ought to be consistent? I can think of arguments both pro and con, but I'm curious what others have to say. --Alan Wexelblat (until 9/2: decvax!ittvax!wex) (after 9/12: ucbvax!wex.UPenn@UDel-Relay)
mcg@shark.UUCP (Steven McGeady) (09/02/83)
"I contradict myself? So I contradict myself! I contain multitudes." The trouble is, many users contain somewhat less than a multitude.
mark@umcp-cs.UUCP (09/02/83)
There are lots of kinds of consistency. The most important thing
application programs ought to be consistent with is the application.
This means using concepts and methods already familiar to
the domain expert. This most likely means that application
programs for different areas will be inconsistent with one
another.
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@UDel-Relaygsp@ulysses.UUCP (09/02/83)
There are many aspects of "consistency" and I think they can be discussed separately, and perhaps should be. Here is a common problem of consistency for which there is no solution, but I can tell you the tradeoffs. It involves consistency in language design, their syntax and primitives. Suppose you want to design a language for application X. You go out and do a good job and people love it so much they ask for it to work on application Y. If you tuned language X to application X so that it was wonderful for doing X, you may find it does not generalize well to other domains. On the other hand, you may have designed language X so that generalization to other applications is easy. In that case, you may find that the language does not serve people well in application X. A common example is the specialization of programming languages. LISP is tuned to symbolic actions on lists, SNOBOL to string patterns and their manipulation, and so on. Applications based on some of these, maybe a semantic network language based in LISP, are even more finely tuned to a specific application. This is not without a cost, though. Once a language is tuned to one application, it loses applicability to others. (This is not literally true. LISP when extended in one direction maintains its basic functions and hence their capabilities. This is an advantage of extended languages over languages built from token one.) Languages that provide everything for everyone can be baroque and difficult to learn as well as implement. Simple languages that provide the means for extension seem to be the best alternative, though implementing them can be difficult (but don't forsake great tools like m4 (especially the newer BTL version) that offer such capabilities to many applications). LISP is such a language, as is C. In such languages, libraries (extensions) are bound to crop up. (I wish they did more often.) The tradeoff can be summarized: A GOOD ARTIFICIAL LANGUAGE SPECIALIZES IN ONE DOMAIN AT A COST OF GENERALITY TO OTHERS. A corollary is that a good language is inconsistent with others; almost a paradox. These issues: tradeoffs in language design, consistency, and artificial languages, are discussed in more detail in my paper Natural Artificial Languages: Low Level Processes that should appear sometime soon in the IJMMS. Preprints are available from me. Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp
nather@utastro.UUCP (09/02/83)
Consistency is a virtue of the small mind.
mason@utcsrgv.UUCP (Dave Mason) (09/05/83)
Consistency is for Overloaded Minds. (Be they small, or be the load large)