Avoiding side effects

Avoiding side effects

[Anders Wirzenius]

Another thread about functions and side effects triggered me to
ask advice how to solve a specific problem without using side effects.

Problem:
Two files A and B containing one code per line (actually a
material number). I want to have the difference between those
files (A-B), i.e. remove those lines in A that are mentioned in
B.
B may contain codes that are not present in A.
A and B contain up to 1.5 million lines each.

My solution:
I sort the files alphabetically and remove possible duplicates
(Unix commands sort and uniq).
I create two functions, Strip and Advance.
function Strip (Remove_This : in String) return String
   -- Displays rows until row > Remove_This.
function Advance (Candidate : in String) return String
   --  Advance in file until row > Candidate.
The main program is then merely a loop where I alternate between
advancing lines in the two files until the row in the file is
greater than the value to compare against:
...
loop
   Trans_String := To_Unbounded_String (Strip (To_String
    (Trans_String)));
   Trans_String := To_Unbounded_String (Advance (To_String
    (Trans_String)));
end loop;
The problem is how to deal with the situation when I reach the
end of the file. 
I have done it using a side effect:
EOF_Reached     : Boolean := False;
loop
   Trans_String...
   exit when EOF_Reached;
   Trans_String...
   exit when EOF_Reached;
end loop;
--  Display possible tail of file A.
EOF_Reached is set to True in the functions Strip and Advance as
a side effect.

Is there a better way without using the side effect EOF_Reached?

-- 
Anders

Re: Avoiding side effects

[Jean-Pierre Rosen]

Anders Wirzenius a �crit :
[...]
> The problem is how to deal with the situation when I reach the
> end of the file. 
> I have done it using a side effect:
> EOF_Reached     : Boolean := False;
> loop
>    Trans_String...
>    exit when EOF_Reached;
>    Trans_String...
>    exit when EOF_Reached;
> end loop;
> --  Display possible tail of file A.
> EOF_Reached is set to True in the functions Strip and Advance as
> a side effect.
> 
> Is there a better way without using the side effect EOF_Reached?
> 

Exceptions of course!
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Avoiding side effects

[Anders Wirzenius]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Anders Wirzenius a �crit :
> [...]
> > The problem is how to deal with the situation when I reach the
> > end of the file. I have done it using a side effect:
> > EOF_Reached     : Boolean := False;
> > loop
> >    Trans_String...
> >    exit when EOF_Reached;
> >    Trans_String...
> >    exit when EOF_Reached;
> > end loop;
> > --  Display possible tail of file A.
> > EOF_Reached is set to True in the functions Strip and Advance as
> > a side effect.
> > Is there a better way without using the side effect EOF_Reached?
> >
> 
> Exceptions of course!

Please don't feel like I am provocative. I just want to find out
the difference between exceptions and side effects:

Why is an exception in this case not considered to be a side
effect?

-- 
Anders

Re: Avoiding side effects

[Ludovic Brenta]

Anders Wirzenius wrote:
> I create two functions, Strip and Advance.
> function Strip (Remove_This : in String) return String
>    -- Displays rows until row > Remove_This.
> function Advance (Candidate : in String) return String
>    --  Advance in file until row > Candidate.
> The main program is then merely a loop where I alternate between
> advancing lines in the two files until the row in the file is
> greater than the value to compare against:
...
> The problem is how to deal with the situation when I reach the
> end of the file.
...

Both of your functions already have the side effect of moving the
current position in the input files, so I don't see why you would want
to avoid side effects. I think Jean-Pierre's answer is good; use the
exceptions that Ada.Text_IO propagates to indicate the end of file.

--
Ludovic Brenta.

Re: Avoiding side effects

[Anders Wirzenius]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Anders Wirzenius wrote:
> > I create two functions, Strip and Advance.
> > function Strip (Remove_This : in String) return String
> >    -- Displays rows until row > Remove_This.
> > function Advance (Candidate : in String) return String
> >    --  Advance in file until row > Candidate.
> > The main program is then merely a loop where I alternate between
> > advancing lines in the two files until the row in the file is
> > greater than the value to compare against:
> ...
> > The problem is how to deal with the situation when I reach the
> > end of the file.
> ...
> 
> Both of your functions already have the side effect of moving the
> current position in the input files, so I don't see why you would want
> to avoid side effects. I think Jean-Pierre's answer is good; use the
> exceptions that Ada.Text_IO propagates to indicate the end of file.

