From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: What does "lacks a prefix" mean? Date: Tue, 28 Jul 2015 02:24:55 +0200 Message-ID: <87fv492ko8.fsf@nl106-137-147.student.uu.se> References: <87lhed0xp2.fsf@robertthorpeconsulting.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438043223 32444 80.91.229.3 (28 Jul 2015 00:27:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jul 2015 00:27:03 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jul 28 02:26:54 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJsjK-0005yL-3N for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Jul 2015 02:26:50 +0200 Original-Received: from localhost ([::1]:56321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJsjJ-0004mF-9i for geh-help-gnu-emacs@m.gmane.org; Mon, 27 Jul 2015 20:26:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45978) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJsj8-0004m4-V0 for help-gnu-emacs@gnu.org; Mon, 27 Jul 2015 20:26:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJsj4-0001wB-My for help-gnu-emacs@gnu.org; Mon, 27 Jul 2015 20:26:38 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:50770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJsj4-0001vK-Fs for help-gnu-emacs@gnu.org; Mon, 27 Jul 2015 20:26:34 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZJsj2-0005fJ-Op for help-gnu-emacs@gnu.org; Tue, 28 Jul 2015 02:26:32 +0200 Original-Received: from nl106-137-228.student.uu.se ([130.243.137.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Jul 2015 02:26:32 +0200 Original-Received: from embe8573 by nl106-137-228.student.uu.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 28 Jul 2015 02:26:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 84 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: nl106-137-228.student.uu.se Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:oGwB3dCglkDx3E16Mpqrlek8BRs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106046 Archived-At: Robert Thorpe writes: > For what it's worth, this is my opinion on let vs > let*. > > When there's a dependency between two of the > variables I use let*. If there's no dependency at > all I use let. So, if the code defining y depends on > the code defining x then I use let*. > > I don't like the style where let* is used for > everything. Here's an example of the problem. > Suppose you're reading through a function. You have > a local variable z and you want to understand what > values it could have. To begin with you want to > understand what could happen at the beginning of the > body of the let statement z is defined in. > > I.e.:- (defun foo () "blah blah" (let* ((a > (something)) (b (something-else ...)) (z > (something-more))) ... here... ...rest of the code...) > > Now, let's say the programmer has used let. In that > case I know by looking that I don't have to read the > definitions of a & b. Alternatively, suppose the > programmer has used let* even though z isn't > dependent on a or b. In that case let* indicates to > me the reader that they should read the definitions > of a & b. But, doing that isn't immediately > necessary, I may not need to understand the details > of a & b to understand the problem. This is the exact same tiresome argument that has been put forward several times by now and the argument is still only logical within the framework that is "this is the way people do it". Yes: I know! In the other framework, where it is natural and *desired* that things depend on each other and happen stepwise - nothing to be afraid of and nothing that must be marked specifically as it is the natural order of things - in that framework it doesn't make sense (surprise, surprise!). There is a framework of convention but beneath that there is technology. On top of that we can create any framework of our minds as we desire. If we create one that doesn't make sense in terms of technology, if we use it enough, we'll even start to like it! It is sly! > It's easy to be critical of the process of > restructuring or refactoring code. It's inevitable > in large codebases though. OK, so how many lines of zsh, C, C++ and Lisp do you have to write before it gets inevitable to "refactor" it? I ask because I did my biggest projects in those languages but apparently they weren't big enough because I never did any "refactoring", whatever that is, if it isn't the very normal and everyday thing that is writing, improving, and fixing bugs in code, in what case I have done it every day for many years! What is all this talk?! I don't understand this whole defaitiste "we know the drill" mentality. "It is just the way it is." It isn't - what it is is an empty buffer and it doesn't have to be anything and it can be whatever you want it to be! "Do it today, in a different way!" (Scooter 2010) > The cost and time of rewriting them is simply too > large. Even if the original is badly written it > generally contains undocumented features that people > rely on. If a large program is well written that > doesn't mean it won't need modifications regularly. So, everything is so bad, we have to have let/let* - it is inevitable! -- underground experts united http://user.it.uu.se/~embe8573