From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: base Date: Thu, 26 Aug 2010 01:37:41 -0400 Message-ID: References: <20100822120642.GA1794@muc.de> <871v9o7dmf.fsf@uwakimon.sk.tsukuba.ac.jp> <87wrrg5rzg.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5ho5gyr.fsf@uwakimon.sk.tsukuba.ac.jp> <87hbij6hib.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4nf7ezq.fsf@catnip.gol.com> <878w3v7dd2.fsf@catnip.gol.com> <83wrrfmljv.fsf@gnu.org> <87d3t75crc.fsf@uwakimon.sk.tsukuba.ac.jp> <87fwy2g7i2.fsf@telefonica.net> <83r5hmmrz0.fsf@gnu.org> <877hjefll8.fsf@telefonica.net> <83mxsam5lh.fsf@gnu.org> <87eidm5a0n.fsf@catnip.gol.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282801080 23857 80.91.229.12 (26 Aug 2010 05:38:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Aug 2010 05:38:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 26 07:37:59 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OoV9v-000845-It for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 07:37:55 +0200 Original-Received: from localhost ([127.0.0.1]:51557 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoV9u-0006ef-Pp for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 01:37:54 -0400 Original-Received: from [199.232.76.173] (port=58551 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoV9k-0006eR-Pa for emacs-devel@gnu.org; Thu, 26 Aug 2010 01:37:44 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1OoV9j-0008VN-4W for emacs-devel@gnu.org; Thu, 26 Aug 2010 01:37:44 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:43205) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1OoV9i-0008VI-RI for emacs-devel@gnu.org; Thu, 26 Aug 2010 01:37:42 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1OoV9h-00064z-L1; Thu, 26 Aug 2010 01:37:41 -0400 In-reply-to: <87eidm5a0n.fsf@catnip.gol.com> (message from Miles Bader on Thu, 26 Aug 2010 12:27:04 +0900) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129240 Archived-At: > From: Miles Bader > Date: Thu, 26 Aug 2010 12:27:04 +0900 > System-Type: x86_64-unknown-linux-gnu > > Eli Zaretskii 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.