From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Thorpe Newsgroups: gmane.emacs.help Subject: Re: What does "lacks a prefix" mean? Date: Thu, 30 Jul 2015 02:40:18 +0100 Message-ID: <87twsmxw1p.fsf@robertthorpeconsulting.com> References: <87fv492ko8.fsf@nl106-137-147.student.uu.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438220448 31779 80.91.229.3 (30 Jul 2015 01:40:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jul 2015 01:40:48 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Emanuel Berg Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jul 30 03:40:43 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 1ZKcpu-0007o4-SA for geh-help-gnu-emacs@m.gmane.org; Thu, 30 Jul 2015 03:40:43 +0200 Original-Received: from localhost ([::1]:37483 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKcpu-0005Ty-8N for geh-help-gnu-emacs@m.gmane.org; Wed, 29 Jul 2015 21:40:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKcpd-0005TC-GD for help-gnu-emacs@gnu.org; Wed, 29 Jul 2015 21:40:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKcpa-0000jQ-55 for help-gnu-emacs@gnu.org; Wed, 29 Jul 2015 21:40:25 -0400 Original-Received: from outbound-smtp04.blacknight.com ([81.17.249.35]:39002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKcpZ-0000iM-SC for help-gnu-emacs@gnu.org; Wed, 29 Jul 2015 21:40:22 -0400 Original-Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp04.blacknight.com (Postfix) with ESMTPS id 7325F98B1C for ; Thu, 30 Jul 2015 01:40:20 +0000 (UTC) Original-Received: (qmail 19484 invoked from network); 30 Jul 2015 01:40:20 -0000 Original-Received: from unknown (HELO RTLaptop) (rt@robertthorpeconsulting.com@[109.76.151.238]) by 81.17.254.9 with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 30 Jul 2015 01:40:19 -0000 In-Reply-To: <87fv492ko8.fsf@nl106-137-147.student.uu.se> (message from Emanuel Berg on Tue, 28 Jul 2015 02:24:55 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 81.17.249.35 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:106136 Archived-At: I won't talk about this much more because I think it's getting off-topic for this list. Emanuel Berg writes: > 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! I think that new languages should be written to do this the same way. I think the convention for let and let* used in lisp is useful and I wish it were more widespread. I'm not advocating it just because it's used in old code. My comments about refactoring were separate. > 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!). Certainly there is no point in avoiding dependencies. They always occur in programming. But, there's no need to make it look as through there are dependencies where there aren't. There's no point removing tools that allow use to differentiate one situation from the other easily. That's the problem with the approach you're advocating. As I said earlier, let's suppose you're reading through function foo looking for what happens to variable bar. Suppose you have:- (let (..... (foo (code ...))) body) In this case there's no need to read through any of the other variables defined in the let. Suppose instead you have: (let* (..... (foo (code ...))) body) In that case the part I've labeled "code ..." could depend on the other local variables. In the "let" case it's often possible to eval the "code ..." part with C-x C-e. That's often not possible in the let* case. In the let* case you have to read through the rest of the local variable definitions. In elisp we have the following meanings: * let - there aren't dependencies between these variables. * let* - there are dependencies between these variables. In other languages that only support something like let* it means "there may be dependencies between these variables, you have to read all the code". >> 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! Of course, refactoring is often exactly what you say. It's improving code. Some people define it more rigourously. For example, making local improvements to code without changing the overall design is called "refactoring". Changing the overall design is called "rearchitecting". Remember the original reason we discussed this though. You wrote this: > Why the (?)? Mucking around with old code is necessary every time you > want to add a feature or debug a failure. Now, you're advocating "mucking around with old code". Well, that inevitably requires reading it and understanding it. New features must always be inserted somewhere. The original designers of a program can never envisage all of the ways that it might be extended. Look at Emacs, it's existed for decades and for all that time it's maintainers have tried to expand configurability. Yet, every few weeks somebody comes up with a practical case were a default behaviour can't be changed. >> 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! Of course I don't think there's any particular threshold in terms of lines-of-code of the type you describe. What more important is the overall effort of rewriting vs fixing. For example, is the existing program merely messy? If so then it's often better to tidy it up than re-write it even if it's small. If the program has a few modules that are badly written then those can be replaced. Is the original full of undocumented features everyone relies on? If so then re-writing it can be very tricky. Programs that are badly designed are a difficult case. If they're badly designed but the design is well executed (i.e. the code is generally well written) then it can be best to keep them around. If a program is really bad (i.e. buggy, badly written and difficult to modify) then it may be worth replacing it even if it's millions of lines long. Redesigning is one of the most useful and interesting programming skills to develop. It's about knowing how to re-use what you have to build a more general program without throwing too much away. BR, Robert Thorpe