R is quite a powerful environment. Here's a small way it could be even better.
I wanted to change the working directory, so I tried the obvious thing
cd("foo")
Error: couldn't find function "cd"
Then I looked for `directory' in the FAQ but found nothing. A search
for directory in the introduction also turned up nothing.
A Google search for "gnu R change directory" brought up a link to the
Windows FAQ, and there was the answer: setwd. enough, setwd is
not mentioned in the general FAQ, the introduction, or the language
definition.
Hopefully someone can add a mention of setwd to the general FAQ or the
intro. Even better would be to have a cd() command, since that's what
almost every beginner will try first.
R-help (AT) stat (DOT) math.ethz.ch mailing list
PLEASE do read the posting guide!

I'm on Linux, so it didn't occur to me to look in the Windows FAQ
until it came up in the Google search. Why should Windows users be
the only ones who learn how to change directories?

Issac

5/9/06, Berton Gunter <gunter.berton (AT) gene (DOT) comwrote:
You do not say, but if you are on Windows see the R for Windows FAQ 2.14
where getwd() is explicitly mentioned. setwd() is on the same man page.

Also the R for Windows File menu has a "Change dir " entry. So I think R
core has already taken care of this, at least on Windows.

-- Bert Gunter
Genentech Non-Clinical Statistics
South San Francisco, CA

"The business of the statistician is to catalyze the scientific learning
process." - George E. P. Box
>
>
>
Message
From: r-help-bounces (AT) stat (DOT) math.ethz.ch
[mailto:r-help-bounces (AT) stat (DOT) math.ethz.ch] Behalf Issac Trotts
Sent: Tuesday, May 09, 2006 2:51 PM
To: r-help (AT) stat (DOT) math.ethz.ch
Subject: [R] Can't there be a cd command?

R is quite a powerful environment. Here's a small way it
could be even better.

I wanted to change the working directory, so I tried the obvious thing

cd("foo")
Error: couldn't find function "cd"

Then I looked for `directory' in the FAQ but found nothing. A search
for directory in the introduction also turned up nothing.

A Google search for "gnu R change directory" brought up a link to the
Windows FAQ, and there was the answer: setwd. enough, setwd is
not mentioned in the general FAQ, the introduction, or the language
definition.

Hopefully someone can add a mention of setwd to the general FAQ or the
intro. Even better would be to have a cd() command, since that's what
almost every beginner will try first.

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

>
>
>

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

I believe Berton Gunter was trying to be helpful, as you didn't
mention your operating system, rather than suggesting that Linux
users read the Windows FAQ.

However, when I type (under S X)

help.search("directory")

the 6th line returned is

getwd(base) Get or Set Working Directory

which seems clear enough.

Steve Buyske

