From mark_difford at yahoo.co.uk  Tue Feb 24 17:52:59 2009
From: mark_difford at yahoo.co.uk (Mark Difford)
Date: Tue, 24 Feb 2009 08:52:59 -0800 (PST)
Subject: [Rd] [R] Semantics of sequences in R
In-Reply-To: <22183297.post@talk.nabble.com>
References: <8b356f880902221350q4a976bfr19b0d5b01a989250@mail.gmail.com>
	<20090223113422.76cc1494@absentia> <49A255A5.1010506@idi.ntnu.no>
	<20090223175623.6106add2@berwin-nus1> <49A27AF4.307@idi.ntnu.no>
	<20090223192757.2ff7f629@berwin-nus1>
	<49A2961C.3020405@idi.ntnu.no>
	<20090224001247.5d2e3db9@berwin5> <49A2F89B.10900@idi.ntnu.no>
	<20090224160252.154a7d75@berwin-nus1>
	<49A3B257.2000103@idi.ntnu.no>
	<20090224175215.1336a820@berwin-nus1>
	<49A3C9A3.80506@erasmusmc.nl> <22183297.post@talk.nabble.com>
Message-ID: <22184447.post@talk.nabble.com>


...
My earlier email requires too much reading between the lines. This one puts
the finger more closely on the issues: There are historical inconsistencies
and there are design flaws. Naturally, there often is an overlap, but there
is also a clear area of excellence. These are largely different things and
they should not be so easily confused.

Regards, Mark.


Mark Difford wrote:
> 
> Dimitris Rizopoulos wrote:
> 
>>> in my opinion the point of the whole discussion could be summarized by
>>> the question, what 
>>> is a design flaw? This is totally subjective, and it happens almost
>>> everywhere in life. 
> 
> This [what constitutes a design flaw, and the suggestion that all design
> flaws are subjective] needs to be more carefully defined, and cannot, or
> should not, be allowed to fly untested. People do die from time to time
> because of design flaws. In recent times, two well-known car companies had
> serious design flaws that led to several deaths.
> 
> Needless to say [perhaps], design flaws in software can have serious
> consequences. So-called "design flaws" in a language are unlikely to. So
> there are some fundamental, and important, differences between them.
> Usually, respondents on this list are very careful not to confuse apples
> with birds, or to try to compare them.
> 
> Regards, Mark.
> 
> 
> Berwin A Turlach wrote:
>> On Tue, 24 Feb 2009 09:39:51 +0100
>> Wacek Kusnierczyk <Waclaw.Marcin.Kusnierczyk at idi.ntnu.no> wrote:
>> 
>>> Berwin A Turlach wrote:
>> 
>> [...]
>>> why not read some fortunes?
>> I am well aware of those fortunes and maybe you missed the one:
>> 
>>> fortune("Watson")
>> 
>> Getting flamed for asking dumb questions on a public mailing list is
>> all part of growing up and being a man/woman.
>>    -- Michael Watson (in a discussion on whether answers on R-help
>>       should be more polite)
>>       R-help (December 2004)
>> 
>> I am actually wondering where the corresponding fortunes from December
>> 2005, December 2006, December 2007 and December 2009 are since they
>> started of be produced on an annual basis.
>> 
>> [...]
>>>>> on the other hand, i have seen quite a few responses that were
>>>>> bashing a user for reporting a non-existent bug or submitting an
>>>>> annoying patch.
>>>>>     
>>>> In didactic terms those are "negative motivations/reinforcements";
>>>> opinion differ on how effective they are to reach certain learning
>>>> outcomes.   
>>>>   
>>> ah, so what's the difference between the way i pinpoint design flaws
>>> and the way r gurus respond to people, so that i am running with a
>>> chip on my shoulder, and they are being 'negatively
>>> motivating/reinforcing' in didactic terms?  [...]
>> 
>> Your goal is, presumably, that you want to have the design flaws
>> fixed/discussed/&c.  The goal of the R gurus is to avoid having to
>> waste their time on unproductive issues because people do not read
>> documentation/behave contrary to how they are asked to behave/&c.
>> 
>> To reach your goal, the controversial approach is counter productive.
>> To reach their goal, the controversial approach can be quite effective.
> 
> in my opinion the point of the whole discussion could be summarized by 
> the question, what is a design flaw? This is totally subjective, and it 
> happens almost everywhere in life. Take human languages as an example 
> and in particular, English. I do not know the history of the English 
> language but I can guess at some point some people decided that the past 
> tense for "give" should be "gave" and not "gived" according to the 
> standard rule, possibly because they thought it has better acoustic.
> 
> Is this a design flaw of English? Some might argue yes, maybe they would 
> think "gived" does not have a that bad acoustic or they could have come 
> up with another possibility than "gave". Does this confuse new users of 
> English? Of course it does -- I had to spent many hours learning the 
> past tense and past particle of the irregular verbs. Should it be 
> changed? Then almost all existing code (i.e., English texts) should be 
> rewritten, which I think demonstrates why some people are a bit 
> reluctant in design changes.
> 
> To close I'd like to share with you a Greek saying (maybe also a saying 
> in other parts of the world) that goes, for every rule there is an 
> exception. The important thing, in my opinion, is that these exceptions 
> are documented.
> 
> Best,
> Dimitris
> 
> 
>> [...]
>>>>> it has been fixed immediately by martin. 
>>>>>     
>>>> Yes, and, again, you could not help yourself telling the developers
>>>> what you think they should do, could you?  
>>> was this really running with a chip:
>> 
>> Look up what "running with a chip on your shoulder means" and reflect
>> on the occasions in which I suggested to you that you give the
>> impression of doing so.   On this occasion nobody said that you were
>> running around with a chip on your shoulder.
>> 
>>> "shouldn't the tests have captured it? i think you should have a check
>>> for every feature following from the docs."
>>>
>>> to which marting responded "yes, we should"
>> 
>> But he also made it clear that it would be unlikely that he or any
>> other R-core member would write those tests and that this would
>> probably be left to you; with any contribution being welcome.  Consider
>> yourself lucky that this exchange was with Martin, other members of R
>> core might have communicated a similar message in quite another way.
>> That exchange is very much confirming my understanding of the culture
>> of the R community.
>> 
>>>> As I try to tell you, that
>>>> is not the way it works.  R comes already with extensive tests that
>>>> are run with "make check".  If you think some are missing, you
>>>> could send a script and propose that they are included.  But
>>>> telling others that they should write such tests is unlikely to
>>>> make it happen. 
>>> haven't done the thing.
>> 
>> Come on, read your own quote above:  "Shouldn't the tests have captured
>> this?  I think you should have a check for every feature following from
>> the docs",  If this is not "telling others that they should write such
>> test", then what is?  
>> 
>> Cheers,
>> 
>> 	Berwin
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> -- 
> Dimitris Rizopoulos
> Assistant Professor
> Department of Biostatistics
> Erasmus University Medical Center
> 
> Address: PO Box 2040, 3000 CA Rotterdam, the Netherlands
> Tel: +31/(0)10/7043478
> Fax: +31/(0)10/7043014
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 



-- 
View this message in context: http://www.nabble.com/Re%3A--R--Semantics-of-sequences-in-R-tp22152063p22184447.html
Sent from the R devel mailing list archive at Nabble.com.



[Rd] [R] Semantics of sequences in R
Mark Difford