From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: base Date: Thu, 26 Aug 2010 09:23:28 +0100 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282811040 25433 80.91.229.12 (26 Aug 2010 08:24:00 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Aug 2010 08:24:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 26 10:23:58 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 1OoXkb-0005uJ-R1 for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 10:23:58 +0200 Original-Received: from localhost ([127.0.0.1]:37838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoXka-0002Yi-Pp for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 04:23:56 -0400 Original-Received: from [140.186.70.92] (port=56664 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoXkR-0002Y6-L7 for emacs-devel@gnu.org; Thu, 26 Aug 2010 04:23:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OoXkN-0003Kc-GK for emacs-devel@gnu.org; Thu, 26 Aug 2010 04:23:47 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:58325) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OoXkN-0003KE-6X for emacs-devel@gnu.org; Thu, 26 Aug 2010 04:23:43 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OoXkL-0005kw-J4 for emacs-devel@gnu.org; Thu, 26 Aug 2010 10:23:41 +0200 Original-Received: from cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com ([92.232.137.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Aug 2010 10:23:41 +0200 Original-Received: from u.s.reddy by cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Aug 2010 10:23:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 71 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 In-Reply-To: X-detected-operating-system: by eggs.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:129244 Archived-At: 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