Parsing R code: Freedom of expression is not always a good idea (2012)

Re:Parsing R code: Freedom of expression is not always a goo... by dash2 on Tuesday June 14, 2022 @08:23AM (#31738165)

This seems very much like an outsider's critique. It's super interesting, but if the goal is actually improving R I'm almost sure a better approach would be to take a hand with development, fix some bugs, gain respect and push for incremental - or even less-than-incremental - changes. Core R are definitely trying to encourage new developers to join in, so the opportunity is there.

[ Parent | on HN ]

Re:Parsing R code: Freedom of expression is not always a goo... by datastoat on Wednesday June 15, 2022 @05:57AM (#31750952)

> This seems very much like an outsider's critique

Spot on! This same sentiment was expressed very well in a paper evaluating the R language [1]:

"This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular."

It would be nice to see a post about R that analyses _why_ it's so hugely popular with data scientists. It's easy to write "R doesn't do what we computer scientists think languages should do, so it's no good". It's harder to analyse what R gets right (for its domain) that other languages get wrong. Personally, I think it's not just that R has the best data-handling libraries (ggplot2, plyr, data.table), it's its "unlikely linguistic cocktail" that is perfectly suited for data exploration.

I think that maybe we hear the views of software engineers who get handed a messy R script and are asked to make it run in production, or make it run on big datasets, and so they only ever see the downsides of R. R wasn't designed to make life easy for production! It's designed to make it easy to explore datasets, which often means one-off code, 99% of which you run and then delete because your hypothesis about the data was wrong.

[1] https://www.researchgate.net/publication/240040602_Evaluatin...

[ Parent | on HN ]

Re:Parsing R code: Freedom of expression is not always a goo... by svnpenn on Tuesday June 14, 2022 @11:29AM (#31740926)

I wholly disagree with this sentiment. I have seen, time and again, awful language design choices. Granted, they might have been the best option at the time, or maybe no one could think of a better method.

But things change with time. And quite often, the response to suggestions ends up being "it's too late to change it", "it's good enough", or any number of comments to minimize the obvious negatives. Too often people get stuck in "local maximums", thinking their way is best, until years later when time has proven them wrong.

[ Parent | on HN ]

Re:Parsing R code: Freedom of expression is not always a goo... by dash2 on Tuesday June 14, 2022 @03:36PM (#31744890)

I didn't say the guy was wrong. I said he wasn't going to change anything by standing outside and complaining. I think your argument supports that idea. Maybe in an ideal world people would be very open to drive-by critique. In reality, not so.

[ Parent | on HN ]

Re:Parsing R code: Freedom of expression is not always a goo... by svnpenn on Tuesday June 14, 2022 @06:30PM (#31746849)

From experience, I find the better option is to just move on.

You can only shout at a wall for so long, before you realize that you're wasting your time. So you make your concerns heard (which this guy did), and you move on. If people want to take the advice to heart, great, but its not likely. Plenty of other languages to use, and plenty of other software to use.

[ Parent | on HN ]