Can't there be a cd command?

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Jan T. Kim
On Wed, May 10, 2006 at 12:56:23PM -0400, Duncan Murdoch wrote:

> On 5/10/2006 12:15 PM, Jan T. Kim wrote:
> > On Wed, May 10, 2006 at 11:26:55AM -0400, Duncan Murdoch wrote:
> >> On 5/10/2006 11:10 AM, Gabor Grothendieck wrote:
> >> > On 5/10/06, Duncan Murdoch <[hidden email]> wrote:
> >
> >> >> What is it that you find objectionable about having a default for the
> >> >> file argument in read.table?  I think Martin has said that he doesn't
> >> >> want non-UI functions to be involved with UI functions, but I don't see
> >> >> that:  if your code works now, it will be completely unaffected by
> >> >> setting a default for the argument.  (Sorry if I summarized the argument
> >> >> incorrectly, Martin, I didn't look it up.)
> >> >
> >> > That would be my objection too.  UI should not be tied to the non-UI core.
> >> > Its basically a loose coupling argument.
> >>
> >> I don't accept that argument, because in R everything* is interactive.
> >> There isn't a non-UI core.  The function arguments are part of the user
> >> interface.
> >
> > It seems to me that there might be a misunderstanding here; as the term
> > "user" is used to refer to a person interacting with the computer on
> > the one hand, and to refer to a programmer using R on the other hand.
>
> One of the design goals of S and R is to blur the distinction between
> users and programmers.  It is a continuum.  R is designed to gently urge
> non-programmers to become programmers, because the designers think
> that's the way statistical computing should be done.

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

> > Everything being "part of the user interface", in the sense of
> > every user-visible function being part of the API, does not and should
> > not imply that everything should be interactive.
>
> No, I didn't suggest that.  What I was suggesting is that it should be
> *convenient* to use read.table interactively, not that it should be
> required.  (It's already possible, but not convenient, especially for a
> beginner who doesn't know the secret incantation.)

Well, not knowing a secret is always inconvenient...  ;-)

> > In my experience, interactivity is a rather double-edged thing: On the
> > one hand, it facilitates learning and exploration, but on the other
> > hand, its improper use is frequently detrimental to reproducibility of
> > scientific computation.
>
> I definitely agree with that.  It should be convenient to use R
> non-interactively as well.  Anyone who wants reproducibility should be
> writing packages and scripts or vignettes that run non-interactively.

Ok, I fully agree with this -- seems that I've interpreted the statement
that "in R everything is interactive" a bit too narrowly.

> That's why I am emphasizing that this change will have no effect on
> existing code.  I wouldn't suggest it if it did.

That's an important point too, obviously.

I'm not entirely convinced about the convenience aspect, as I find file
choosers of all sorts disruptive to workflow... but that's perhaps a
matter of personal taste.

Best regards, Jan
--
 +- Jan T. Kim -------------------------------------------------------+
 |             email: [hidden email]                               |
 |             WWW:   http://www.cmp.uea.ac.uk/people/jtk             |
 *-----=<  hierarchical systems are for files, not for humans  >=-----*

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Bugzilla from manuellopezibanez@yahoo.es
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

               
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Gregory Snow
In reply to this post by Issac Trotts
When talking about user friendlyness of computer software I like the analogy of cars vs. busses:

Busses are very easy to use, you just need to know which bus to get on, where to get on, and where to get off (and you need to pay your fare).  Cars on the other hand require much more work, you need to have some type of map or directions (even if the map is in your head), you need to put gas in every now and then, you need to know the rules of the road (have some type of drivers licence).  The big advantage of the car is that it can take you a bunch of places that the bus does not go and it is quicker for some trips that would require transfering between busses.

Using this analogy programs like SPSS are busses, easy to use for the standard things, but very frustrating if you want to do something that is not already preprogrammed.

R is a 4-wheel drive SUV (though environmentally friendly) with a bike on the back, a kayak on top, good walking and running shoes in the pasenger seat, and mountain climbing and spelunking gear in the back.

R can take you anywhere you want to go if you take time to leard how to use the equipment, but that is going to take longer than learning where the bus stops are in SPSS.

Now there are tools like Rcmdr that help get you started (maybe a gps unit in the R suv above), but if we make R too user friendly then we limit what can be done with it.

I think the volume of mail in R-help is partly due to lack of friendliness, but a lot of it is due to the flexibility as well, if it did less, there would be less to learn and ask questions about.  I for one prefer to do a little more work learning the program in exchange for being able to do a lot more with it.


To mangle a famous Einstien quote:  "Statistical packages should be made as user friendly as possible, but no friendlier."

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
[hidden email]
(801) 408-8111
 

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Manuel López-Ibáñez
Sent: Wednesday, May 10, 2006 2:19 PM
To: [hidden email]
Subject: Re: [R] Can't there be a cd command?

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

               
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Bert Gunter

...another fortunes package candidate? I especially liked the sections
beginning "R is a 4 wheel drive SUV...", but a lot of it is great IMHO. Well
said! Bestimmt!

-- Bert

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Greg Snow
> Sent: Wednesday, May 10, 2006 1:37 PM
> To: [hidden email]
> Subject: Re: [R] Can't there be a cd command?
>
> When talking about user friendlyness of computer software I
> like the analogy of cars vs. busses:
>
> Busses are very easy to use, you just need to know which bus
> to get on, where to get on, and where to get off (and you
> need to pay your fare).  Cars on the other hand require much
> more work, you need to have some type of map or directions
> (even if the map is in your head), you need to put gas in
> every now and then, you need to know the rules of the road
> (have some type of drivers licence).  The big advantage of
> the car is that it can take you a bunch of places that the
> bus does not go and it is quicker for some trips that would
> require transfering between busses.
>
> Using this analogy programs like SPSS are busses, easy to use
> for the standard things, but very frustrating if you want to
> do something that is not already preprogrammed.
>
> R is a 4-wheel drive SUV (though environmentally friendly)
> with a bike on the back, a kayak on top, good walking and
> running shoes in the pasenger seat, and mountain climbing and
> spelunking gear in the back.
>
> R can take you anywhere you want to go if you take time to
> leard how to use the equipment, but that is going to take
> longer than learning where the bus stops are in SPSS.
>
> Now there are tools like Rcmdr that help get you started
> (maybe a gps unit in the R suv above), but if we make R too
> user friendly then we limit what can be done with it.
>
> I think the volume of mail in R-help is partly due to lack of
> friendliness, but a lot of it is due to the flexibility as
> well, if it did less, there would be less to learn and ask
> questions about.  I for one prefer to do a little more work
> learning the program in exchange for being able to do a lot
> more with it.
>
>
> To mangle a famous Einstien quote:  "Statistical packages
> should be made as user friendly as possible, but no friendlier."
>
> --
> Gregory (Greg) L. Snow Ph.D.
> Statistical Data Center
> Intermountain Healthcare
> [hidden email]
> (801) 408-8111
>  
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Manuel
> López-Ibáñez
> Sent: Wednesday, May 10, 2006 2:19 PM
> To: [hidden email]
> Subject: Re: [R] Can't there be a cd command?
>
> 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
>
>
> ______________________________________________
> LLama Gratis a cualquier PC del Mundo.
> Llamadas a fijos y móviles desde 1 céntimo por minuto.
> http://es.voice.yahoo.com
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide!
> http://www.R-project.org/posting-guide.html
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide!
> http://www.R-project.org/posting-guide.html
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Achim Zeileis
On Wed, 10 May 2006 13:51:06 -0700 Berton Gunter wrote:

> ...another fortunes package candidate?

Hehe, yes, this time I was quicker ;-)

