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

List:       kde-devel
Subject:    Re: The no goto religion
From:       "Jos Poortvliet" <jos () mijnkamer ! nl>
Date:       2007-08-05 9:11:58
Message-ID: 5c77e14b0708050211y418f799ep9b93e3962f4fce5c () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On 8/5/07, James Richard Tyrer <tyrerj@acm.org> wrote:
>
> I think that if you read all of the thread you will see that the "no
> goto" dogma is still alive and well.


You do?

Let me quote just a few people from this thread.


> i'm more of the "goto makes sense in a few situations, don't use it
otherwise."

> Trust us, we understand your stance on goto.  We know what it can save,
> when it is helpful, when it isn't necessary, when it is too much, etc.
> (even if some didn't, you've certainly made it clear)

> for the record, so that people don't get the wrong idea here: there are
places
> in kde where goto *is* used, and for good reasons. it's not "no goto
allowed"
> it's "use goto only where it makes a real difference".

> It's true.  I found *hundreds* of files in the KDE codebase that contain
> the string "goto", including many in kdelibs itself ... !!!

Not everybody is very positive, indeed:

> I honestly do not believe that your code, as well-intentioned as it is,
> will make a significant improvement in overall application performance.

> Compared to those problems, James, I think you really are talking
> about small differences and it might be more important not to introduce
> style variations into the code base ("When in Rome ...").

But, you actually didn't really disagree with this. I guess mostly because
it's true, of course. It seems most agree that one could be smarter with
goto's in hot paths, so changes can be made AFTER profiling identified the
culprit.

Some are not happy with this whole discussion:

> btw, this is my last reply in this thread. i've wasted enough time on
this.

And that makes sense:
> Code is really a matter of personal taste, as you all know, there's no
need to be a "captain obvious" here.

To be honest, the whole point of this discussion seems to be:

> Well try to take a positive attitude towards flame wars.  I don't take
> them seriously and, therefore, tend to find them entertaining. :-D

And you certainly must know who said that.

The problem is, many people DON'T like flame wars. And it seems we are
wasting our time entertaining you. You might think you're doing a good thing
- and maybe, on some level, the first few emails did show some people GOTO's
aren't that evil. But I think that purpose is long gone, and we're just
entertainment now. While many have better things to do.

So I would politely ask you to stop the discussion. It would benefit KDE, so
consider giving up your fun a contribution to our community.

Don't respond to the individual quotes (you already did, and I'm no
programmer, so I don't give a shit about GOTO's or not - I don't even know
if your point was to use them or NOT use them, and I don't care).

Just tell me if you understand what I'm trying to say.

BTW this isn't a matter of hate (it's more a matter of me having had not
much sleep over the last 3 - 4 days, I guess).

you're doing good stuff in some area's. I just think you shouldn't get
involved in threads longer than 5 - 10 emails because they have a tendency
to grow into pointless discussions. You're point generally has been noted,
yet as long as there you have the slightest sense off disagreement, you go
on. In this discussion, it seems you want a goto on every second line of
code - and as long as ppl object to that, you'll send them emails...

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 <<
>

