Re: Avoiding side effects

[Adam Beneschan <adam@irvine.com>]

On Oct 13, 11:49 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:

> That's just one of many, along with: "never use goto", "never use
> exceptions", "never use 'use' clauses", "never use pointers", "the OO
> approach is always right", "the market is always right", etc, etc, etc.

[snip]

> What is silly is tying yourself in knots to avoid a perfectly sensible way
> of doing something, because it is abominated by the adherents of a dogma.
>
> The trouble is that bright people (Dijkstra, Hoare, Dahl, etc) offer
> recommendations for general approaches, to be applied with common sense; but
> then their much dimmer followers turn the recommendations into religions.

Or even worse... they turn it into department policy.

It seems like I've seen too many indicences on comp.lang.ada where a
poster wasn't allowed to use a particular construct, even if it was
the best one for their particular situation, because of a department
policy not to use <whatever>.

I've fallen victim to the religion thing, though; when Dijkstra's
"Gotos considered harmful" article came out, I was a COBOL programmer
for the school district at the time, and most of the existing programs
was truly abominably-written spaghetti code, and probably so were most
of mine at the time.  But I (**** SAW THE LIGHT ****) and started
avoiding GOTO's like the plague, which was quite difficult because
COBOL at the time did not have decent control structures---no loops,
just PERFORM paragraph UNTIL, and no "if...end if" or "begin...end"
constructs so that IF's couldn't always be nested inside other IF's
with generality, so I was doing things like moving code sequences down
to separate paragraphs so that I could PERFORM them.  I guess it did
make my code better than spaghetti, but it was still pretty contorted,
and it took some time and a Yourdon book to realize that was I was
doing was silly and unproductive, and started using GOTOs in a more
sensible manner.  I wouldn't say I was particularly "dim" at the time,
just inexperienced, perhaps not surprising since I was only about
sixteen at the time.

But you're absolutely right.  The most important thing is to learn
what makes a program readable and maintainable.  Sometimes this just
takes experience.  But no matter what, dogmas are a very poor
substitute for this kind of learning and experience.  With a few
exceptions... I still think "don't ever use ALTER statements" is
probably a good dogma for COBOL programmers.  The spaghetti-code
programmers who wrote the old software loved using them, and they
always made code difficult to follow.  So I guess even the "no dogmas"
dogma is the kind of dogma that should be avoided...

                              -- Adam