> I especially liked the sections
> beginning "R is a 4 wheel drive SUV...", but a lot of it is great
> IMHO. Well said!

Indeed.

> Bestimmt!

Ja, das auch...
Z

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Robert Citek
In reply to this post by Gregory Snow

On May 10, 2006, at 3:37 PM, Greg Snow wrote:
> R is a 4-wheel drive SUV (though environmentally friendly) with a  
> bike on the back, a kayak on top, good walking and running shoes in  
> the pasenger seat, and mountain climbing and spelunking gear in the  
> back.

But mapping R to a SUV makes R sound too much like a car, which many  
people know how to drive.  That is, someone who knows how to drive a  
car pretty much knows how to drive an SUV.  The SUV analogy implies  
that someone who knows another computer languages, e.g C, perl, VB,  
Java, SQL, would be able to use R.  Unfortunately, that is in all  
likelihood not the case.  R has a rather specialized syntax it uses  
to manipulate data.  It's not like C or perl or VB or Java or SQL.  
So, knowing those languages helps a little but not much.

Because of that, I would say R is more like a helicopter, a HUEY  
perhaps.

Regards,
- Robert
http://www.cwelug.org/downloads
Help others get OpenSource software.  Distribute FLOSS
for Windows, Linux, *BSD, and MacOS X with BitTorrent

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: metaphoRs - was Can't there be a cd command?

