Re: base

[Eli Zaretskii]

> From: Miles Bader <address@hidden>
> Date: Thu, 26 Aug 2010 12:27:04 +0900
> System-Type: x86_64-unknown-linux-gnu
> 
> Eli Zaretskii <address@hidden> writes:
> > That wasn't the answer I was expecting.  I expected to see several
> > possible workflows with some analysis of their merits and demerits.
> > There's no need to know how a repository stores its info for that.
> 
> The "list some workflows" method quickly breaks down except for
> extremely simple tools (which few tools are), because it would entail
> enumerating a huge number of possible scenarios

You are pushing a simple request ad absurdum.  I wasn't asking for an
exhaustive list of _all_possible_ workflows, only for a few
representative ones.  And please don't tell me that's impossible, or
even hard, because today I can easily do that for Bazaar.

> A model does _not_ need to be the same as the actual implementation --
> rather it's a highly efficient and usable way for the user to understand
> the tool.

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.

> 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.

> people do lots of experiments, but people don't teach physics as a rote
> series of "if you do X, then Y happens" -- that would be madness.
> Instead, they use experiments to develop a model of how things work,
> which can be much more easily taught, and is much more useful once
> learned.

The models developed by physicists are supposed to be how the nature
actually works.  They are not "mental models" by a user who can be
ignorant of the internals, they pretend to be the laws of the nature
itself, which _are_ the "internals".  IOW, in physics, the model and
the actual implementation details are indistinguishable, at least in
practice.  Therefore, this analogy is not useful in the context of
this discussion.

A more useful analogy would be the use of a TV set.  Most people have
no idea how it works, and yet they can use it very efficiently--until
something breaks.  Because I know quite a bit about how it works, I
can sometimes fix simple problems or at least analyze them, whereas my
wife would just call the tech support.

So if we were discussing ways to debug bzr problems or work around
bugs, then yes, some inside knowledge would be extremely helpful.  But
as long as I don't want to debug bzr and will settle for asking "the
technicians" for work-arounds on the bzr list rather than look for
them myself, I have no need for such knowledge.

> For software of course, often the user-model can be based on the
> implementation (though almost always simplifying it)

Only if you want to study or hack the tool.  Most of us never do that
with the majority of the tools we use.

> 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.