At 3:11 PM -0700 5/9/06, Issac Trotts wrote:
>I'm on Linux, so it didn't occur to me to look in the Windows FAQ
>until it came up in the Google search. Why should Windows users be
>the only ones who learn how to change directories?
>
>Issac
>
5/9/06, Berton Gunter <gunter.berton (AT) gene (DOT) comwrote:
>You do not say, but if you are on Windows see the R for Windows FAQ 2.14
>where getwd() is explicitly mentioned. setwd() is on the same man page.
>>
>Also the R for Windows File menu has a "Change dir " entry. So I think R
>core has already taken care of this, at least on Windows.
>>
>-- Bert Gunter
>Genentech Non-Clinical Statistics
>South San Francisco, CA
>>
>"The business of the statistician is to catalyze the scientific learning
>process." - George E. P. Box
>>
>>
>>
>Message
>From: r-help-bounces (AT) stat (DOT) math.ethz.ch
>[mailto:r-help-bounces (AT) stat (DOT) math.ethz.ch] Behalf Issac Trotts
>Sent: Tuesday, May 09, 2006 2:51 PM
>To: r-help (AT) stat (DOT) math.ethz.ch
>Subject: [R] Can't there be a cd command?
>>
>R is quite a powerful environment. Here's a small way it
>could be even better.
>>
>I wanted to change the working directory, so I tried the obvious thing
>>
>cd("foo")
>Error: couldn't find function "cd"
>>
>Then I looked for `directory' in the FAQ but found nothing. A search
>for directory in the introduction also turned up nothing.
>>
>A Google search for "gnu R change directory" brought up a link to the
>Windows FAQ, and there was the answer: setwd. enough, setwd is
>not mentioned in the general FAQ, the introduction, or the language
>definition.
>>
>Hopefully someone can add a mention of setwd to the general FAQ or the
>intro. Even better would be to have a cd() command, since that's what
>almost every beginner will try first.
>>
>
>R-help (AT) stat (DOT) math.ethz.ch mailing list
>
>PLEASE do read the posting guide!
>
>>
>>
>>
>
>
>R-help (AT) stat (DOT) math.ethz.ch mailing list
>
>PLEASE do read the posting guide!

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/9/06, Prof Brian Ripley <ripley (AT) stats (DOT) ox.ac.ukwrote:
Wed, 10 May 2006, Peter Dalgaard wrote:

"Issac Trotts" <issac.trotts (AT) gmail (DOT) comwrites:
>
>I'm on Linux, so it didn't occur to me to look in the Windows FAQ
>until it came up in the Google search. Why should Windows users be
>the only ones who learn how to change directories?
>
Well, on Linux et al., the normal mode of operation is to start R from
the commmand line in the directory where you want to be. Windows
you start from a desktop icon or a menu entry, which implies that
you're always in the same directory, and usually the wrong one.

Exactly. I don't think I have ever used setwd() on Linux.

Also, I have never seen this asked before for a Unix-alike, so it seems
not to be a >F<AQ. There is a common tendency for users who run into a
problem to think everyone does too, and it isn't necessarily so.

Frequently asked questions do make it to the FAQs: it is a defence
mechanism for the volunteers supporting R.

help.search("directory") gets you there.

K, good to know. Thanks for helping.

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

Issac Trotts wrote:
5/9/06, Prof Brian Ripley <ripley (AT) stats (DOT) ox.ac.ukwrote:
>Wed, 10 May 2006, Peter Dalgaard wrote:
>>
"Issac Trotts" <issac.trotts (AT) gmail (DOT) comwrites:

I'm on Linux, so it didn't occur to me to look in the Windows FAQ
until it came up in the Google search. Why should Windows users be
the only ones who learn how to change directories?
Well, on Linux et al., the normal mode of operation is to start R from
the commmand line in the directory where you want to be. Windows
you start from a desktop icon or a menu entry, which implies that
you're always in the same directory, and usually the wrong one.
>Exactly. I don't think I have ever used setwd() on Linux.
>>
>Also, I have never seen this asked before for a Unix-alike, so it seems
>not to be a >F<AQ. There is a common tendency for users who run into a
>problem to think everyone does too, and it isn't necessarily so.
>>
>Frequently asked questions do make it to the FAQs: it is a defence
>mechanism for the volunteers supporting R.
>>
>help.search("directory") gets you there.

K, good to know. Thanks for helping.

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

probably this has used up sufficient disk space in the mail archive
already, but anyway a bit of support to the initial request: one of the
very first things I did, when I started using R, was adding

cd <- setwd
pwd <- getwd

to my .Rprofile. and when I encouraged colleagues to try R out, the 'top
three' questions where

"how can I get out? I tried ^C, exit(), quit(), but nothing works"
"how can I change the directory? `cd' does'nt work"
"where am I? `pwd' does'nt work" (`pwd' is something like a 'local
speciality', I presume)

this is of course a marginal obstacle for new users, but avoidable all
the same. (and maybe most people (like myself) in the first place don't
think it important enough to post it -- maybe it _would_ be in the FAQ
otherwise)

so, _if_ 'cd' would be recognized in future releases, it would'nt do any
harm, would it?

joerg

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

so, _if_ 'cd' would be recognized in future releases, it would'nt do any
harm, would it?

ls()
[1] some things here
cd("foo")
ls()
[1] some things here

Cue shout of: "Hey, it didnt work!"

ls() is not to /bin/ls what setwd() is to 'cd'.

Gets -1 from me. setwd() makes it clear[er] its a working directory on
the file system and nothing to do with R's objects.

Barry

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/10/2006 9:29 AM, Paul Johnson wrote:
It is a FAQ in our Linux lab. People start emacs and fire up R via
ess, and then they have no idea 'where they are". For computer
experts, it is not a problem, but for people who don't know much about
computers, it is a pretty big problem. They have data in some
subdirectory, but almost invariably they don't get emacs & R started
from that same place.

Unfortunately, for our users, it does not help to simply re-label
setwd as cd. Both commands imply a deeper understanding of the S
than they have. Also, unfortunately, these are the same people who
don't understand that FAQs exist and should be consulted. These people
are so new/timid that asking in r-help would be the last thing to
cross their mind.

I've wondered if it would not help to have the R prompt include the
directory name, as in an x terminal.

I think file system directories aren't as central in R as they are in a
shell, so it would just be distracting. Most of the time I work in the
R workspace, not in the file system.

To me the solution is to allow interactive file selection by default,
i.e. the default on read.table and similar functions should be
file.choose(), rather than having no default and throwing an error.
This won't help you in the short run (because file.choose() on Linux
isn't all that friendly to beginners), but perhaps it would encourage
someone to make it better. file.choose() is quite nice in Windows (and
I think on the Mac), so beginners there could be told

mydf <- read.table()

and they'd get something useful.

Martin Maechler has disagreed with me about this in the past, but hasn't
convinced me that he's right, he's just convinced me that doing nothing
is easier than arguing about it.

Duncan Murdoch

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
5/10/2006 9:29 AM, Paul Johnson wrote:
It is a FAQ in our Linux lab. People start emacs and fire up R via
ess, and then they have no idea 'where they are". For computer
experts, it is not a problem, but for people who don't know much about
computers, it is a pretty big problem. They have data in some
subdirectory, but almost invariably they don't get emacs & R started
from that same place.

Unfortunately, for our users, it does not help to simply re-label
setwd as cd. Both commands imply a deeper understanding of the S
than they have. Also, unfortunately, these are the same people who
don't understand that FAQs exist and should be consulted. These people
are so new/timid that asking in r-help would be the last thing to
cross their mind.

I've wondered if it would not help to have the R prompt include the
directory name, as in an x terminal.

I think file system directories aren't as central in R as they are in a
shell, so it would just be distracting. Most of the time I work in the
R workspace, not in the file system.

To me the solution is to allow interactive file selection by default,
i.e. the default on read.table and similar functions should be
file.choose(), rather than having no default and throwing an error.
This won't help you in the short run (because file.choose() on Linux
isn't all that friendly to beginners), but perhaps it would encourage
someone to make it better. file.choose() is quite nice in Windows (and
I think on the Mac), so beginners there could be told

mydf <- read.table()

and they'd get something useful.

Martin Maechler has disagreed with me about this in the past, but hasn't
convinced me that he's right, he's just convinced me that doing nothing
is easier than arguing about it.

I agree with Martin regarding read.table; however, the underlying idea is
good and could be achieved via simple wrappers which are the same
as the corresponding underlying functions except for the default argument
to file:

read.table.choose <- function(file = file.choose(), )
read.table(file, )
read.csv.choose <- function(file = file.choose(), ) read.csv(file, )
read.delim.choose <- function(file = file.choose(), )
read.delim(file, )

# test
mydata <- read.table.choose()

in a package available to the users or possibly even in R core.

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/10/2006 10:45 AM, Gabor Grothendieck wrote:
5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
>5/10/2006 9:29 AM, Paul Johnson wrote:
>It is a FAQ in our Linux lab. People start emacs and fire up R via
>ess, and then they have no idea 'where they are". For computer
>experts, it is not a problem, but for people who don't know much about
>computers, it is a pretty big problem. They have data in some
>subdirectory, but almost invariably they don't get emacs & R started
>from that same place.
>>
>Unfortunately, for our users, it does not help to simply re-label
>setwd as cd. Both commands imply a deeper understanding of the S
>than they have. Also, unfortunately, these are the same people who
>don't understand that FAQs exist and should be consulted. These people
>are so new/timid that asking in r-help would be the last thing to
>cross their mind.
>>
>I've wondered if it would not help to have the R prompt include the
>directory name, as in an x terminal.
>>
>I think file system directories aren't as central in R as they are in a
>shell, so it would just be distracting. Most of the time I work in the
>R workspace, not in the file system.
>>
>To me the solution is to allow interactive file selection by default,
>i.e. the default on read.table and similar functions should be
>file.choose(), rather than having no default and throwing an error.
>This won't help you in the short run (because file.choose() on Linux
>isn't all that friendly to beginners), but perhaps it would encourage
>someone to make it better. file.choose() is quite nice in Windows (and
>I think on the Mac), so beginners there could be told
>>
>mydf <- read.table()
>>
>and they'd get something useful.
>>
>Martin Maechler has disagreed with me about this in the past, but hasn't
>convinced me that he's right, he's just convinced me that doing nothing
>is easier than arguing about it.

I agree with Martin regarding read.table; however, the underlying idea is
good and could be achieved via simple wrappers which are the same
as the corresponding underlying functions except for the default argument
to file:

read.table.choose <- function(file = file.choose(), )
read.table(file, )
read.csv.choose <- function(file = file.choose(), ) read.csv(file, )
read.delim.choose <- function(file = file.choose(), )
read.delim(file, )

# test
mydata <- read.table.choose()

in a package available to the users or possibly even in R core.

No, I don't think this is a good idea. It would be just as easy to tell
people to type

read.table(file=file.choose())

with no new package or function necessary. I want the existing basic
function to work when used by a beginner in a simple way.

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

Duncan Murdoch

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
5/10/2006 10:45 AM, Gabor Grothendieck wrote:
5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
>5/10/2006 9:29 AM, Paul Johnson wrote:
>It is a FAQ in our Linux lab. People start emacs and fire up R via
>ess, and then they have no idea 'where they are". For computer
>experts, it is not a problem, but for people who don't know much about
>computers, it is a pretty big problem. They have data in some
>subdirectory, but almost invariably they don't get emacs & R started
>from that same place.
>>
>Unfortunately, for our users, it does not help to simply re-label
>setwd as cd. Both commands imply a deeper understanding of the S
>than they have. Also, unfortunately, these are the same people who
>don't understand that FAQs exist and should be consulted. These people
>are so new/timid that asking in r-help would be the last thing to
>cross their mind.
>>
>I've wondered if it would not help to have the R prompt include the
>directory name, as in an x terminal.
>>
>I think file system directories aren't as central in R as they are in a
>shell, so it would just be distracting. Most of the time I work in the
>R workspace, not in the file system.
>>
>To me the solution is to allow interactive file selection by default,
>i.e. the default on read.table and similar functions should be
>file.choose(), rather than having no default and throwing an error.
>This won't help you in the short run (because file.choose() on Linux
>isn't all that friendly to beginners), but perhaps it would encourage
>someone to make it better. file.choose() is quite nice in Windows (and
>I think on the Mac), so beginners there could be told
>>
>mydf <- read.table()
>>
>and they'd get something useful.
>>
>Martin Maechler has disagreed with me about this in the past, but hasn't
>convinced me that he's right, he's just convinced me that doing nothing
>is easier than arguing about it.
>
I agree with Martin regarding read.table; however, the underlying idea is
good and could be achieved via simple wrappers which are the same
as the corresponding underlying functions except for the default argument
to file:

read.table.choose <- function(file = file.choose(), )
read.table(file, )
read.csv.choose <- function(file = file.choose(), ) read.csv(file, )
read.delim.choose <- function(file = file.choose(), )
read.delim(file, )

# test
mydata <- read.table.choose()

in a package available to the users or possibly even in R core.

No, I don't think this is a good idea. It would be just as easy to tell
people to type

read.table(file=file.choose())

with no new package or function necessary. I want the existing basic
function to work when used by a beginner in a simple way.

I don't think that an idiom of multiple function calls is as simple as
issuing a single function call with no args.

possibility is to have
a keyword "choose" on the file function in the same way that file
accepts the keyword "clipboard". Then one could write:

mydata <- read.table("choose")

I think the wrapper approach is probably preferable though and seems
consistent with the way R deals with this in other places such as the
IS wrapper.

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.

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/10/2006 11:10 AM, Gabor Grothendieck wrote:
5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
>5/10/2006 10:45 AM, Gabor Grothendieck wrote:
>5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
>>5/10/2006 9:29 AM, Paul Johnson wrote:
>>It is a FAQ in our Linux lab. People start emacs and fire up R via
>>ess, and then they have no idea 'where they are". For computer
>>experts, it is not a problem, but for people who don't know much about
>>computers, it is a pretty big problem. They have data in some
>>subdirectory, but almost invariably they don't get emacs & R started
>>from that same place.
>>>
>>Unfortunately, for our users, it does not help to simply re-label
>>setwd as cd. Both commands imply a deeper understanding of the S
>>than they have. Also, unfortunately, these are the same people who
>>don't understand that FAQs exist and should be consulted. These people
>>are so new/timid that asking in r-help would be the last thing to
>>cross their mind.
>>>
>>I've wondered if it would not help to have the R prompt include the
>>directory name, as in an x terminal.
>>>
>>I think file system directories aren't as central in R as they are in a
>>shell, so it would just be distracting. Most of the time I work in the
>>R workspace, not in the file system.
>>>
>>To me the solution is to allow interactive file selection by default,
>>i.e. the default on read.table and similar functions should be
>>file.choose(), rather than having no default and throwing an error.
>>This won't help you in the short run (because file.choose() on Linux
>>isn't all that friendly to beginners), but perhaps it would encourage
>>someone to make it better. file.choose() is quite nice in Windows (and
>>I think on the Mac), so beginners there could be told
>>>
>>mydf <- read.table()
>>>
>>and they'd get something useful.
>>>
>>Martin Maechler has disagreed with me about this in the past, but hasn't
>>convinced me that he's right, he's just convinced me that doing nothing
>>is easier than arguing about it.
>>
>I agree with Martin regarding read.table; however, the underlying idea is
>good and could be achieved via simple wrappers which are the same
>as the corresponding underlying functions except for the default argument
>to file:
>>
>read.table.choose <- function(file = file.choose(), )
>read.table(file, )
>read.csv.choose <- function(file = file.choose(), ) read.csv(file, )
>read.delim.choose <- function(file = file.choose(), )
>read.delim(file, )
>>
># test
>mydata <- read.table.choose()
>>
>in a package available to the users or possibly even in R core.
>>
>No, I don't think this is a good idea. It would be just as easy to tell
>people to type
>>
>read.table(file=file.choose())
>>
>with no new package or function necessary. I want the existing basic
>function to work when used by a beginner in a simple way.

I don't think that an idiom of multiple function calls is as simple as
issuing a single function call with no args.

possibility is to have
a keyword "choose" on the file function in the same way that file
accepts the keyword "clipboard". Then one could write:

mydata <- read.table("choose")

I think the wrapper approach is probably preferable though and seems
consistent with the way R deals with this in other places such as the
IS wrapper.


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

Duncan Murdoch

* Well, maybe this should be restricted to functions visible to the
user, but everything we've been discussing so far is visible and is part
of the user interface.

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
5/10/2006 11:10 AM, Gabor Grothendieck wrote:
5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
>5/10/2006 10:45 AM, Gabor Grothendieck wrote:
>5/10/06, Duncan Murdoch <murdoch (AT) stats (DOT) uwo.cawrote:
>>5/10/2006 9:29 AM, Paul Johnson wrote:
>>It is a FAQ in our Linux lab. People start emacs and fire up R via
>>ess, and then they have no idea 'where they are". For computer
>>experts, it is not a problem, but for people who don't know much about
>>computers, it is a pretty big problem. They have data in some
>>subdirectory, but almost invariably they don't get emacs & R started
>>from that same place.
>>>
>>Unfortunately, for our users, it does not help to simply re-label
>>setwd as cd. Both commands imply a deeper understanding of the S
>>than they have. Also, unfortunately, these are the same people who
>>don't understand that FAQs exist and should be consulted. These people
>>are so new/timid that asking in r-help would be the last thing to
>>cross their mind.
>>>
>>I've wondered if it would not help to have the R prompt include the
>>directory name, as in an x terminal.
>>>
>>I think file system directories aren't as central in R as they are in a
>>shell, so it would just be distracting. Most of the time I work in the
>>R workspace, not in the file system.
>>>
>>To me the solution is to allow interactive file selection by default,
>>i.e. the default on read.table and similar functions should be
>>file.choose(), rather than having no default and throwing an error.
>>This won't help you in the short run (because file.choose() on Linux
>>isn't all that friendly to beginners), but perhaps it would encourage
>>someone to make it better. file.choose() is quite nice in Windows (and
>>I think on the Mac), so beginners there could be told
>>>
>>mydf <- read.table()
>>>
>>and they'd get something useful.
>>>
>>Martin Maechler has disagreed with me about this in the past, but hasn't
>>convinced me that he's right, he's just convinced me that doing nothing
>>is easier than arguing about it.
>>
>I agree with Martin regarding read.table; however, the underlying idea is
>good and could be achieved via simple wrappers which are the same
>as the corresponding underlying functions except for the default argument
>to file:
>>
>read.table.choose <- function(file = file.choose(), )
>read.table(file, )
>read.csv.choose <- function(file = file.choose(), ) read.csv(file, )
>read.delim.choose <- function(file = file.choose(), )
>read.delim(file, )
>>
># test
>mydata <- read.table.choose()
>>
>in a package available to the users or possibly even in R core.
>>
>No, I don't think this is a good idea. It would be just as easy to tell
>people to type
>>
>read.table(file=file.choose())
>>
>with no new package or function necessary. I want the existing basic
>function to work when used by a beginner in a simple way.
>
I don't think that an idiom of multiple function calls is as simple as
issuing a single function call with no args.

possibility is to have
a keyword "choose" on the file function in the same way that file
accepts the keyword "clipboard". Then one could write:

mydata <- read.table("choose")

I think the wrapper approach is probably preferable though and seems
consistent with the way R deals with this in other places such as the
IS wrapper.
>
>
>>
>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.

Duncan Murdoch

* Well, maybe this should be restricted to functions visible to the
user, but everything we've been discussing so far is visible and is part
of the user interface.

Another idea is to implement a menu item in the Windows GUI that
does a read.table(file.choose(), ).

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

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

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

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

5/16/2006 5:46 AM, Joerg van den Hoff wrote:
Manuel LI 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.
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.

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

R-help (AT) stat (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!

Duncan Murdoch wrote:
5/16/2006 5:46 AM, Joerg van den Hoff wrote:
>Manuel LI 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!).

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 (DOT) math.ethz.ch mailing list

PLEASE do read the posting guide!