* Avoiding side effects @ 2008-09-30 5:50 Anders Wirzenius 2008-09-30 7:48 ` Jean-Pierre Rosen ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Anders Wirzenius @ 2008-09-30 5:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 5:50 Avoiding side effects Anders Wirzenius @ 2008-09-30 7:48 ` Jean-Pierre Rosen 2008-09-30 9:20 ` Anders Wirzenius 2008-09-30 10:42 ` Ludovic Brenta 2008-10-02 12:56 ` Ole-Hjalmar Kristensen 2 siblings, 1 reply; 28+ messages in thread From: Jean-Pierre Rosen @ 2008-09-30 7:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 7:48 ` Jean-Pierre Rosen @ 2008-09-30 9:20 ` Anders Wirzenius 2008-09-30 11:36 ` Jean-Pierre Rosen 0 siblings, 1 reply; 28+ messages in thread From: Anders Wirzenius @ 2008-09-30 9:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 9:20 ` Anders Wirzenius @ 2008-09-30 11:36 ` Jean-Pierre Rosen 2008-09-30 12:43 ` Anders Wirzenius 0 siblings, 1 reply; 28+ messages in thread From: Jean-Pierre Rosen @ 2008-09-30 11:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 11:36 ` Jean-Pierre Rosen @ 2008-09-30 12:43 ` Anders Wirzenius 0 siblings, 0 replies; 28+ messages in thread From: Anders Wirzenius @ 2008-09-30 12:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 5:50 Avoiding side effects Anders Wirzenius 2008-09-30 7:48 ` Jean-Pierre Rosen @ 2008-09-30 10:42 ` Ludovic Brenta 2008-09-30 11:12 ` Anders Wirzenius 2008-10-02 12:56 ` Ole-Hjalmar Kristensen 2 siblings, 1 reply; 28+ messages in thread From: Ludovic Brenta @ 2008-09-30 10:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 10:42 ` Ludovic Brenta @ 2008-09-30 11:12 ` Anders Wirzenius 0 siblings, 0 replies; 28+ messages in thread From: Anders Wirzenius @ 2008-09-30 11:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-09-30 5:50 Avoiding side effects Anders Wirzenius 2008-09-30 7:48 ` Jean-Pierre Rosen 2008-09-30 10:42 ` Ludovic Brenta @ 2008-10-02 12:56 ` Ole-Hjalmar Kristensen 2008-10-06 12:09 ` Anders Wirzenius 2 siblings, 1 reply; 28+ messages in thread From: Ole-Hjalmar Kristensen @ 2008-10-02 12:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-02 12:56 ` Ole-Hjalmar Kristensen @ 2008-10-06 12:09 ` Anders Wirzenius 2008-10-07 11:08 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 28+ messages in thread From: Anders Wirzenius @ 2008-10-06 12:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-06 12:09 ` Anders Wirzenius @ 2008-10-07 11:08 ` Ole-Hjalmar Kristensen 2008-10-07 14:24 ` (see below) 0 siblings, 1 reply; 28+ messages in thread From: Ole-Hjalmar Kristensen @ 2008-10-07 11:08 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-07 11:08 ` Ole-Hjalmar Kristensen @ 2008-10-07 14:24 ` (see below) 2008-10-07 14:47 ` Anders Wirzenius 0 siblings, 1 reply; 28+ messages in thread From: (see below) @ 2008-10-07 14:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-07 14:24 ` (see below) @ 2008-10-07 14:47 ` Anders Wirzenius 2008-10-07 14:51 ` (see below) 0 siblings, 1 reply; 28+ messages in thread From: Anders Wirzenius @ 2008-10-07 14:47 UTC (permalink / raw) "(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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-07 14:47 ` Anders Wirzenius @ 2008-10-07 14:51 ` (see below) 2008-10-08 5:16 ` Anders Wirzenius 0 siblings, 1 reply; 28+ messages in thread From: (see below) @ 2008-10-07 14:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-07 14:51 ` (see below) @ 2008-10-08 5:16 ` Anders Wirzenius 2008-10-08 7:35 ` Dmitry A. Kazakov 2008-10-08 15:32 ` (see below) 0 siblings, 2 replies; 28+ messages in thread From: Anders Wirzenius @ 2008-10-08 5:16 UTC (permalink / raw) "(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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-08 5:16 ` Anders Wirzenius @ 2008-10-08 7:35 ` Dmitry A. Kazakov 2008-10-08 15:32 ` (see below) 1 sibling, 0 replies; 28+ messages in thread From: Dmitry A. Kazakov @ 2008-10-08 7:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-08 5:16 ` Anders Wirzenius 2008-10-08 7:35 ` Dmitry A. Kazakov @ 2008-10-08 15:32 ` (see below) 2008-10-13 12:27 ` Anders Wirzenius 1 sibling, 1 reply; 28+ messages in thread From: (see below) @ 2008-10-08 15:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-08 15:32 ` (see below) @ 2008-10-13 12:27 ` Anders Wirzenius 2008-10-13 13:21 ` Marco 2008-10-13 18:49 ` (see below) 0 siblings, 2 replies; 28+ messages in thread From: Anders Wirzenius @ 2008-10-13 12:27 UTC (permalink / raw) "(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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 12:27 ` Anders Wirzenius @ 2008-10-13 13:21 ` Marco 2008-10-13 18:55 ` (see below) 2008-10-13 18:49 ` (see below) 1 sibling, 1 reply; 28+ messages in thread From: Marco @ 2008-10-13 13:21 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 13:21 ` Marco @ 2008-10-13 18:55 ` (see below) 2008-10-14 7:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 28+ messages in thread From: (see below) @ 2008-10-13 18:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 18:55 ` (see below) @ 2008-10-14 7:30 ` Dmitry A. Kazakov 2008-10-14 11:44 ` Colin Paul Gloster 0 siblings, 1 reply; 28+ messages in thread From: Dmitry A. Kazakov @ 2008-10-14 7:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-14 7:30 ` Dmitry A. Kazakov @ 2008-10-14 11:44 ` Colin Paul Gloster 0 siblings, 0 replies; 28+ messages in thread From: Colin Paul Gloster @ 2008-10-14 11:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 12:27 ` Anders Wirzenius 2008-10-13 13:21 ` Marco @ 2008-10-13 18:49 ` (see below) 2008-10-13 21:22 ` Adam Beneschan 2008-10-14 6:22 ` Avoiding side effects and other dogma Anders Wirzenius 1 sibling, 2 replies; 28+ messages in thread From: (see below) @ 2008-10-13 18:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 18:49 ` (see below) @ 2008-10-13 21:22 ` Adam Beneschan 2008-10-13 21:53 ` (see below) 2008-10-14 6:22 ` Avoiding side effects and other dogma Anders Wirzenius 1 sibling, 1 reply; 28+ messages in thread From: Adam Beneschan @ 2008-10-13 21:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 21:22 ` Adam Beneschan @ 2008-10-13 21:53 ` (see below) 2008-10-14 6:17 ` mockturtle 0 siblings, 1 reply; 28+ messages in thread From: (see below) @ 2008-10-13 21:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-13 21:53 ` (see below) @ 2008-10-14 6:17 ` mockturtle 2008-10-14 14:58 ` Adam Beneschan 0 siblings, 1 reply; 28+ messages in thread From: mockturtle @ 2008-10-14 6:17 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects 2008-10-14 6:17 ` mockturtle @ 2008-10-14 14:58 ` Adam Beneschan 0 siblings, 0 replies; 28+ messages in thread From: Adam Beneschan @ 2008-10-14 14:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects and other dogma. 2008-10-13 18:49 ` (see below) 2008-10-13 21:22 ` Adam Beneschan @ 2008-10-14 6:22 ` Anders Wirzenius 2008-10-14 13:48 ` (see below) 1 sibling, 1 reply; 28+ messages in thread From: Anders Wirzenius @ 2008-10-14 6:22 UTC (permalink / raw) "(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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Avoiding side effects and other dogma. 2008-10-14 6:22 ` Avoiding side effects and other dogma Anders Wirzenius @ 2008-10-14 13:48 ` (see below) 0 siblings, 0 replies; 28+ messages in thread From: (see below) @ 2008-10-14 13:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2008-10-14 14:58 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-30 5:50 Avoiding side effects Anders Wirzenius 2008-09-30 7:48 ` Jean-Pierre Rosen 2008-09-30 9:20 ` Anders Wirzenius 2008-09-30 11:36 ` Jean-Pierre Rosen 2008-09-30 12:43 ` Anders Wirzenius 2008-09-30 10:42 ` Ludovic Brenta 2008-09-30 11:12 ` Anders Wirzenius 2008-10-02 12:56 ` Ole-Hjalmar Kristensen 2008-10-06 12:09 ` Anders Wirzenius 2008-10-07 11:08 ` Ole-Hjalmar Kristensen 2008-10-07 14:24 ` (see below) 2008-10-07 14:47 ` Anders Wirzenius 2008-10-07 14:51 ` (see below) 2008-10-08 5:16 ` Anders Wirzenius 2008-10-08 7:35 ` Dmitry A. Kazakov 2008-10-08 15:32 ` (see below) 2008-10-13 12:27 ` Anders Wirzenius 2008-10-13 13:21 ` Marco 2008-10-13 18:55 ` (see below) 2008-10-14 7:30 ` Dmitry A. Kazakov 2008-10-14 11:44 ` Colin Paul Gloster 2008-10-13 18:49 ` (see below) 2008-10-13 21:22 ` Adam Beneschan 2008-10-13 21:53 ` (see below) 2008-10-14 6:17 ` mockturtle 2008-10-14 14:58 ` Adam Beneschan 2008-10-14 6:22 ` Avoiding side effects and other dogma Anders Wirzenius 2008-10-14 13:48 ` (see below)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox