[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: The no goto religion
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2007-08-05 3:34:13
Message-ID: 46B54535.9060500 () acm ! org
[Download RAW message or body]

Robert Knight wrote:
>> His numbers are based on how
>> the code would compile.  Not on actual execution in a specific
>> architecture.  I don't think that there is any doubt that, in most
>> cases, more instructions will result in longer execution time.
> 
> I have now read the PDF of the paper you linked to.  It was an
> interesting read, thank you for providing the link.
> 
> However, I believe that it does not support the theme of your posts.
>>From the introductory section in which Knuth provides the background
> to the debate (page 268):
> 
>   "A good programmer
>   will not be lulled into complacency by such
>   reasoning, he will be wise to look carefully
>   at the critical code; but only after that code
>   has been identified. It is often a mistake to
>   make a priori judgments about what part
>   of a program are really critical, since the
>   universal experience of programmers who
>   have been using measurement tools has been
>   that their intuitive guesses fail."
> 
> And just before that, the now legendary quote:
> 
>> We should forget about small
>> efficiencies, say about 97% of the time: pre-
>> mature optimization is the root of all evi
> 
> Given that most of KDE is essentially sitting atop a big stack of
> other libraries, issuing function calls to get things done, the kind
> of critical loops that he talks about in the paper are not
> common-place.  If you look at parts of the glibc code however, such as
> heavily used string processing functions, then you will find them.
> 
> Knuth also explicitly advocates readability over micro-optimisation in
> what he refers to as the "97%" of the code which is outside the
> critical inner loops.
> 
> The broad message running through the paper that people should not
> become dogmatic or religious about their approach to programming tools
> is obviously sensible, but I think would make more sense to a reader
> in the context of the on-going discussions which were being held at
> the time, several of which are mentioned in the introduction.  The
> modern example I can think of is the backlash in a few quarters
> against the use of Mono or other high level languages.  Personally I
> do not think the rarity of goto in KDE code is a religious or
> 'dogmatic' choice as the title of your original email implied.
> Rather, I believe it is because people have picked up the style of
> existing code which for whatever reason tended not to use it often.
> In my case neither my programming books, nor my course lectures, nor
> existing open source code I work with uses goto in their solutions
> often.
> 
> In summary, reading this thread has been rather like watching a
> journalist stumble into a Fleet Street editor's office in 2007 with
> his breaking news and analysis of the Crimean War.   Interesting, but
> a couple of days late.

I think that if you read all of the thread you will see that the "no 
goto" dogma is still alive and well.  The argument started in the 70's 
when I was still punching hole in those damned cards and doesn't yet 
seem to be resolved.  Incidentally, not using goto's when writing with 
cards is not very pleasant. :-)

Perhaps I was fortunate that a recent text on C++ that I purchased 
describes the proper use of a "goto" in C++.  My first text on C was the 
"white book".  I learned that the proper use of a 'goto' statement was 
to cleanly break out of nested structures.  That is what it is best used 
for and AFAIK that is best programing practice.  Newer programing 
languages (including the one that I wrote) have ways to avoid this. 
Structures can be given names and/or have multiple exits -- but these -- 
line the 'break' statement -- are just a goto in disguise.

-- 
JRT
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]