[R] Can't there be a cd command?

[Duncan Murdoch]

On 5/16/2006 5:46 AM, Joerg van den Hoff wrote:
> Manuel López-Ibáñez wrote:
>> Jan T. Kim wrote:
>>> That's an idea I like very much too -- much better than the currently
>>> popular idea of "protecting" users from the "unfriendliness" of
>>> programming, anyway...
>>>
>> 
>> It is just my opinion that the amount of mail in R-help speaks volumes 
>> about the current "friendliness" [1], or lack thereof, of R. Perhaps I 
>> am just the only one who thinks this way...
>> 
>> [1] http://en.wikipedia.org/wiki/Usability
>> 
>> 		
> 
> I think you are 100% right: the r-help list says it all. needless to 
> say, R is a great achievment without any doubt, but claiming that it's 
> easy to use (beyond the most basic arithmetics) is really wishful thinking.

This is sloppy thinking.  The volume of mail here shows that there are a 
lot of questions, perhaps because there are a lot of users.
You're also misquoting Jan:  he didn't say R was "easy to use", he said 
that the idea of urging people to program is better than trying to be 
too friendly and protecting them from it.

> I don't think programming R is easier than programming C, for example. 

I do both, and I think R programming is easier.  It has a more sensible 
idea of scoping, it doesn't have the preprocessor doing bizarre 
transformations to the text, it doesn't have pointers writing to random 
memory locations, it can handle strings much more sensibly.

On the negative side, the vector orientation of R encourages people to 
come up with clever APL-style one-liners that are unreadable; the lack 
of type declarations, the weird handling of indexing, the strange object 
oriented programming models all make R programming hard.

So R is not easy, but it's easier than C.

> This is not to say that it takes the same time to solve the same problem 
> in both languages, since in R many, many things are already there 
> (either in the language (vectorized computations) or in the packages). 
> but the quantity 'number of new lines of working code per hour' should 
> be about the same.
> 
> I have used MATLAB/octave previously. in comparison to R, the MATLAB 
> language sure is not pretty, not consistent and less powerful, but 
> without any question easier. and of course, the interactive use is 
> facilitated by the absence of lots of paranthesis and quotes and the 
> way, unknown commands are resolved by looking them up in the search path.
> 
> but that's not a situation, one should complain about: R simply cannot 
> be everybody's darling.
> 
> what I always find a bit strange is the explicit claim/aim to blur the 
> distinction between users and programmers: one could postulate the same 
> aim (or property) for MATLAB, octave, IDL, or even any other language 
> providing an interactive interpreter (python, ruby, Tcl, C++/Cint/root, 
> ...). in my experience the distinction between users (rather: 
> non-programmers) and programmers always is quite sharp.

If that's really the aim of those other packages (and I don't think so), 
then I think you're just saying that those other packages are quite 
unsuccessful.  I don't think it is.  I think those other packages are 
designed for programmers.

> 
> again, in comparison to MATLAB (where I have some experience) I have 
> noted that the 'users' (a.k.a. non-programmers) have more difficulties 
> in using R interactively, mainly for the following reasons:
> 
> - difficulties in understanding the neccessety for all those paranthesis
>    (why can't I just say 'ls'?)
> - subsetting ((x), [x], [[x]], $x, $"x", ['x'], ["x"], [["x"]], ... or 
> what!?)
> - R's strong functional orientation: R encourages writing functions with 
>   _lots_ of arguments which you must understand/know of (even if you 
> don't touch the defaults) and the user must construct the suitable 
> function call and launch it to get his/her results.
> 
> of course one can write interactive ('please enter ...') programms, but 
> usually does'nt since it 's much more convenient from the programmers 
> point of view to utilize the functional approach). in a way R's 
> functions behave like UNIX commands including lots of command line 
> parameters: they are great for experienced
> users but the average guy neither understands
> 
> tar    c[bBDeEfFhiklnopPqvwX@[0-7]]    [block]     [tarfile]
>       [exclude-file]  {-I include-file  |  -C directory  |  file |
>       file} ...
> 
> nor
> 
> plot(x, y = NULL, type = "p",  xlim = NULL, ylim = NULL,
>            log = "", main = NULL, sub = NULL, xlab = NULL, ylab = NULL,
>            ann = par("ann"), axes = TRUE, frame.plot = axes,
>            panel.first = NULL, panel.last = NULL,
>            col = par("col"), bg = NA, pch = par("pch"),
>            cex = 1, lty = par("lty"),
>            lwd = par("lwd"), asp = NA, ...)
> 
> easily.
> 
> so, to make a long story short: it would'nt harm avoiding the claim that 
> R is 'easy'.  it's probably more of the "you either love it or hate it" 
> variety (so the unicycle metaphor occuring in this thread fits very 
> well, I believe).

Statistical computing is not easy, so how could R be?  Who has ever 
claimed it is?  Any package that makes statistical computing appear to 
be easy is probably giving you wrong answers half the time, or is 
extremely limited in scope.

Duncan Murdoch