🚀 go-pugleaf

>
>Unrestrained pointers are the data structures equivalent of
>uncontrolled GOTOs. A language like C that lets you do anything
>in the world that you please with pointers is very similar to a
>language like BASIC that lets you arbitrarily jump to anyplace you
>want to in your code. Sure, there's a lot of power in that! But
>there's a lot of unnecessary "danger". 

The problem with BASIC (and FORTRAN) is that there used to be no other
way!  The lack of a good way forced sole use of the bad.

>The fact that the C language allows complete, unrestrained
>manipulation of pointers is, in my opinion, a severe disadvantage
>to the language. Defenses of it remind of some papers that I've
>had to read defending the GOTO. I sincerely believe that higher level
>control constructs are preferable to GOTOs; I equally sincerely
>believe that higher level data-structures (like the Eiffel implicit
>references) are preferable to unrestrained pointers.

Allowing is not bad, no acceptable alternatives is bad.

I remember taking a course that stressed structured programming, when
I used a GOTO, the TA wrote a GASP! in red on the listing -- but I lost
no points because the alternates were horrible to contemplate.  
(The situation was 2 levels deep in WHILE statements and about 3 deep
in nested IF's and a error was detected.)  The code was considered easy to
read (by the TA) and the purpose of the GOTO was easy to understand.  The
point here and in the other 5 times I've used goto's in my programming, is
that the goto is sometimes the best way.  Or so I have thought so at those
times.  I do not like languages which have pre-determined what is good for
me and the application which the authors know nothing about.
(I don't count the GOTO's I've coded in BASIC, FORTRAN, or assembly
languages, simply because there was no other way)

This is not meant to be a flame for GOTO's, rather against taking basic
functionality out of languages because they might be misused.  Rather,
add functionality which will result in the bad practice being unnecessary.
When it is easier to code the "good" way, the "bad" will (slowly)
stop being used.  For instance, I have seen very few GOTO's in the
last several years in anybody's code where the language had reasonable
other constructs -- even though the dreaded GOTO was available.

If the bad construct continues to be used, one of two reasons will
be in evidence: 1) not enough education, or more likely 2) the
alternative is not sufficient in the user's (not in the inventor's)
opinion.

    jim miller - it's my opinion so it's the truth :-)