I suggest that you approach each of these as fundamentally different languages, intended for fundamentally different purposes. R is a programming language that is not “general-purpose.” It is very-specifically designed for statistics. Unlike tools such as SAS® and SPSS®, which are based on monolithic modules (each dripping with options) that are tied together – if at all – by relatively primitive scripting facilities, R offers the statistician a true programming-language environment that is targeted for his tasks and mind-set. (It is no wonder why SAS, SPSS, and everybody else promptly created interfaces to it, and openly encourage its use.)
A useful analogy to the present situation is when you embed R programming into a project that was built using a conventional tool like SAS or SPSS: the two tools work together, but, within its element, R is running the show and the stats-package is supporting it. The same will undoubtedly be true for the hybrid applications that you write where Perl is the tool supporting it. Don’t try to do Perl things the R way, nor R things the Perl way. Study R examples to see, not only how this language “works,” but also how it “thinks.” Spend a few days in which you do not fire-up the Perl interpreter at all. As you found with Perl, soon you will be saying (about some particular aspect of R), “gee, that’s kinda cool!” (And so it is. You will not “hate learning R” for very long ...)
As you write your tools, also consider your audience. There is a large “impedance mismatch” between the Perl and the R mind-sets, and researchers are likely to be more-familiar with R. Try to avoid requiring them to confront this mismatch and to switch back-and-forth between the two environments in their design of a solution, even if they are familiar with both. A pure-R implementation of a particular section is probably more-favorable than a mixed one, and concerns such as “execution time” or “efficiency” usually are considered to be secondary, within reason, unless they say otherwise. Consult the R-gurus within the organization frequently as you design your tools.
