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

[Joerg van den Hoff]

Duncan Murdoch wrote:
> 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.
well, as far as my english goes, 'sloppy' is a strong word (and apart
from mathematicians physicists (my background) probably are the people
who are most allergic to being accused of it :-)) and it's an overhasty
conclusion on your side, I'd say.

I want to make clear beforehand, that I do _not_ think this a very
important discussion, but rather an informal exchange of opinions, so
maybe this takes us all a bit to far, but anyway:

for one, I myself (and I think manuel, too) was not talking of the shear
volume of mails (this obviously would have to be 'calibrated' against
the total number of R users and the resulting quantity had to be
compared to other help-lists). at least my impression is, that there are
a number of reoccuring  difficulties in the mail, which are rather
specific to R's design (whether this situation could or should be
altered: that would be a different topic). certainly, among these are
the subsetting/indexing issues, certainly lazy evaluation, certainly
anything related to environments, namespaces, computing  on the language
(substitute, eval, ...).
> 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 did'nt quote anyone AFAIKS, so I can't have misquoted anyone (having
misinterpreted someone I cannot rule out). the 'easy to use' did not
refer to a special statement from this thread, but to the general
impression one can get from the list and contributed as well as official
manuals (I only checked now: the 'what is R?' section on the homepage
contains one 'ease', one 'easy', one 'easily' within a total of two or
three paragraphs...).

it is pointless to dwell on this to long: what is easy for you might be
difficult for me or vice versa, depending on the question to answer/
problem to solve. _if_ I take the freedom to interpret it as 'easy for
the pedestrians', the statements are simply not true ("easily extended
via packages"??).

with reference to the idea of urging people to programm: well, the idea
in itself is not objectionable, the question is how realistic the
approach is (i.e. how large will be the success rate of getting people
to programm, which otherwise would'nt have done _and_ is this rate
larger in R than in the other packages?).
> 
>> 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.
this is all very well, though I only partly agree, but this a very
technical assessment anyway and seems to indicate that a non-programmer
will not be much better off with R as a 'starting language' than with C
(since your criteria mostly will not be initially 'operational'). I
_bet_ this starting phase would be easier with MATLAB/octave (but I'm
not arguing for pushing beginners to MATLAB!).
> 
> 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.
yepp. and cascaded apply/lapply calls, I'd add.
> 
> So R is not easy, but it's easier than C.
by a margin, maybe, though I have people in my group who definitely do
object (making especially a point of the fact that they have
difficulties to rapidly read/understand their own R code after a few
month which they do not experience with  their C++ stuff...)
> 
>> 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.
I'm afraid that really is a (rather widespread) misconception on the
side of R aficionados and R's "inner circle" that R distinguishes itself
in this respect from the other packages (let's stick for comparison with
matlab, octave, idl as being 'scientific/numerical' packages (root is
rather 'heavy weight' in comparison)). I think the average user of R and
octave, say, will behave the same: if it's easy, do it interactively, if
it requires more than a handful of commands or plotting some data for a
check, than write a script (probably the best thing to do even it it
could be done interactively), if it's a permanent reoccuring serious
task, write a full-fledged program/package.

if your assessment were true, their should be some real indication/proof
that

1.) interactive use of R is easier (faster) than that of, say, octave,
for doing some standard manipulation of data (say subsetting, summary
statistics, matrix algrebra, data exploration/plotting) _and_ that

2.) coding small scripts/functions/programms to solve some specific
problem (max. a few 100 lines of code) is easier (for the willing and
capable, but unexperienced newcomer) in R (meaning taking less time to
get it running).

on the _average_ this won't be the case (of course one can choose
suitable examples to "prove" superiority of one or the other system, but
that's not the point).
> 
>>
>> 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.

you need not convince me, anyway.

but your emphasis on 'statistical computing' is off the mark, at least
with regards to what I was trying to say:

I was not focusing on R's "core competence" in statistical computing
(which simply is not there in the other packages).

I was not not talking about using the "statistical" algorithms and
techniques correctly (to do this, I must understand them in mathematical
terms -- again nothing you'd expect in non-experts--, which is not a
task that R has really anything to do with).

I was talking about the general properties of the language and the
general "numerical" and 'exploratory' capabilities (matrix algebra,
linear equations, optimization, plotting, ...) and use thereof.

to make a last point: what at times is irritating (I'm not addressing
you here) is that a nearly dogmatic, at least zealous, and (luckily very
rarely even an elitist) tone creeps in on the R lists if some
'ignoramus' is critizising the state of affairs even concerning
ultra-marginal details, such as the question whether there could not be
a 'cd' command (this was starting the thread, by the way...): well, it's
not there, so be it, I don't care. but to 'invent' lengthy theoretical
arguments against 'cd' in comparsion to 'setwd' to 'defend' R is a
strange thing to see.

I think R's strengths and advantages are obvious enough that a more
relaxed approach would be in place sometimes.

joerg
> 
> Duncan Murdoch