Yes, you are right. 
The design in itself contains at least one side effect.
Thanks to both of you, Jean-Pierre and Ludovic.

-- 
Anders

Re: Avoiding side effects

[Jean-Pierre Rosen]

Anders Wirzenius a �crit :
> Please don't feel like I am provocative. I just want to find out
> the difference between exceptions and side effects:
> 
> Why is an exception in this case not considered to be a side
> effect?
> 
To me, an exception is more like a kind of result rather than a side-effect.

A subprogram is intended to provide a certain service; either it can 
provide the intended result, or it must tell the caller, in an 
unambiguous way, that the correct result could not be provided; that's 
what exceptions are for.

If you compare exception with a return code, the difference is that you 
can easily ignore a return code, but not an exception. And remember:
    "There is only one thing worse than a program that crashes:
     a program that gives wrong, but likely results."
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Avoiding side effects

[Anders Wirzenius]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Anders Wirzenius a �crit :
> > Please don't feel like I am provocative. I just want to find out
> > the difference between exceptions and side effects:
> > Why is an exception in this case not considered to be a side
> > effect?
> >
> To me, an exception is more like a kind of result rather than a side-effect.
> 
> A subprogram is intended to provide a certain service; either it can
> provide the intended result, or it must tell the caller, in an
> unambiguous way, that the correct result could not be provided; that's
> what exceptions are for.
> 
> If you compare exception with a return code, the difference is that
> you can easily ignore a return code, but not an exception. And
> remember:
>     "There is only one thing worse than a program that crashes:
>      a program that gives wrong, but likely results."

Thanks for this excellent clarification. Actually there exists
already occurrences of an exception in both functions. To
"translate" those Ada.Text_IO.End_Of_File (...) occurrences to a
global EOF_variable is just clumsy. Much better to use the
exceptions directly in the main program.

Thanks for your time.

-- 
Anders

Re: Avoiding side effects

[Ole-Hjalmar Kristensen]

If I understand your problem correctly, why not simply do the
following after the sort -u stage?:

comm -23 fileA fileB

But to answer the Ada quiestion, I think I would organize the loop a
little bit differently. The following is a classical way of merging
two files, but it should work in your case too:

  while not End_Of_File(File_A) and not End_Of_File(File_B) loop
  -- Process records from both files
  end loop;

  while not End_Of_File(File_A) loop
  -- Process tail of file A
  end loop;

  while not End_Of_File(File_B) loop
  -- Process tail of file B
  end loop;

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Avoiding side effects

[Anders Wirzenius]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> writes:

> If I understand your problem correctly, why not simply do the
> following after the sort -u stage?:
> 
> comm -23 fileA fileB

Oops. I was not aware of that program. Looks promising. Thanks.

> 
> But to answer the Ada quiestion, I think I would organize the loop a
> little bit differently. The following is a classical way of merging
> two files, but it should work in your case too:
> 
>   while not End_Of_File(File_A) and not End_Of_File(File_B) loop
>   -- Process records from both files
>   end loop;
> 
>   while not End_Of_File(File_A) loop
>   -- Process tail of file A
>   end loop;
> 
>   while not End_Of_File(File_B) loop
>   -- Process tail of file B
>   end loop;

Thanks for that, too. The program I wrote did the job and was
sufficiently fast. My question was more about how to do it using
subprograms (functions) without side effects. 
I suppose "Process records from..." and "Process tail..." are
having side effects if coded as subprograms, as they advance the
pointer in the two files.

-- 
Anders

Re: Avoiding side effects

[Ole-Hjalmar Kristensen]

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.

>>>>> "AW" == Anders Wirzenius <anders@no.email.thanks.invalid> writes:

