From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2274 invoked by alias); 30 Jul 2008 19:15:34 -0000 Received: (qmail 2264 invoked by uid 22791); 30 Jul 2008 19:15:33 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Jul 2008 19:15:15 +0000 Received: (qmail 17864 invoked from network); 30 Jul 2008 19:15:14 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Jul 2008 19:15:14 -0000 Message-ID: <4890BDBC.4060400@codesourcery.com> Date: Wed, 30 Jul 2008 19:19:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb@sourceware.org Subject: Re: Move GDB to C++ ? References: <487658F7.1090508@earthlink.net> <200807101901.m6AJ1UMQ007185@brahms.sibelius.xs4all.nl> <488F4AA7.7060001@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00334.txt.bz2 Eli Zaretskii wrote: >> From: Vladimir Prus >> Date: Wed, 30 Jul 2008 11:18:09 +0400 >> >> >>> Unless we can answer this question, refactoring and rewriting is >>> simply waste of resources, nothing less, nothing more. >>> >> And here, you also surely know what is generally goal of refactoring -- >> to make code simpler and more amendable for future change. >> > > No, refactoring always has some specific goal. Only given a specific > goal, can one weigh the alternatives -- one to keep existing design > and code and change it, the other to refactor it and then extend the > result. You need to have a clear goal so that you could balance > advantages against disadvantages. Without a goal, all you have is > disadvantages (the overhead and effort of refactoring), because > advantages cannot be estimated without a specific goal in sight. How > do you estimate an advantage of ``making code simpler and more > amenable to change''? You can't. > But to be fair, the coding standards we already impose don't usually have quantifiable benefits. In fact your argument could be used against any kind of abstraction in the code (how do you prove that the target stack is advantageous over some other design?), or against the adding of comments (can you demonstrate that any particular comment block is helping any other developers?). I actually think this is one of the unheralded strengths of free software over proprietary - we're always able to transform the code into something we all *want* to work on. By contrast, proprietary code so often degenerates into undocumented spaghetti, because it only gets touched when there is an obvious short-term benefit, and only touched enough to realize the short-term result. If everybody simply said "yes, I would prefer working on a GDB written in C++", I would consider that sufficient justification all by itself, even if there were no technical reasons. Stan