R devel - Mar 2013 - R-devel Digest, Vol 121, Issue 20

I am not in favor of the change, which is a choice of rigor over usability.

When I am developing code or functions I agree with this, and I view any
warnings from R
CMD check about shortened arguments as positive feedback.

But 90% of my usage of R is day to day data analysis, interactive, at the
keyboard.  A lot
of data sets that come to me have long variable names.  What this change will
mean to me
is that I'll either spend a lot of time cursing at these annoying frickin
warnings, or
have to take the time to make new data sets (several times a week) that have
abbreviated
names.  Of course when I come back to that project 8 weeks later I'll need
to recreate the
short-long mapping in my head...

Let's think about WHY abbreviated names were allowed in the first place. 
Usability is
worth a lot more than purity to the actual users of a package.  S had the rare
advantage
of serious users just down the hall from the developers, which I hypothesise is
one of the
true foundation for it's success.  (What user would have invented the hiding
aspect S4
classes --- "let's put the results of the fit into a steel box so they
can't see the
parts" --- which is actually touted as a virtue?  I cringe every time a new
method I need
is sewed up this way.)

"C is a remarkable language.  ... The success of C is due to a number of
factors, none of
them key, but all of them important. Perhaps the most significant of all is that
C was
developed by real practioners of programming and was designed for practical
day-to-day
use, not for show or for demonstration. Like any well-designed tool, it falls
easily to
the hand and feels good to use. Instead of providing constraints, checks and
rigorous
boundaries, it concentrates on providing you with power and on not getting in
your way."
    Preface to "The C Book", M Banahan et al


Terry Therneau


On 03/21/2013 06:00 AM, r-devel-request@r-project.org
wrote:
> Allowing partial matching on $-extraction has always been a source of
accidents.
> Recently, someone who shall remain nameless tried names(mydata) <-
"d^2" followed by
> mydata$d^2. As variables in a data frame are generally considered similar
to variables
> in, say, the global environment, it seems strange that foo$bar can give you
the content
> of foo$bartender. In R-devel (i.e., *not* R-3.0.0 beta, but 3.1.0-to-be)
partial matches
> now gives a warning. Of course, it is inevitable that lazy programmers will
have been
> using code like
>> >  
	[[alternative HTML version deleted]]

Le jeudi 21 mars 2013 ? 08:51 -0500, Terry Therneau a ?crit
:
> I am not in favor of the change, which is a choice of rigor over usability.
> 
> When I am developing code or functions I agree with this, and I view any
warnings from R
> CMD check about shortened arguments as positive feedback.
> 
> But 90% of my usage of R is day to day data analysis, interactive, at the
keyboard.  A lot
> of data sets that come to me have long variable names.  What this change
will mean to me
> is that I'll either spend a lot of time cursing at these annoying
frickin warnings, or
> have to take the time to make new data sets (several times a week) that
have abbreviated
> names.  Of course when I come back to that project 8 weeks later I'll
need to recreate the
> short-long mapping in my head...
> 
> Let's think about WHY abbreviated names were allowed in the first
place.  Usability is
> worth a lot more than purity to the actual users of a package.  S had the
rare advantage
> of serious users just down the hall from the developers, which I
hypothesise is one of the
> true foundation for it's success.  (What user would have invented the
hiding aspect S4
> classes --- "let's put the results of the fit into a steel box so
they can't see the
> parts" --- which is actually touted as a virtue?  I cringe every time
a new method I need
> is sewed up this way.)
> 
> "C is a remarkable language.  ... The success of C is due to a number
of factors, none of
> them key, but all of them important. Perhaps the most significant of all is
that C was
> developed by real practioners of programming and was designed for practical
day-to-day
> use, not for show or for demonstration. Like any well-designed tool, it
falls easily to
> the hand and feels good to use. Instead of providing constraints, checks
and rigorous
> boundaries, it concentrates on providing you with power and on not getting
in your way."
>     Preface to "The C Book", M Banahan et al
I would think that the ability to hit the Tab key to trigger name
completion in your R GUI makes partial matching almost useless. The
avantage of interactive completion in the GUI is that you immediately
see the result of the partial matching. So you get the best of both
worlds: no need to type long variable names in full, but no traps when a
match is not what you would expect.

Doesn't this suit your use case?


Regards
> Terry Therneau
> 
> 
> On 03/21/2013 06:00 AM, r-devel-request at r-project.org wrote:
> > Allowing partial matching on $-extraction has always been a source of
accidents.
> > Recently, someone who shall remain nameless tried names(mydata) <-
"d^2" followed by
> > mydata$d^2. As variables in a data frame are generally considered
similar to variables
> > in, say, the global environment, it seems strange that foo$bar can
give you the content
> > of foo$bartender. In R-devel (i.e., *not* R-3.0.0 beta, but
3.1.0-to-be) partial matches
> > now gives a warning. Of course, it is inevitable that lazy programmers
will have been
> > using code like
> >> >  
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel