Re: Avoiding side effects

["(see below)" <yaldnif.w@blueyonder.co.uk>]

On 13/10/2008 13:27, in article uabd8adeb.fsf@no.email.thanks.invalid,
"Anders Wirzenius" <anders@no.email.thanks.invalid> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
>> On 08/10/2008 06:16, in article u1vyrbra1.fsf@no.email.thanks.invalid,
>> "Anders Wirzenius" <anders@no.email.thanks.invalid> wrote:
>> 
>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>> 
>>>> On 07/10/2008 15:47, in article uprmc4g3i.fsf@no.email.thanks.invalid,
>>>> "Anders Wirzenius" <anders@no.email.thanks.invalid> wrote:
>>>> 
>>>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>>>> 
>>>>>> On 07/10/2008 12:08, in article wvbrfxn8hdc7.fsf@sun.com, "Ole-Hjalmar
>>>>>> Kristensen" <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
>>>>>> 
>>>>>>> Yes, I think any program which use a read/write interface to a file
>>>>>>> will have side effects in that sense. The only way I can think of for
>>>>>>> avoiding this would be to mmap the whole file, then it will appear as
>>>>>>> an array of bytes.
>>>>>> 
>>>>>> Why would stepping through an array not be thought a "side" effect?
>>>>> 
>>>>> A function that returns the row of that array and only that
>>>>> would perhaps be a function without side effects. The information
>>>>> in that row can be fetched when needed.
>>>> 
>>>> A function that always returns the same row of an array would be of little
>>>> use, I should think.
>>> 
>>> I have a feeling that the function can be programmed so that it returns
>>> different row (numbers, or pointers in that array) depending on
>>> the content of the rows in that array ;-)
>>> 
>>> function Row_Number (Row_Number_In_Other_Array : in
>>>                      Row_Number_Type)  return Row_Number_Type is
>>>    --  Return a row number one higher than the row number of the row
>>>    --  identical to the row in the other array.
>>> 
>> 
>> I think this beautifully illustrates the silliness that slavish adherence to
>> dogma inevitably produces, in programming as in finance and politics.
> 
> The thread I started was about how to avoid side effects. From
> the answers I have been reading that for a case where you compare
> the content of two files, it is rather hard to do it with
> functions without having side effects.
> 
> 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.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk