Re: Avoiding side effects and other dogma.

[Anders Wirzenius <anders@no.email.thanks.invalid>]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 13/10/2008 13:27, in article uabd8adeb.fsf@no.email.thanks.invalid,
> "Anders Wirzenius" <anders@no.email.thanks.invalid> wrote:
> > 
> > Is the dogm you refer to something like "functions without side
> > effects". 
> 
> 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.
> 
> > 
> > I am not a professional programmer any more and I just
> > wanted to learn something about side effects. What is silly in that?
> 
> 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.
> 
> I encountered this a lot as a teacher. I remember giving a lecture on memory
> management techniques and being confronted at the end by one a student who
> demanded that I should say which was "the best". When I explained it was not
> possible to do that, he insisted that I really knew which was the best and
> was keeping the secret to myself.
> 
> Too many software practitioners (among many others) have that mindset.

As a teacher you may then be familiar with the difference between
"wanting to learn" and "programming for production". To me it is a
good technique to "strive for perfection" if you use that as a
tool for learning something about a subject.
You may write a program using a goto whenever you have a need for
jumping somewhere and after that write another version of the
program without a single goto. And then write a third version
adopting yet another dogma. The three versions are useless once
you have made up your mind about the consequences of adopting
different principles. You throw those versions in the recycle bin
and start to write the "common sense" adopted program
version. And keep that.

-- 
Anders