<snip>

    AW> Thanks for that, too. The program I wrote did the job and was
    AW> sufficiently fast. My question was more about how to do it using
    AW> subprograms (functions) without side effects. 
    AW> I suppose "Process records from..." and "Process tail..." are
    AW> having side effects if coded as subprograms, as they advance the
    AW> pointer in the two files.

    AW> -- 
    AW> Anders

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Avoiding side effects

[(see below)]

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?

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

Re: Avoiding side effects

[Anders Wirzenius]

"(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.

-- 
Anders

Re: Avoiding side effects

[(see below)]

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.

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

Re: Avoiding side effects

[Anders Wirzenius]

"(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. 


-- 
Anders

Re: Avoiding side effects

[Dmitry A. Kazakov]

On Wed, 08 Oct 2008 05:16:22 GMT, Anders Wirzenius 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 ;-)

... which (content) cannot itself be a function, when mutable. There is no
way out of "functional singularity." (:-))

Even a pure function is not a function in the promoted sense. It is a
subroutine with one dedicated out parameter, called "result," such that all
effect of execution is limited to that parameter.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Avoiding side effects

[(see below)]

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.

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

Re: Avoiding side effects

[Anders Wirzenius]

"(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". 

I am not a professional programmer any more and I just
wanted to learn something about side effects. What is silly in
that?


-- 
Anders

Re: Avoiding side effects

[Marco]

On Oct 13, 5:27 am, Anders Wirzenius <and...@no.email.thanks.invalid>
wrote:
> "(see below)" <yaldni...@blueyonder.co.uk> writes:
> > On 08/10/2008 06:16, in article u1vyrbra1....@no.email.thanks.invalid,
> > "Anders Wirzenius" <and...@no.email.thanks.invalid> wrote:
>
> > > "(see below)" <yaldni...@blueyonder.co.uk> writes:
>
> > >> On 07/10/2008 15:47, in article uprmc4g3i....@no.email.thanks.invalid,
> > >> "Anders Wirzenius" <and...@no.email.thanks.invalid> wrote:
>
> > >>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>
> > >>>> On 07/10/2008 12:08, in article wvbrfxn8hdc7....@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 havesideeffects 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 withoutsideeffects. 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 avoidsideeffects. 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 havingsideeffects.
>
> Is the dogm you refer to something like "functions withoutside
> effects".
>
> I am not a professional programmer any more and I just
> wanted to learn something aboutsideeffects. What is silly in
> that?

  nothing, but I agree don't get carried away with the concept,
Functional Programming is kind of an extreme backlash to the Object
Oriented push of the late 80's and 90's, in the end, both are useful
but is important to keep as many functions "pure" as possible because
these tend to be easier to verify and are more reusable in other
contexts.

 http://en.wikipedia.org/wiki/Pure_function

 At work, we are trending away from the pure OO stuff to a mixed
approach.

Re: Avoiding side effects

[(see below)]

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

Re: Avoiding side effects

[(see below)]

On 13/10/2008 14:21, in article
c3d10577-421a-4fb0-b27f-1395df583dd9@w1g2000prk.googlegroups.com, "Marco"
<prenom_nomus@yahoo.com> wrote:

> On Oct 13, 5:27 am, Anders Wirzenius <and...@no.email.thanks.invalid>
> wrote:
>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>>> On 08/10/2008 06:16, in article u1vyrbra1....@no.email.thanks.invalid,
>>> "Anders Wirzenius" <and...@no.email.thanks.invalid> wrote:
>> 
>>>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>> 
>>>>> On 07/10/2008 15:47, in article uprmc4g3i....@no.email.thanks.invalid,
>>>>> "Anders Wirzenius" <and...@no.email.thanks.invalid> wrote:
>> 
>>>>>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>> 
>>>>>>> On 07/10/2008 12:08, in article wvbrfxn8hdc7....@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 havesideeffects 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 withoutsideeffects. 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 avoidsideeffects. 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 havingsideeffects.
>> 
>> Is the dogm you refer to something like "functions withoutside
>> effects".
>> 
>> I am not a professional programmer any more and I just
>> wanted to learn something aboutsideeffects. What is silly in
>> that?
> 
>   nothing, but I agree don't get carried away with the concept,
> Functional Programming is kind of an extreme backlash to the Object
> Oriented push of the late 80's and 90's, in the end, both are useful

