>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>>>>> on Mon, 30 Jan 2006 09:58:23 -0500 writes:
Duncan> On 1/30/2006 4:16 AM, Martin Maechler wrote:
>>>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> on
>>>>>>> Sun, 29 Jan 2006 16:35:50 -0500 writes:
>>
Duncan> On 1/29/2006 1:29 PM, Prof Brian Ripley wrote:
>> >> On Sun, 29 Jan 2006, Marc Schwartz wrote:
>> >>
>> >>> I would argue against this.
>> >>>
>> >>> If this were the default, that is requiring user >>>
>> interaction, it would break a fair amount of code that I
>> >>> (and I am sure a lot of others have) where automation
>> is >>> critical.
>>
>> >> I don't see how. The current default is
>> >>
>> >>> read.table() >> Error in read.table() : argument
>> "file" is missing, with >> no default
>> >>
>> >> so the only change is that the default might do
>> something >> useful.
>> >>
>> >> Nor do I see the change would help, as the same people
>> >> would still use a character string for 'file' and not
>> >> omit the argument. (It seems very unlikely that they
>> >> would read any documentation that suggested things had
>> >> changed.)
>>
Duncan> No, but people teaching new users (or answering
Duncan> R-help questions) would have a simpler answer: just
Duncan> use read.table().
>> but I am not sure that people teaching R should advocate
>> such a read.table; I they did, the new R users would get
>> the concept that this is the way how to use R.
Duncan> I'd say "a way to use R", and I think teachers
Duncan> *should* present such a use. It insulates users
Duncan> from uninteresting details, just as now it's
Duncan> probably good to advocate using file.choose() rather
Duncan> than explaining paths and escape characters before
Duncan> beginners can do anything with data. Later on
Duncan> they'll need to learn those things, but not from the
Duncan> beginning.
>> I still think R should eventually be used for
>> "Programming with Data" rather than a GUI for ``clicking
>> results together''. Hence users should be taught (in the
>> 2nd or 3rd part, not the 1st one of their introduction to
>> R) to work with R scripts, writing functions etc.
Duncan> Right, I agree here too. This would soften the
Duncan> shock of the 1st introduction, but as soon as the
Duncan> students are ready to look at functions and
Duncan> understand default parameters, they'd be able to see
Duncan> that the default value for the "file" argument is
Duncan> file.choose(). They might become curious about it
Duncan> and call it by itself and discover that it is
Duncan> possible to program GUI elements (assuming that
Duncan> file.choose() calls one).
>> And similar to Marc, I would never want default behavior
>> to start up a GUI elements: It is also much more
>> error-prone; just consider the "choose CRAN mirror" GUI
>> that we had recently introduced, and the many questions
>> and "bug" reports it produced.
>>
>> I know that I am biased in my views here; but I strongly
>> advocate the "useRs becoming programmeRs" theme and hence
>> rather keep R consistent as a programming language,
>> partly agreeing with Gabor here.
Duncan> I think I disagree with you because I think GUI
Duncan> programming is programming. I don't want beginners
Duncan> to think that there are two kinds of programs:
Duncan> command-line programs that they can write, and GUI
Duncan> programs that only Microsoft can write. I want them
Duncan> to think that programming is programming. Doing
Duncan> complex things is harder than doing easy things, but
Duncan> it's not qualitatively different.
Actually, I completely agree with what you said here.
However we disagree to some extent about the implications
(on teaching R, learning R, ..) of making GUI elements defaults
for basic R functions.
Also the phrase "consistent as a programming language" was
about the fact that for some functions, the default file(name) would be
GUI-dispatching whereas for other functions it would not (and
you agreed it should not).
Martin
Duncan> Duncan Murdoch
>> >> The same issue could be made over scan(), where the >>
>> current default is useful.
>>
Duncan> scan() is very useful for small reads, and rarely
Duncan> needed for reading big formatted files,
>> {people might disagree with this; given scan() is more
>> efficient for large files; but that's not really the
>> topic here.}
>>
Duncan> so I wouldn't propose to change it.
>> good.
>>
Duncan> The inconsistency with read.table would be
Duncan> unfortunate, but no worse than the current one.
>>
>>
>> >>> A lot of the issues seem to be user errors, file >>>
>> permission errors, hidden extensions as is pointed out
>> >>> below and related issues. If there is a legitimate
>> bug >>> in R resulting in these issues, then let's patch
>> >>> that. However, I don't think that I can recall >>>
>> reproducible situations where a bug in R is the root >>>
>> cause of these problems.
>>
>> >> Nor I.
>> >>
>> >> Note that file.choose does not protect you against
>> file >> permission issues (actually, on a command-line
>> Unix-alike >> it does nothing much useful at all):
>> >>
>> >>> readLines(file.choose()) >> Enter file name: errs.txt
>>
Duncan> No, it's not helpful here, but again it makes things
Duncan> no worse, and there's always the possibility that
Duncan> someone would improve file.choose().
>> I strongly prefer the current usage
>>
>> read.table(file.choose(), ....)
>>
>> which implicitly ``explains'' how the file name is chosen
>> to a new default read.table( .....)
>>
>> I'd like basic R functions not to call menu(),
>> GUI... parts unless it's really the main task of that
>> function.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
