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

51–60 of 79 posts

Re: The R language, for programmers

#51

Post by alaiacano »

bglazer wrote: post #47
minimaxir wrote: post #5

The biggest "gotcha" for learning R as a programmer is that R interprets character vectors of data frames as factor vectors by default , which will usually break something in your code. If you're learning R, learn to use dplyr for data manipulation and ggplot2 for plotting. Both will save you a lot of time.

I've heard all good things about ggplot2 and I sincerely believe they're true. However, my only experience has been trying to plot 2 overlapping timeseries that didn't have the same length to the same plot area. I found that to be nearly impossible in ggplot2 and almost trivial with the builtin plot and lines commands in R. Like a lot of good tools, it seems that ggplot2 makes the common case extremely easy, but it c…

> s1 > s2 > s > qplot(x, y, data=s, geom=c('point', 'line'), color=series)

Re: The R language, for programmers

#52

Post by wch »

chuckcode wrote: post #25
rm999 wrote: post #20

Earlier quoted context omitted.

> pass by value only means code tends to end up as monolithic functions I've actually found R works very well as a functional language with very lean functions. It's perhaps worth noting that R doesn't copy a dataframe in a function call if you don't modify it, which is a very common use-case for me. (I'm not sure if this extends to other datatypes) > very slow in loops so lot contorting to move things to matrix oper…

Python has better and better support for R with Rpy2 and R like data frames with Pandas, which is helping me take advantage of the incredibly useful analysis libraries in R. Also note that loops are slow enough that it is really worth learning the *apply() functions in R to avoid iterating over collections. For a relatively in depth explanation check out Hadley Wickham's book http://adv-r.had.co.nz/Functionals.html

It's a common misconception that for loops in R are slow. They're actually fast (around 20 million iterations per second on my computer). What can be slow is modifying data structures in particular ways using a loop. See http://rpubs.com/wch/46581

Re: The R language, for programmers

#55

Post by daveloyall »

kyberias wrote: post #49
daveloyall wrote: post #14

TL;DR: Tragically, R has a lot in common with old-skool PHP and MS Excel, at the same time.

I don't know why exactly you're getting downvoted. I've tried learning R many times, but the resemblance to PHP problems is just too much.

Probably there aren't legitimate semantic or syntactic similarities between the three.

But for proposes of a TL;DR, I believe that a qualitative description of the situation should suffice.

I'll try again:

TL;DR: The language R lacks the quality without a name.

Or:

Jeeze, now I know why none of my previous attempts to learn a little R were fruitful.

Or:

The language R seems to have been developed in isolation and thus it fails to adhere to any particular convention--it is its own beast. Further, it sometimes lacks self-referential integrity and coherence.

Or:

haha cf. PHP or Excel.

:)

Re: The R language, for programmers

#56

Post by mbq »

chuckcode wrote: post #42
mbq wrote: post #29

Earlier quoted context omitted.

*apply functions are loops underneath -- they only look better and save you time possibly wasted on growing some dynamically sized output structure. The way of solving slow loop in R is to find package which implements it in C/Fortran (or write your own in case there is none).

It'a actually a little complicated but if you're interested in the details check out this stack overflow thread [1]. High level summary is that lapply() and functions built on top of it do some work in native C and so are generally faster but not all of the *apply() functions are faster. [1] http://stackoverflow.com/questions/2275896/is-rs-apply-famil...

The problem here is not the for-loop itself but the time used by the R runtime on executing the mapped function multiplied by the number of iterations (this is BTW the main source of advantage for dynamic and GCed but JITed languages like JS or Julia).

Re: The R language, for programmers

#57

Post by nkurz »

daveloyall wrote: post #55
kyberias wrote: post #49

Earlier quoted context omitted.

I don't know why exactly you're getting downvoted. I've tried learning R many times, but the resemblance to PHP problems is just too much.

Probably there aren't legitimate semantic or syntactic similarities between the three. But for proposes of a TL;DR, I believe that a qualitative description of the situation should suffice. I'll try again: TL;DR: The language R lacks the quality without a name. Or: Jeeze, now I know why none of my previous attempts to learn a little R were fruitful. Or: The language R seems to have been developed in isolation and thu…

I voted you up here because you were below zero and I was also about to post a comment comparing R to PHP, but I'll mention that I frequently downvote one line posts that start with "TL;DR". The concept of "too long didn't read" implies (to me, and probably others) that that the article isn't worth reading. If I think the article is worth reading, and the short comment isn't incredibly insightful, I'd usually prefer such comments to be at the bottom of the page and grayed out.

Re: The R language, for programmers

#58

Post by nkurz »

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 package, and the 'foundations' seem weak.

Variable names are a hodgepodge of unhelpful single letter abbreviations theSecondArgumentToTheFunction; functions alternate between camelCase, dots, and underscores; and any form of architecture seems at best an afterthought. It seems like the base language encourages this, or at least does nothing to prevent it. It's commonplace to pick on Perl, but the overall quality of popular packages seems considerably lower on CRAN than CPAN. Perhaps this is because Perl is so conscious of its reputation at this point that the remaining programmers take great pain to write clear code?

I feel like R is currently in the stage where Perl and PHP were as the internet was just when the internet started to explode. The first-to-market CGI scripts and libraries, often written by domain expert non-programmers, became the default choices which the rest of the infrastructure was built on. At some point, the weight became too great for the shoddy[1] construction, and most people moved on to languages with better attention to maintainability and foundational detail (Python, Ruby).

Those who remained with the language evolved it in similar directions, by replacing the earlier libraries with better designed ones and by setting a higher standard for community norms. I'm not sure about PHP, but contrary to reputation, modern Perl is often a really clean and consistent language. Julia seems to be playing a parallel role for R, although the new-found strength of Python in the data analysis space complicates the analogy.

But I wonder: is R undergoing (or about to undergo) a similar renaissance? Are there already examples of "Modern R" out there to serve as templates for the future direction of the language? Or is R happy where it is?

[1] Did you know that 'shoddy' was originally a legitimate but low grade of wool, and wasn't necessarily pejorative?

Re: The R language, for programmers

#59

Post by daveloyall »

nkurz wrote: post #57
daveloyall wrote: post #55

Earlier quoted context omitted.

Probably there aren't legitimate semantic or syntactic similarities between the three. But for proposes of a TL;DR, I believe that a qualitative description of the situation should suffice. I'll try again: TL;DR: The language R lacks the quality without a name. Or: Jeeze, now I know why none of my previous attempts to learn a little R were fruitful. Or: The language R seems to have been developed in isolation and thu…

I voted you up here because you were below zero and I was also about to post a comment comparing R to PHP, but I'll mention that I frequently downvote one line posts that start with "TL;DR". The concept of "too long didn't read" implies (to me, and probably others) that that the article isn't worth reading. If I think the article is worth reading, and the short comment isn't incredibly insightful, I'd usually prefer…

Oh, I hadn't considered "too long, DON'T read". Hm. This article is worth reading if you're interested in R but not yet well acquainted with it.

Re: The R language, for programmers

#60

Post by jghn »

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 necessary. It's on my todo list, but frankly things like "fix actual bugs" have been sitting on that list for a very long time as well.

In general though, I've always found that most packages are pretty crappy and not just for code quality. With a relatively small amount of exceptions what I found over the years was that if you needed to do something it was almost always better to write something yourself than shoehorn someone else's junk into your system. There's an exception w/ Bioconductor, particularly the packages created and maintained by the core devs.

And on your point about the renaissance, yes I believe that has been happening, largely driven by Hadley Wickham.

Post reply on HN