FP started with LISP, ca. 1960, and turned into a major academic industry in
the early 1980s. Only AI rivals it as a wholesale waste of CS effort.

> but is important to keep as many functions "pure" as possible because
> these tend to be easier to verify and are more reusable in other
> contexts.
> 
>  http://en.wikipedia.org/wiki/Pure_function
> 
>  At work, we are trending away from the pure OO stuff to a mixed
> approach.

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

Re: Avoiding side effects

[Adam Beneschan]

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

Re: Avoiding side effects

[(see below)]

On 13/10/2008 22:22, in article
d3ea88f3-cb6c-48a2-9661-5cd63fdbf188@l33g2000pri.googlegroups.com, "Adam
Beneschan" <adam@irvine.com> wrote:
... 
> 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

Exactly.

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

Nope.
I'm sure there is a good use for ALTER.
I just don't know what it is yet. 8-)

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

Re: Avoiding side effects

[mockturtle]

(see below) ha scritto:

> On 13/10/2008 22:22, in article
> d3ea88f3-cb6c-48a2-9661-5cd63fdbf188@l33g2000pri.googlegroups.com, "Adam
> Beneschan" <adam@irvine.com> wrote:
> ...
> > 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
>
> Exactly.
>
> > 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.
(snip=



>
> Nope.
> I'm sure there is a good use for ALTER.
> I just don't know what it is yet. 8-)
>

You "structured guys" are so limited... (that is why you are never on
the
right side of an assignment :-) ALTER is such a wonderful statement!
Something like FORTRAN computed GOTO, only a little bit more
perverted.  Just a (tiny) step away from  a COME FROM.... 8-)

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

Re: Avoiding side effects and other dogma.

[Anders Wirzenius]

"(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

Re: Avoiding side effects

[Dmitry A. Kazakov]

On Mon, 13 Oct 2008 19:55:17 +0100, (see below) wrote:

> FP started with LISP, ca. 1960, and turned into a major academic industry in
> the early 1980s. Only AI rivals it as a wholesale waste of CS effort.

(:-))

However there is a crucial difference between them. Lambda calculus is a
nice theory of little or no practical use.

AI has no theory whatsoever, it is a bunch of methods useful and used in
practice.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Avoiding side effects

[Colin Paul Gloster]

On Tue, 14 Oct 2008, Dmitry A. Kazakov wrote:

|------------------------------------------------------------------------------|
|"On Mon, 13 Oct 2008 19:55:17 +0100, (see below) wrote:                       |
|                                                                              |
|> FP started with LISP, ca. 1960, and turned into a major academic industry in|
|> the early 1980s. Only AI rivals it as a wholesale waste of CS effort.       |
|                                                                              |
|(:-))                                                                         |
|                                                                              |
|However there is a crucial difference between them. Lambda calculus is a      |
|nice theory of little or no practical use.                                    |
|                                                                              |
|[..]"                                                                         |
|------------------------------------------------------------------------------|

Typed lambda calculus has been of use in verification.

Regards,
C. P. G.

Re: Avoiding side effects and other dogma.

[(see below)]

On 14/10/2008 07:22, in article u8wsrwv9j.fsf_-_@no.email.thanks.invalid,
"Anders Wirzenius" <anders@no.email.thanks.invalid> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
...
>> 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.

That's fine: it directly contradicts the idea that there is precisely one
"correct" way to do everything, and that pernicious idea is what I condemn.

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

Re: Avoiding side effects

[Adam Beneschan]

On Oct 13, 11:17 pm, mockturtle <framefri...@gmail.com> wrote:

> > Nope.
> > I'm sure there is a good use for ALTER.
> > I just don't know what it is yet. 8-)
>
> You "structured guys" are so limited... (that is why you are never on
> the
> right side of an assignment :-) ALTER is such a wonderful statement!
> Something like FORTRAN computed GOTO, only a little bit more
> perverted.  Just a (tiny) step away from  a COME FROM.... 8-)

You mean this?

http://www.fortran.com/come_from.html

Yep, I remember reading that article way back when...

                               -- Adam