I read the Wizard Book too. Absolutely classic! I agree about paying attention to performance, of course. Lisp programmers bend over backwards to write tail-recursive functions for similar performance reasons. So you have to pay attention to the language's idiosyncracies. But the time spent coding is usually much longer than the eventual run time. Learning to write well-designed code can do more to save time, even if the run time is slightly longer than optimal. If run time is an issue, then switching to C or Fortran etc. might be the best bet. But even in that case, using R for prototyping code can provide valueable insights.

Cheers,

Simon.

Simon Blomberg, BSc (Hons), PhD, MAppStat. 
Lecturer and Consultant Statistician 
Faculty of Biological and Chemical Sciences 
The University of Queensland 
St. Lucia Queensland 4072 
Australia 
T: +61 7 3365 2506 
email: S.Blomberg1_at_uq.edu.au

Policies:
1.  I will NOT analyse your data for you.
2.  Your deadline is your problem.

The combination of some data and an aching desire for 
an answer does not ensure that a reasonable answer can 
be extracted from a given body of data. - John Tukey.



-----Original Message-----
From: Wacek Kusnierczyk [mailto:Waclaw.Marcin.Kusnierczyk@idi.ntnu.no]
Sent: Fri 20/06/2008 5:06 PM
To: R help
Cc: Simon Blomberg
Subject: Re: [R] Programming Concepts and Philosophy
 
Simon Blomberg wrote:
> I try to use a functional programming style. I define functions within
> functions when it is helpful in terms of information hiding. I avoid
> writing functions with side-effects as much as possible, so the only
> communication of the called function with the caller function is through
> the arguments and the returned value. I try to keep the code as simple
> and clear as possible (this is one of the things I fail at most). An
> appropriate amount of comments is also useful, especially when returning
> to old code after a long break. OOP is useful for really big projects,
> but I find OOP unnecessarily complicated for small jobs.
>
> I found "Code Complete", by McConnell (http://www.cc2e.com/) to be very
> helpful. I'm sure there are other books around with similar tips. Before
> I switched to R, I used XLisp-Stat. I found learning Lisp to be a really
> good way to learn good programming practices. Good Lisp code is the
> closest thing you can get to poetry in computer programming. "Lisp Style
> & Design", by Miller and Benson was helpful. I'd like to see an "S Style
> & Design."
>   

i support this view.  i found sicp (structure and interpretation of
computer programs, by abelson & sussman, a real classic in the field)
particularly enlightening, although it certainly is a bit outdated in
many respects -- but just a bit.  functional programming style is great,
but beware -- r will create (afaik, experts please correct me if this is
wrong) a deep copy of about any object you send as an argument to a
function (if only when it is actually used inside the function), and the
result may be that the more beautiful the code, the more the performance
sucks. 

in pure functional programming, a function cannot change any part of the
object passed to it as an argument, so there's no need for making a
local copy.  in r everything can happen as you can deparse the call to a
function inside the function body, and you can never tell whether the
object you pass to a function will be changed or not, given only the
function's signature.

vQ


	[[alternative HTML version deleted]]

