... 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.kusnierc...@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@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@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. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel