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 05:16:16 -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 1282814192 5484 80.91.229.12 (26 Aug 2010 09:16:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Aug 2010 09:16:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 26 11:16:31 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 1OoYZS-0001CZ-OS for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 11:16:31 +0200 Original-Received: from localhost ([127.0.0.1]:44994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoYZR-0008DI-EO for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2010 05:16:29 -0400 Original-Received: from [199.232.76.173] (port=56226 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoYZH-0008DB-LG for emacs-devel@gnu.org; Thu, 26 Aug 2010 05:16:19 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1OoYZF-000161-SA for emacs-devel@gnu.org; Thu, 26 Aug 2010 05:16:19 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:42132) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1OoYZF-00015w-Hx for emacs-devel@gnu.org; Thu, 26 Aug 2010 05:16:17 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1OoYZE-0005sD-8D; Thu, 26 Aug 2010 05:16:16 -0400 In-reply-to: (message from Uday S Reddy on Thu, 26 Aug 2010 09:23:28 +0100) 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:129245 Archived-At: > From: Uday S Reddy > Date: Thu, 26 Aug 2010 09:23:28 +0100 > > 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. A "good" model will leave only an insignificant bias. I am talking only about good models. I submit that a good model does not need to be based on implementation details. I can understand why programmers tend to base such models on the actual implementation, but I don't agree that a good model must be based on that. Moreover, I actually think that the best models should _not_ be based on implementation details. > 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 No one said that the DAG representation by "bzr log" should be the basis for the model that we all agree users need to form. (I could argue in good faith that this output can be interpreted in a way that is conducive to correct understanding of the history, but that would take us too far from the subject.) > The fact that there isn't a single Bazaar document that mentions DAG > is astonishing. (For the record, I wrote such a document a few months ago and submitted it to the bzr developers. I have no idea when it will become part of the official docs.) As I said elsewhere in this thread, the quality of documentation in the bzr project leaves a lot to be desired. But we should distinguish between inadequacy of the existing documentation and the basis upon which to create a coherent mental model that should be presented to users. This subthread started with an assertion that such a model does not exist for bzr, but does exist for other dVCSs. This is the issue here, not whether bzr documenters did a good job. > > 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. This borders on theology, and I won't enter that argument. But however you see this, what's important is that these theories are _the_only_models_ used in physics, there's no "mental model" on the one hand and the actual "implementation" OTOH. Only meta-physicists argue about the latter, but it's out of scope of physics as a scientific discipline. > 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. Well, your ideas about QM are slightly outdated, and I hear hints that you didn't like physics very much ;-) So I doubt whether this analogy is worth pursuing, especially since I think it was inappropriate to begin with. > My teachers always seemed to prefer the particle model. I > prefer the wave model myself. I think it is conceptually efficient. For some problems, yes. For others, no. What's important is that where it does describe the world correctly, there's no "implementation" known to us that describes things better. If such a better description were to appear, it would immediately replace the existing one. That's not the relations between a mental model of a user and the actual implementation known to developers. For example, a mental model could stay even when the implementation is radically changed. > > 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." 100% agreement.