From: "M. Edward (Ed) Borasky" Date: 2006-07-05T03:20:39+09:00 Subject: Re: ed borasky and his second favourite programming language Matthew Smillie wrote: > On Jul 4, 2006, at 17:03, Nuralanur@aol.com wrote: > >> Thank you, Paul, for the link. >> Assuming that Ara's link to Ed Borasky's opinions also makes the case >> for R, >> I've two questions: >> >> obviously, you can like features of R very much, but what do you do >> if the code you have to write doesn't have anything to do with >> statistics? Let me put a little context on this. At the time I adopted R, the project I was working on was written nearly 100 percent in Perl, and most of that was Perl 4 code I had hand-translated from some primitive "awk" scripts. The need arose to create some statistical graphs (boxplots mostly) and other late 20th century artifacts. So I went hunting for an open-source tool that would do that. The requirements, other than open source and the ability to do the graphs, was that the package be able to run on either Windows or Linux, and that it be "accessible from Perl" in some sense. A nice-to-have was that it could be found on Red Hat media (7.0 IIRC). There were three candidates: Perl Data Language (PDL), XLisp-Stat, and R. PDL is mainly for image processing, and I didn't see boxplots built in, so it dropped out first. I personally didn't have any problem programming in Lisp, but I wasn't willing to saddle my colleagues with the task of learning Lisp, and the R community looked larger and more vibrant than the XLisp-Stat community. So R won out. My current _modus operandi_ is to do the data crunching in Perl, a task for which it was designed, and upload the data into a relational database or CSV files, then do the analysis in R. If I were writing all of this magic over today, I'd probably build a Rails app and use the R math library for the analysis. Now, to answer the question: "but what do you do if the code you have to write doesn't have anything to do with statistics?" Well, first of all, being a mathematician, I'll make the claim that *any* sufficiently large task, programming or otherwise, has *some* statistics in it. :). Second, if the task is *mostly* statistics and graphics but contains other elements, like the need for a GUI, database interface, web serving, regular expression handling -- in short, all the things we use "scripting languages" like Ruby as our primary tools to accomplish -- you don't need to leave R! There are libraries (now) that do all of these things. >> What are the nice features of R that make it superior to Ruby in Ed >> Borasky's opinion - and do we agree with him ? Clearly R is superior to Ruby for executing the 700-odd packages in the CRAN, Bioconductor and OmegaHat repositories. :) If you read through that list, you'll find a lot of things that R does very well that you probably never heard of. Of the 700-odd packages, I regularly use perhaps five or ten -- the kernel smoothers, the database interfaces, the GUI and web servers and occasionally the time series packages. And clearly Ruby is superior to R for lots of things. They don't happen to be things I get paid to do at the moment. They are things I want to learn how to do, which is why I'm learning Ruby. Ruby is, as far as I can tell, the best-designed *general purpose* language to date. > > I can't speak for Ed, but for me (I use it as well), it does precisely > what it needs to do, and it does it succinctly and well. Which, not > coincidentally, are the same reasons I use Ruby for the things I use > Ruby for, and the same reasons I use Prolog for the things I use > Prolog for. I attempted to learn Prolog once. I never got very far with it, and moved on to FORTH. :) >> Ruby is "more general" than R (since there are bindings for R >> available), >> and there are also bindings to other scientific programs/packages >> e.g., GSL >> (if you want to to do numerical integration or random number >> generation). I think R has bindings for GSL too -- about the only thing I don't recall R being able to do is call Ruby. :) >> I think one should compare languages that do about the same things >> with respect to how they do it. > That might be interesting for its own sake, but it doesn't really > teach us anything about the languages being compared. Languages are > just tools, and not all tools are meant to do the same things. This > one drives nails, this one turns screws, this one calculates > eigenvectors, and this one makes foxes eat bacon. Knowing those > aspects of a language are much more valuable than, say, knowing which > one is faster at a 'hello world' web application. Yeah, but ... when C first came out, it was touted as a general-purpose language, which indeed it is. About the only people who didn't jump on the C bandwagon were the AI folks, who were married to Lisp, and the number crunchers, who were married to FORTRAN. C for all practical purposes wiped out assembler, PL/I, Ada, Pascal, and even COBOL. Today, C drives nails, turns screws, calculates eigenvectors, and powers Linux, GCC, Perl, Python, PHP, R and Ruby. I've never heard of a FORTRAN compiler written in FORTRAN. But ... Lisp and Scheme for the most part still power (and compile) themselves. :) -- M. Edward (Ed) Borasky http://linuxcapacityplanning.com