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

From: Joerg van den Hoff <>
Date: Wed 17 May 2006 - 19:05:29 EST

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]

>> 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.

> Duncan Murdoch mailing list PLEASE do read the posting guide! Received on Wed May 17 19:10:53 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Thu 18 May 2006 - 04:10:10 EST.

Mailing list information is available at Please read the posting guide before posting to the list.