Bert,
Thanks for your reply. I suspect we agree more than you might think....
Comments inline below. I've snipped out parts.
-s
On Thu, Dec 11, 2008 at 2:45 PM, Bert Gunter <gunter.ber...@gene.com> wrote:
> Rationale? -- you'll have to ask the developers....
Hmm. It would be nice if this could be documented for new users -- and for
posterity. But I admit that other projects I have worked on don't do a
particularly good job of documenting such things, either.
> As for deprecating (or changing) tapply: do you have any idea how much code
> that could break?! I think that is probably a wholly unrealistic
> suggestion....
>
Ah, perhaps my terminology isn't clear. In the programming world,
"deprecating" (as opposed to removing or changing) a feature means declaring
it obsolete and not-to-be-recommended (or as you put it "somewhat obscure
and even annoying") while continuing to support it for backwards
compatibility. So tapply would continue to exist and to work both for
legacy code and for users who prefer it, but it would not be taught to new
users, and its documentation would cross-reference the currently recommended
approach.
The way forward is through efforts like Hadley's plyr package....
Agreed, and ideally the user and developer community would eventually
converge on one or another such package and integrate it into the core
system, to avoid balkanization of the user community.
> ...packages like R.oo and proto allow one to use a whole different
> programming language/paradigm within R, while still taking advantage of all
> of R's existing built-in functionality. Except for possible performance
> penalties, I don't see how you can ask for much more than that....
I certainly agree that exploring other approaches in add-on packages is a
good thing. Even better to progressively deprecate features which are
"obscure and even annoying" at the same time.
> ...So, no, R is certainly not perfect. I'm sure that if they could go back
> 20
> years with today's knowledge and experience, the developers would do some
> things differently....
We cannot change the past, but we can make a better future without hurting
current users!
...any objective assessment -- and certainly those of us who use it day in
> and day out in our
> work -- would consider R a truly amazing software product, warts or no....
>
I agree entirely -- I have come to use R after considering a variety of
alternatives for my work, and am delighted with its functionality and strong
user community. I admit, though, that the learning curve has been
surprisingly steep, largely because of design inconsistencies and
idiosyncratic terminology.
> Hence, may I suggest that instead of merely pointing out its (often well
> known,btw) imperfections and inelegancies, you instead move to the
> developers' forum and contribute improvements. This is, I believe, a
> standard way for people with programming expertise like yourself to
> contribute to open source development....
Agreed, and I have contributed to Maxima over the years. I am quite new to
R, though, and just getting my bearings. I haven't even looked at the
underlying implementation yet. I do intend to contribute in the future.
-s
[[alternative HTML version deleted]]
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
