🚀 go-pugleaf

In article <10765@yunexus.UUCP>, oz@yunexus.UUCP (Ozan Yigit) writes:
| In article <3234@kim> kim@spock (Kim Letkeman) writes:
| >In article <10558@yunexus.UUCP>, oz@yunexus.UUCP (Ozan Yigit) writes:
| 
| >Perhaps noting the name of the author would help explain the reasoning
| >behind the original article, which might make for a more enlightened
| >response.
| 
| Should other posters like myself expect such a gracious reception
| as well?

Well, you did pick the most negative possible interpretation, but I
suppose I shouldn't be surprised. I apologize if you took offense,
none was intended. I simply meant that it is useful to take into
account peripheral issues (such as a person's track record - e.g.
Kyle's VM mail package) when dissecting an opinion or position.

| >| 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. 
| 
| You are mistaken.

Does three words a refutation make? Why am I mistaken? I consider it
uncharitable to use language like "he wants to STOP configurability
and he is making ARBITRARY decisions." 

| >... 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 *exactly* where the problem is.
| 
| It is one thing to provide safety-features as a possible solution against
| presumed human failings under certain circumstances. It is totally another
| thing to suggest/imply that those features are necessarily correct,
| sufficient, or even required without appropriate justification.

As a satisfied user of VM, I don't see that Kyle made any decisions
that I would consider arbitrary in the design. I think this supports
my interpretation of his original statements as non-sinister. He is
not trying to control the users of his software, but is merely trying
to apply common sense.

| Tell me: what exactly *is* an unsophisticated user? [by implication, you
| *are* sophisticated right?] Unsophisticated in relation to what? Typing?

A rather negative interpretation. I am using unsophisticated as in a
fairly typical user of emacs. Meaning someone who does not hack in
lisp. I am not rendering opinions on their level of cultural
sophistication as should have been obvious from the context. The
original subject basically revolved aroung extensibility, lisp and GNU
emacs, so I am trying to remain in that arena to avoid clouding the
issues too much.

A typical user of emacs could be typing ahead and could easily delete
a buffer or destroy a data file if the designer of the feature or mode
in use allowed single characters as responses to important questions
such as "are you sure?"

Again, nothing sinister ... just common sense. A "sophisticated" user
(by my earlier definition) would know how to turn this off were that
desired. But that user would also know and understand the risk and
would be more careful during risky sequences.

| Un*x?  Editors? Computers in general? Does "unsophisticated" mean
| "stupid"?  By the way, what is a catastrophic command? One that
| cannot be undone? Why

Obviously unsophisticated does not mean stupid. It is easy to imagine
that some users of emacs are not interested in learning the ins and
outs of extending the editor and are therefore always a bit unsure as
to exactly what is going on internally. It is for their benefit that
these subjective decisions are often made.

Any command that would cause the user regret were the wrong choice
made could be defined as catastrophic under the terms of this
discussion.

| can't it be undone? Is that a theoretical or provably practical
| necessity or bad design? How catastrophic should the commands be?
| Are they necessary?

Again ... all pretty subjective. They are necessary if they can cause
problems for the unsuspecting user.

| Yup, it is nice to talk about "unsophisticated users" and "risky
| commands" and "catastrophies". "Designer" indeed.

When I design lisp code for the local user community, I simply do what
makes sense. I don't try to control them, but I also don't assume that
they have spent any time learning the internals. So I have to make
some decisions.

| >The dividing line is obviously a personal choice.
| 
| Is that so. Do you think the programmers working on the next release of
| WordPerfect (for example) make "obviously" personal choices? Would you
| like to ask them?

Wordperfect is a complete software package that is not user-supported
nor particularly extensible.  I suspect that there is quite a formal
design process for making the decisions we have been discussing. I
don't see any connection at all with this discussion.

| >Configuring a program to operate a certain way is hardly the same as
| >extending it by adding new functionality. Webster agrees.
| 
| Is that Webster's Intro to Computer Science?? Wrong book. :-). Try
| something on automata theory.

Sarcasm again. We were discussing the meaning of configure versus
extend. Look it up. It applies to this discussion. No computer science
needed for this one.

| >| 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.
| 
| So ?? My point was far more general than just emacs, and I expected the
| reader to think of other "extensible" editors, window managers, word
| processors, directory browsers, hypertalk, awl, tcl, ad nausiam. Actually,

These statements are too sweeping and general and cover too much
territory to be debated. If you want to cloud the issues, this is the
way to do it. If you want to discuss them, then let's stay within
shouting distance of the original postings.

| RMS has had a very clear vision, and made a serious effort in explaining
| his design choices, extensibility, up to and including, for example,
| "dynamic binding".  [e.g.  See RMS Emacs paper on Barstow's I.P.E.]. His
| followers have not been so thorough.

His followers have done a fine job in my opinion. I use many of the
extensions that are available and all have been excellent so far. I
have not noted any major departures from the standard practises.

-- 
Kim Letkeman    uunet!mitel!spock!kim