barry rowlingson
Robert Citek wrote:

> Because of that, I would say R is more like a helicopter, a HUEY  
> perhaps.

  I vote for unicycle. I've seen people race, skip, climb stairs, go up
mountains, dance and even play hockey on unicycles. But when I get on
one, all I can do is fall off. I know all these other feats are
possible, but I can't do it.

  That's how a beginner in R feels, isn't it?

Barry

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

joerg van den hoff
In reply to this post by Bugzilla from manuellopezibanez@yahoo.es
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.

I don't think programming R is easier than programming C, for example.
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.

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

joerg

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Rolf Turner-2
In reply to this post by Issac Trotts

Duncan Murdoch wrote (amongst other things):

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

        Well expressed, Duncan!  (A slam Dunc, one might say. :-) )

                        cheers,

                                Rolf

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

P Ehlers
Rolf Turner wrote:

> Duncan Murdoch wrote (amongst other things):
>
>
>>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.
>
>
> Well expressed, Duncan!  (A slam Dunc, one might say. :-) )
>
> cheers,
>
> Rolf
>

I agree - well said! The only thing Duncan missed is that the volume
is high partly because there are quite a few people who want to use R
without reading any documentation. But is it just my imagination or
is that type of post on the decrease?

Peter Ehlers

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Marc Schwartz (via MN)
In reply to this post by Rolf Turner-2
On Tue, 2006-05-16 at 17:49 -0300, Rolf Turner wrote:

> Duncan Murdoch wrote (amongst other things):
>
> > 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.
>
> Well expressed, Duncan!  (A slam Dunc, one might say. :-) )
>
> cheers,
>
> Rolf

In looking back at the archive, I don't see an indication of someone
suggesting that Duncan's prose might be a candidate for the fortunes()
package, unless Achim has already done so...  :-)

Regards,

Marc

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Achim Zeileis
On Tue, 16 May 2006 16:50:36 -0500 Marc Schwartz (via MN) wrote:

> On Tue, 2006-05-16 at 17:49 -0300, Rolf Turner wrote:
> > Duncan Murdoch wrote (amongst other things):
> >
> > > 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.
> >
> > Well expressed, Duncan!  (A slam Dunc, one might say. :-) )
> >
> > cheers,
> >
> > Rolf
>
> In looking back at the archive, I don't see an indication of someone
> suggesting that Duncan's prose might be a candidate for the fortunes()
> package, unless Achim has already done so...  :-)

...I was waiting for someone to suggest it ;-) Done now. We're also
beginning to have enough new fortunes for a new release...will try to
put it out soon.

Best,
Z

> Regards,
>
> Marc
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide!
> http://www.R-project.org/posting-guide.html
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

joerg van den hoff
In reply to this post by Duncan Murdoch
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Reply | Threaded
Open this post in threaded view
|

Re: Can't there be a cd command?

Bugzilla from manuellopezibanez@yahoo.es
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
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
12