Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The R language, for programmers

johndcook.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: The R language, for programmers

#61

Post by jghn »

johnsea wrote: post #45
mjt0229 wrote: post #8

R is one of those languages that looks like it was designed in a vacuum by a very smart person. It has many common, modern PL constructs, but they're expressed syntactically in a way that in no way resembles any other language I've seen. The entire syntactic legacy of Algol, Pascal, C, etc, all are thrown by the wayside. Familiarity with any of those syntaxes felt to me like more of a liability than a help. That's no…

R is a 'rip-off' / open source re-implementation of the commercial S language by John Chambers. (There are some differences in scoping iirc). Haven't many of its 'modern' PL constructs already been used in Lisp (dialects) before?

Indeed, it's not the hodgepodge that many people believe it to be, it just comes from a heritage that's much further away in the PL family tree than they're used to.

There are something things which were grafted on to S/R later on. For instance the S4 OOP system was added much later (in S4) and was based on Dylan's OOP system. So there's a case where the GP is correct that it was taking structure from another PL but it's also one which is fairly foreign to a lot of OOP devs

Re: The R language, for programmers

#62

Post by jghn »

epistasis wrote: post #35
Alupis wrote: post #2

I actually quite like the R language. A buddy of mine is in his University's PoliSci program and one of the requirements is to learn R for statistical and trend analysis. He could not stop complaining until I offered to help him learn it by learning it with him. After doing his first assignment, we were both impressed with what could be easily done in R to visualize data. I think he now realizes how useful of a tool…

I actually really like it too. The programming language features of it are quite different from what's going on in a Java/C++/C# world, but they are super convenient. Argument matching is really amazing and useful for prototyping. No doubt there's a penalty, but it's exactly the type of power that's needed to build expressive and useful reusable components with rapidly changing designs. And pattern matching like that…

I've said for several years now that most complaints about R's syntax and idioms really boil down to "this isn't doing things the way I'm used to doing them, i.e. the C/C++ branch of the language family tree"

Re: The R language, for programmers

#63

Post by jghn »

xname wrote: post #53

One thing I don't like about R is the OOP part of R. I don't see any reason of R including OOP into its design and sometimes it just creates confusions.

R didn't include OOP into its design, it was all grafted on later, are there are multiple systems.

There's the S3 OOP system, the S4 OOP system, reference classes and at least one add on package on CRAN which does something different.

So which one are you complaining about? :)

Re: The R language, for programmers

#64

Post by nkurz »

jghn wrote: post #60
nkurz wrote: post #58

I've been looking at a variety of R packages, mostly for the purposes of rewriting them in C++ for greater speed, and my assessment is that most of them are of very low code quality. I don't mean that they don't work (they usually do), or that they are too slow (they usually are, but this is explained by selection bias given the reasons I'm looking at them), but that there is little standardization even with a given…

I'll admit that as someone who has a package on CRAN, has been using R since ~2001 and who is a normal software developer in their day to day job that the lack of standardization is something I'm guilty of. For me what happened was that my thoughts on appropriate naming, structure, etc has evolved over the 6 (I think?) years of the package's existence but I simply haven't had the time to make the wholesale changes ne…

Could you suggest some examples of packages using current best practices that I could try to pattern mine after?

Re: The R language, for programmers

#65

Post by Alupis »

epistasis wrote: post #35
Alupis wrote: post #2

I actually quite like the R language. A buddy of mine is in his University's PoliSci program and one of the requirements is to learn R for statistical and trend analysis. He could not stop complaining until I offered to help him learn it by learning it with him. After doing his first assignment, we were both impressed with what could be easily done in R to visualize data. I think he now realizes how useful of a tool…

I actually really like it too. The programming language features of it are quite different from what's going on in a Java/C++/C# world, but they are super convenient. Argument matching is really amazing and useful for prototyping. No doubt there's a penalty, but it's exactly the type of power that's needed to build expressive and useful reusable components with rapidly changing designs. And pattern matching like that…

Should note that R wasn't really designed for "programmer" programmers. It's largely used by statisticians, analysts, etc, so a lot of the syntax will vary from a C based language.

Re: The R language, for programmers

#66

Post by sytelus »

To me writing tutorials for teaching R these days is same as writing tutorials for Fortran (and I'm sure Fortran still has some nice goodies not available elsewhere). It misdirecting people eager to learn something to a wrong thing. As you can see in this article, every 3rd section of R book or tutorial is often dedicated in gotachas to deal with. We have iPython, Notebook, sci-kitlearn, numpy etc and massive number of R-packages already migrated. I hope there is little need to take trouble of learning R for most people new to it.

Re: The R language, for programmers

#67

Post by sebastianavina »

nkurz wrote: post #58

I've been looking at a variety of R packages, mostly for the purposes of rewriting them in C++ for greater speed, and my assessment is that most of them are of very low code quality. I don't mean that they don't work (they usually do), or that they are too slow (they usually are, but this is explained by selection bias given the reasons I'm looking at them), but that there is little standardization even with a given…

R is more like a statistical package, you use R for cleaning data, calculating confidence intervals and alike. It's not really a language for programmers. I mean, Matlab is not a language for programmers.

Re: The R language, for programmers

#68

Post by jghn »

nkurz wrote: post #64
jghn wrote: post #60

Earlier quoted context omitted.

I'll admit that as someone who has a package on CRAN, has been using R since ~2001 and who is a normal software developer in their day to day job that the lack of standardization is something I'm guilty of. For me what happened was that my thoughts on appropriate naming, structure, etc has evolved over the 6 (I think?) years of the package's existence but I simply haven't had the time to make the wholesale changes ne…

Could you suggest some examples of packages using current best practices that I could try to pattern mine after?

I should be clear that there's not yet a One True Way in terms of coding standards and such, but things are improving.

Anyways, a good place to start would be the Hadleyverse: https://github.com/hadley

One could do a lot worse than following his lead.

Re: The R language, for programmers

#69

Post by hadley »

lispm wrote: post #27
rcthompson wrote: post #15

Earlier quoted context omitted.

You can think of the lazily evaluated arguments feature a lot like lisp macros. Basically, any function in R can either get the value of its arguments (i.e. acting like a regular function) or it can get the unevaluated expression passed for that argument (i.e. acting like a lisp macro). So in your "do.stuff" example, it's not a matter of special scoping, per se. The do.stuff function is actually getting the symbols "…

That would be a FEXPR in Lisp, not a macro. In most actually used Lisp dialects, FEXPRs have been replaced with macros.

Yes, r functions are very similar to fexprs

Re: The R language, for programmers

#70

Post by hadley »

scroy wrote: post #22
aagha wrote: post #19

I'm curious for others thoughts on what to use for complex statistics if you needed high performance/speed. Running an R script on a server to process data isn't efficient, but does that mean you have to roll your own stats package if you want to have a Java (for example) back-end?

Not sure how complex your use case is, but I've found Pandas (on Python) to be just as powerful and much more performant than R for working with scientific data. It's built on Numpy so you can use Scipy's statistical functions with it seamlessly.

Recent benchmarks show the performance of pandas, data.table and dplyr to be pretty similar, with data.table usually being the fastest.
Post reply on HN