🚀 go-pugleaf

In article <10558@yunexus.UUCP>, oz@yunexus.UUCP (Ozan Yigit) writes:
| In article <3136@kim> kim@spock (Kim Letkeman) writes:
| >In article <10278@yunexus.UUCP>, oz@yunexus.UUCP (Ozan Yigit) writes:
| >| In article <1990Apr24.132052.8149@talos.pm.com> kyle@cs.odu.edu writes:
| >| >I disagree.  Configurability has to take into account users'
| >| >preferences, yes, but at some point the programmer has to say
| >| >``no'' to keep the user from cutting his own throat.
| >| 
| >| Where do you draw the line ?? ... [rest omitted]
| 
| >Hmmm ... must be "pot shots at Kyle" week.
| 
| This discussion is not related to any personality whatsoever. I had
| not even noticed his name until you mentioned it.

Perhaps noting the name of the author would help explain the reasoning
behind the original article, which might make for a more enlightened
response. For example, noting that Kyle was the author should bring to
mind the VM mail system, which he authored. One would then weigh his
arguments against the style used in that package, which is excellent
incidently. 

You are correct that the discussion did not relate to a personality,
but your article was the second in as many days to contain a veiled
flame of something he had posted. Sorry for reacting, I should have
ignored it.

| >All I understood Kyle to be saying was that he felt that there were
| >valid situations where the programmer might choose to use yes_or_no
| >instead of y_or_n ...
| 
| You misunderstood. 

I don't think so.

| Kyle suggests that there is a point at which the programmer should
| "stop" configurability, and make fixed (and perhaps arbitrary)
| decision as to what is "good" for that user. I merely inquired what
| that point (or dividing line if you wish) is.

A very uncharitable and biased interpretation. Kyle made it fairly
clear that he felt that there was a place where the designer of a
function might consider protecting the unsophisticated user from
catastrophy, rather than allowing a risky command to be easily
triggered by type ahead. This is hardly an arbitrary decision.

It has been demonstrated by a number of postings since then that it is
easy to change this default situation to a more relaxed and less
secure one.

The dividing line is obviously a personal choice. Such factors as "how
many false bug reports do I want to deal with?" enter into the
decision. For example, if Kyle used y_or_n_p everywhere, someone would
inevitably call him saying "I was using VM and all of a sudden a whole
folder disappeared." Easy to do accidently when typing quickly ... and
it only takes one report like this to establish a reputation for
unreliability. 

| [I spoke of "extensibility". Elsewhere, Kyle suggests that it is not the
| same thing as "configurability". The difference is subtle, but for most
| anything out there that is genuinely considered "configurable" or
| "extensible" the difference is all but moot.]

Quite the opposite. Many UNIX utilities and programs allow
configuration of their default behaviour via the traditional dot file
(e.g. .newsrc, .mailrc, .bobsyourunclerc.)  Almost none allow
extensibility, which implies added functionality such as that provided
by gnu emacs and to some extent all emacs implementations.

Configuring a program to operate a certain way is hardly the same as
extending it by adding new functionality. Webster agrees.

| >Much of software should be designed for a specific purpose and tightly
| >coded and then left alone.
| 
| Ok, if you say so. :-)

Hmmm ...

| >Quibbling over "how extensible" something should be is a waste of
| >time. It is possible to change the source code.
| 
| No, not quibble, but discuss: It certainly is not a waste of time,
| especially not when it is hip to throw around "extensibility" (some
| call them macros :-) as if it is be-all-end-all solution to
| everything.

This appears to be a point of religion. I read this newsgroup every
day and haven't received the same message.  People certainly acclaim
highly the extensibility of editors like gnu emacs, but then why
shouldn't they? Have you tried vm, rnews or jnews, emerge or any of
the other extensions to emacs lately? They make real life much easier
and they are there because gnu is extensible and someone extended it.

| I think extensibility (or configurability) without resorting to the
| source-code mods must have some some framework to operate within.
| That's where the decisions like "well, I do not think the extender
| (user?) should be able to do such-and-such (like bypass y-or-no)"
| are made. Now, the next thing to ask is *how* the programmer came up
| with that framework, and *why* did he/she make those seemingly
| arbitrary choices.

This is rather an arbitrary interpretation of the original posting.
Kyle's choice (for example) was merely the default behaviour. The
beauty of an extensible editor like emacs is that Kyle cannot make the
decision that "we users should not be able to do such and such." We
can do it anyway if we want to. The software designer can, however,
influence the default behaviour. Which is what we want.

| As to modifying the source code, that is the absurt :-) part [for
| any number of very realistic reasons, arguably including the
| readability and or modifiability of said source ;-)].

We shouldn't modify the source because that would affect
modifiability. A bit circular ...

There is nothing absurd about extending or changing GNU's behaviour by
modifying the lisp source (or even the C source for the more
adventurous.) Many people do it every day, and the rich functionality
available to the user of gnu emacs is a testament to the value of its
extensibility.





-- 
Kim Letkeman    uunet!mitel!spock!kim