[Attachment #5 (text/html)]

On 8/5/07, <b class="gmail_sendername">James Richard Tyrer</b> &lt;<a \
href="mailto:tyrerj@acm.org">tyrerj@acm.org</a>&gt; wrote:<div><span \
class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I think \
that if you read all of the thread you will see that the &quot;no<br>goto&quot; dogma \
is still alive and well.&nbsp;&nbsp;</blockquote><div><br>You do?<br><br>Let me quote \
just a few people from this thread.<br><br><br> &gt; i&#39;m more of the &quot;goto \
makes sense in a few situations, don&#39;t use it otherwise.&quot;<br>

<br>&gt; Trust us, we understand your stance on goto.&nbsp; We know what it can \
save,<br>&gt; when it is helpful, when it isn&#39;t necessary, when it is too much, \
etc.<br>&gt; (even if some didn&#39;t, you&#39;ve certainly made it clear) \
<br><br>&gt; for the record, so that people don&#39;t get the wrong idea here: there \
are places<br>&gt; in kde where goto *is* used, and for good reasons. it&#39;s not \
&quot;no goto allowed&quot;<br>&gt; it&#39;s &quot;use goto only where it makes a \
real difference&quot;. <br><br>&gt; It&#39;s true.&nbsp; I found *hundreds* of files \
in the KDE codebase that contain<br>&gt; the string &quot;goto&quot;, including many \
in kdelibs itself ... !!!<br><br>Not everybody is very positive, indeed:<br></div> \
<br>&gt; I honestly do not believe that your code, as well-intentioned as it is, \
<br>&gt; will make a significant improvement in overall application \
performance.<br><br>&gt; Compared to those problems, James, I think you really are \
talking <br>&gt; about small differences and it might be more important not to \
introduce<br>&gt; style variations into the code base (&quot;When in Rome \
...&quot;).<br><br>But, you actually didn&#39;t really disagree with this. I guess \
mostly because it&#39;s true, of course. It seems most agree that one could be \
smarter with goto&#39;s in hot paths, so changes can be made AFTER profiling \
identified the culprit. <br><br>Some are not happy with this whole \
discussion:<br><br><span class="q">&gt; btw, this is my last reply in this thread. \
i&#39;ve wasted enough time on this.<br><br>And that makes sense:<br>&gt; Code is \
really a matter of personal taste, as you all know, there&#39;s no need to be a \
&quot;captain obvious&quot; here. <br><br>To be honest, the whole point of this \
discussion seems to be:<br><br>&gt; Well try to take a positive attitude towards \
flame wars.&nbsp; I don&#39;t take<br>&gt; them seriously and, therefore, tend to \
find them entertaining. :-D <br><br>And you certainly must know who said \
that.<br><br>The problem is, many people DON&#39;T like flame wars. And it seems we \
are wasting our time entertaining you. You might think you&#39;re doing a good thing \
- and maybe, on some level, the first few emails did show some people GOTO&#39;s \
aren&#39;t that evil. But I think that purpose is long gone, and we&#39;re just \
entertainment now. While many have better things to do. <br><br>So I would politely \
ask you to stop the discussion. It would benefit KDE, so consider giving up your fun \
a contribution to our community.<br><br>Don&#39;t respond to the individual quotes \
(you already did, and I&#39;m no programmer, so I don&#39;t give a shit about \
GOTO&#39;s or not - I don&#39;t even know if your point was to use them or NOT use \
them, and I don&#39;t care). <br><br>Just tell me if you understand what I&#39;m \
trying to say.<br><br>BTW this isn&#39;t a matter of hate (it&#39;s more a matter of \
me having had not much sleep over the last 3 - 4 days, I guess).<br><br>you&#39;re \
doing good stuff in some area&#39;s. I just think you shouldn&#39;t get involved in \
threads longer than 5 - 10 emails because they have a tendency to grow into pointless \
discussions. You&#39;re point generally has been noted, yet as long as there you have \
the slightest sense off disagreement, you go on. In this discussion, it seems you \
want a goto on every second line of code - and as long as ppl object to that, \
you&#39;ll send them emails... <br><br></span><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">The argument started in the 70&#39;s<br>when I was still punching \
hole in those damned cards and doesn&#39;t yet <br>seem to be \
resolved.&nbsp;&nbsp;Incidentally, not using goto&#39;s when writing with<br>cards is \
not very pleasant. :-)<br><br>Perhaps I was fortunate that a recent text on C++ that \
I purchased<br>describes the proper use of a &quot;goto&quot; in C++.&nbsp;&nbsp;My \
first text on C was the <br>&quot;white book&quot;.&nbsp;&nbsp;I learned that the \
proper use of a &#39;goto&#39; statement was<br>to cleanly break out of nested \
structures.&nbsp;&nbsp;That is what it is best used<br>for and AFAIK that is best \
programing practice.&nbsp;&nbsp;Newer programing <br>languages (including the one \
that I wrote) have ways to avoid this.<br>Structures can be given names and/or have \
multiple exits -- but these --<br>line the &#39;break&#39; statement -- are just a \
goto in disguise.<br> <br>--<br>JRT<br><br>&gt;&gt; Visit <a \
href="http://mail.kde.org/mailman/listinfo/kde-devel#unsub">http://mail.kde.org/mailman/listinfo/kde-devel#unsub</a> \
to unsubscribe &lt;&lt;<br></blockquote></div><br>



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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

Configure | About | News | Add a list | Sponsored by KoreLogic