[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-07-31 12:44:46
Message-ID: 46AF2EBE.20802 () acm ! org
[Download RAW message or body]

Ian Wadham wrote:
> On Tue, 31 Jul 2007 04:49 am, Aaron J. Seigo wrote:
>> btw, this is my last reply in this thread. i've wasted enough time on this.
> 
> Please glance at this Babylon 5 excerpt, Aaron and James RT ... :-)
>     http://www.youtube.com/watch?v=umBZ8zXJQjM
> 
> More seriously, when Dijkstra wrote his original letter to Comms. ACM,
> there were major problems in programming and goto's were at the heart
> of them, though not the only problem, and Dijkstra fingered the goto.  More
> to the point (and much more readable) was his book about structured
> programming which came out a few years later and revolutionised
> our thinking about programming.
> 
> In 1968-69, Cobol, Fortran and various assemblers were the reigning
> languages, with some academics championing Algol.  In Fortran, the
> labels were numeric-only, so you'd read a 2000-line program and get
> to a label 1053, where you would like to make a change, but first you
> would have to find and check all the places where 1053 was referenced
> and the program state at all those points.  Some (badly-written) programs
> had scores of cases like that, with the goto's jumping all over many
> pages of code.  They were known as "spaghetti bowls".
> 
> Worse still was another flavor of goto.  There was the "computed" goto
> (quite good), now reincarnated as "switch" or "case", and the "assigned"
> goto (bad), with an equivalent "alter" statement in Cobol.  Assigned goto
> was like a JMP * in assembly language, where the address to jump to
> is changed repeatedly at execution time, making the program almost
> completely unreadable.

Yes, the improper use of any feature can result in really bad code. 
Code with too many CALLs can also become very hard to read.  However, 
"JUMP *" is needed to implement a "switch" and for that use it doesn't 
produce bad code. Remember that there is no structured code in assembly 
code except for CALL and that all other programing structures must be 
implemented using various JUMP instructions.

> 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 ...").
> 
> Someone wrote an article in Datamation back then to say that all our
> problems with the goto could be solved quite easily by having "come
> from" statements.  It wasn't until he got to the horrendously complicated
> "computed come from" and "assigned come from" that you realised
> he was joking.
> 
> BTW, in my assembly language projects (O/S's, device drivers and
> real-time systems), I used to ban JMP * and goto's that went off the
> page.  Time and space really mattered in those applications on those
> small, slow machines, but reliability and maintainability were even
> more important.  A crash could even get you on that night's TV news.

I agree with much of what you say.  I have seen horrible Spaghetti code 
written in Fortran IV.  However I was taught to write good structured 
code in Fortran.  The old restrictions of using only numeric labels 
certainly didn't improve readability.  Remember that you could use 
functions and subroutines in Fortran V and proper use of these greatly 
improved readability.

That said, I feel that adding extra code to avoid using a "goto' is also 
evil.  I agree with the viewpoint in: "GOTO considered harmful, 
considered harmful" published as a letter in Communications of the ACM. 
  I suggest that you read it:

http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf

Perhaps reading it would benefit those that tell you flatly that all use 
of "goto"s is evil.

Note that there are ways to improve structured code to eliminate both 
the ugly extra code used to avoid "goto"s and the "goto"s themselves.

I wrote a programing language to eliminate even more "goto"s.  It used 
Fortran like syntax, but the features could also be added to C.

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