help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cloning is good (was Re: How to get the help of @?)


From: Sergei Steshenko
Subject: Re: Cloning is good (was Re: How to get the help of @?)
Date: Sun, 2 Sep 2012 13:09:55 -0700 (PDT)

--- On Sun, 9/2/12, Israel Herraiz <address@hidden> wrote:

> From: Israel Herraiz <address@hidden>
> Subject: Re: Cloning is good (was Re: How to get the help of @?)
> To: "help-octave" <address@hidden>
> Date: Sunday, September 2, 2012, 12:45 PM
> Excerpts from Sergei Steshenko's
> message of Sun Sep 02 20:27:48 +0200 2012:
> > I think you have subtly changed the subject/replaced
> the problem.
> 
> No, I did not. The problem I was referring to was this one,
> as stated
> by yourself:
> 
> " as I wrote you on different occasions, you IMO do not
> demonstrate
> understanding of SW architecture and of proper development
> methodology. This particular example shows that you
> apparently ignore
> the 'single point of change/maintenance' concept".
> 
> That concept you mention is IMO just a myth, as many other
> principles
> of software engineering. My point was (or at least,
> attempted to be :)
> that the concept you mention is not backed by any empirical
> evidence,
> and I provided empirical evidence of the opposite. That is,
> the
> opposite of that concept is true. So your accusation of lack
> of
> software engineering knowledge is based on a principle which
> has been
> shown to be false with empirical evidences.
> 
> Cheers,
> Israel
> 


I have already read 15 pages of the article, and I haven't come to the 
conclusion that the article denies the importance of single point of 
change/maintenance.

The article simply explains when and where cloning makes sense.

In fact, I, for example, am fed up with frequent breakages of ALSA (Linux sound 
system). some of them happen because the developers change common for many 
sound cards piece and fail to test it properly - a frequent example from the 
article.

But in this case (semantically) identical documentation is desirable, and a 
call to create a patch instead of changing the workflow which _ensures_ 
(semantically) identical results is a demonstration of not demonstrating 
understanding of SW architecture and of proper development methodology.

I.e. I used the example with documentation not as a myth, but as a concrete 
case where single point of change/maintenance is beneficial.

And, regarding the article, I have my own pretty sophisticated PerlPreProcessor 
used as source code generator - source code generation is also mentioned in the 
article.

It is one of my beloved workhorses.

Regards,
  Sergei.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]