emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: base


From: Uday S Reddy
Subject: Re: base
Date: Thu, 26 Aug 2010 09:23:28 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

On 8/26/2010 6:37 AM, Eli Zaretskii wrote:

Exactly right!  So a document that describes to me how bzr stores its
metadata in a repository is not the only or necessarily the best way
of letting me form a model of bzr that is useful enough to guide me in
day-to-day operations.  For complex and unconventional workflows, it
_might_ be necessary to use the history DAG to explain them, but for
the common workflows even that should not be necessary.  And _none_ of
the workflows really need any description of how the data is stored
and what algorithms are used to process that data.

Eli, I agree with the general thrust of your argument. The conceptual model you present to the users can be quite divorced from the implementation. But different conceptual models can have different levels of conceptual efficiency. One model might lead you to draw the right conclusions and another might mislead you. This kind of thing is called "representation bias" in Computer Science.

I believe that the DAG view is the right conceptual model for version management, not the linearized history with time travel as presented by 'bzr log'. When you look at a history like

   429
      326.1.2
      326.1.1
   428

you are not supposed to think "what has changed from 428 to 326.1.1?" You are really supposed to think "what has changed from 326 to 326.1.1?" The fact that 326.1.1 is a successor to 326, and *not* a successor to 428, is quite important. The fact that there isn't a single Bazaar document that mentions DAG is astonishing. And, I didn't think of it either until Stephen put a DAG in front of me and said "look". Problem solved.

Since you said you had a degree in physics, think of it in those terms:

Physics is an inappropriate analogy here, because physics is not a
device to be used.  Physics is essentially a body of knowledge and a
set of rules to extend that knowledge.  Therefore, a physicist is much
more like a software developer than a software user, and there's
little surprise that physicist's activities do require the kind of
under the hood information akin to what the cited Web pages provide
for git and hg.

This is open to question. I might argue that a physicist is a user of nature, not a developer of nature. And, the physicist's models ("theories" in their terminology) are just conceptually-efficient models of nature. They are not necessarily how things work. In Quantum Mechanics, for instance, we have no real idea how things work, and there are two conceptual models one might use. Since it is incoherent to talk about two conceptual models, standard Quantum Mechanics text books present neither, which drives the Physics students nuts just like the Bazaar documentation drives us nuts. Physics teachers help out by telling students their favorite model, which might appeal to some students and not to others. My teachers always seemed to prefer the particle model. I prefer the wave model myself. I think it is conceptually efficient.

It sometimes takes a little extra effort for the user to learn a model
instead of a rote list of actions, but it pays back hugely in giving the
user power over his tool.

Agreed; however, existence of such an information should not be
declared as a fatal blow to the ability of users to learn to use a
tool safely and efficiently.  It is a bonus, but not a necessity.

Without a good conceptual model, it is doubtful if they can use it "safely and efficiently."

Cheers,
Uday






reply via email to

[Prev in Thread] Current Thread [Next in Thread]