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

[Manuel López-Ibáñez]

Hi,

I am afraid this discussion is going into the wrong direction. I do 
agree with some comments of Joerg van den Hoff, however, I cannot adhere 
to some things said in the last paragraphs. I was just expressing a 
personal observation and I was expecting many people to have disagree 
and perhaps very few to agree.

However, it was just an opinion. Unfortunately, during the next months I 
am going to have little free time, so I cannot: (1) gather examples of 
"usability" issues in R, (2) support them by user cases from R-help, (3) 
propose solutions and  put forth reasons and argue for the changes one 
by one.[*] In a software libre project, complaining without contributing 
is futile, pointless and even insulting to the people that do 
contribute. That is the reason why I did not send any further comments 
on this.

Of course, I would be very happy if someone (or some group) decided to 
start to work on this. However, as said before, I don't consider I have 
the right to tell anybody that they must do it. Thus, a discussion on 
whether "R is hard/easy" or "R has to be hard/easy" or "R is 
harder/easier than program/language X" or "R is like deciphering 
hieroglyphics / R is like piloting an Apache helicopter" is pointless in 
my opinion. So please, don't quote me or mention me in such kind of 
discussion. Please, don't even reply to such messages: there is already 
enough traffic in R-help.

Now, Joerg van de Hoff points out particular cases (like 
subsetting/indexing issues) where new users seem to always have 
problems. That is a better approach: focusing on actual cases. Still, 
more work needs to be done to identify where the problems are and how to 
solve them. That would imply to examine the reaction of users (from 
R-help or your own students), since your (my) personal experience is 
almost useless once you know the answer (magic syntax or workaround). 
Therefore, the value of "I think this is hard/easy because it is 
hard/easy for me" is close to zero. Such discussion may end up on people 
calling names and I don't want to be involved on that. I think working 
mainly off-list on particular proposals (perhaps sharing information in 
the R-Wiki) would be the ideal way to work on this. I am sorry I cannot 
invest more time on this at the present moment.


Regards,
	Manuel López-Ibáñez.


PS: by the way, I do use Perl, Emacs and LaTeX (almost everyday) and I 
think they are great, yet they could be improved in terms of usability.


[*] A clear candidate is the "cd" command. "cd" means change directory 
in Windows, Unix and dozens of applications. It can be argued that "ls" 
doesn't mean "list files". For me, the fact that "ls" has another 
meaning is just unfortunate and I understand that it may be problematic 
to change it. However, "cd" doesn't mean anything in R yet. Actually, 
there is a "dir" command. Could you guess what "dir()" does? If still 
you are not convinced, let it be, I cannot discuss this further (perhaps 
after summer).



Joerg van den Hoff wrote:
> 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
> 
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
>