R design (was "Variable passed to function not used in function in select)
On 11/11/2008 10:28 AM, Terry Therneau wrote:
I've read the back and forth this morning, and I have to side with Vince. 1. Functions that re-interpret their arguments are very dangerous. The original question involved a well formed call to a function, which returned the wrong answer. Bug, design flaw, whatever -- it's a mistake and the best choice would be to fix it. I only consider such behavior in 2 cases: a. when the function is almost never, ever, called from anything but the top level. help() is the only example I can think of. b. to create a label from an argument, as in plot, but the argument itself is left alone to work as it should.
There's another major use for this: model formulas. I like to be able to write lm(y ~ ., data=df), and I'd really hate to have to evaluate all the terms in a model formula explicitly.
One possible fix for subset: first treat the argument formally, and only if that simple interpretation fails try the more 'clever' interpretations. Whether this is doable or not I can't say.
2. The documentation of subset is not in any way clear. I would never have been able to diagnose or work around this bug. The issues are very subtle. I quite often see "it's in the manual so we bear no blame" as an argument on this list. We all need to remember that our view of what we are particularly close to is a distorted one -- I for instance think that everything about the survival package is crystal clear --- and be particularly open to concerns that something is opaque or subtle. 3. I've heavily used perhaps 20 computing languages in my life. I found S to be a refreshing revalation (referring to S of the 1988 Blue manual) precisely because it was completely functional. Once I got used to it, this feature made it so much more useful, extensible, understandable than other things I'd used.
I don't know your definition of "completely functional", but I don't think S and R have ever been. It has always been possible to refer to non-local variables within a function (and their meaning is different between S and R, but I think R tends to be a bit more functional in this), to make super-assignments, to do lots of things that have side effects.
R is becoming less and less a functional language (hidden functions and dependencies with environments for one), I quite often cannot figure out either exactly what a function calls or how to get it to stop doing it.
I don't know what you mean here. Are you talking about recent changes? (Which ones?) Or are you talking about older things, like namespaces? Or closures, which have been in R from the beginning (and which are part of why I'd call it more functional than S)? I am not sure
we have gained with each choice of "convenience" or sophistication over functional purity. I want "scan(file=myfile)" to continue to return "variable myfile not found" when I forget the quotes.
R allows a lot of flexibility in how arguments are handled, and there's been some experimentation with different variations. Remember that R is partly a laboratory in which people are trying to invent new ways of doing statistical computing, and also remember that R (including its contributed packages) has hundreds of authors, not all of whom agree on the best way to do things. The benefit of this is that more stuff gets done: I'm not forced to adopt your ideas of The Right Way to Do Things, so I can get down to coding in the way I like. The disadvantage is that things can be inconsistent, so people are forced to read the documentation, and the documentation is always imperfect.
I am stumped by the R results I get too often, and I'm not a novice. That said, good design is hard. I spend a lot of time on that aspect in the survival package and there are still bits where the 'right' way is only clear after several years experience. I do occassionaly make non-backwards compatable changes. The R core team has done an amazing job on the whole.
If I'm not mistaken, you are still an S user as well as an R user, and this is a bit of a disadvantage: at a fundamental level, they are different languages, though they look superficially similar. I haven't used S in quite a few years, so I expect I'd be stumped by the results I got there in a lot of cases. I think that in the main R is a simpler, easier language to understand, but there are certainly bits and pieces of it where it is not easy.
And let's not shoot the bearers of bad news.
I think we can discuss what's good and what's bad about the language without bringing out the guns or insults. Duncan Murdoch