Hacker News Reader

Comment by nvy | Hacker News Reader

I always thought R was a vestigial artifact of the bad old days of computing that had no place in the Real World (tm), but then I had to use it for a graduate-level data analytics course for business students.

And then it all made sense. Non-coders equate R with RStudio to the point that they don't really get that R and its editor were separate concepts, and therein lies the power.

Everybody uses the same IDE and it always works. No more figuring out why the language server isn't offering completions or wondering why ESS has such awful defaults.

R (and the tight integration with RStudio) makes it very easy for non-programmer types to conduct their own sophisticated exploratory analysis and to produce good looking plots without mucking about in Excel.

I still hate the `<-` assignment operator though.

View on HN

I actually love that R uses '<-' for assignment. Assignment is an inherently asymmetric operation: it takes the RHS and assigns it to the LHS, and the arrow visually indicates this. It feels more correct to have a visually asymmetric operator for it.

This makes sense, but then why the use of `=` for function arguments?

Because in that context the equals sign makes sense, e.g. "Call function F with X equal to 5."

I don't see how that logic differs from using `=` as an assignment operator.

"Assign X with value equal to 5"

When you do `f(x=5)`, x doesn't get set to 5 anywhere you can see (it happens inside the body of f, which you are treating as a black box). So logically, in the context of the code that's calling f, it's not an assignment operation.

Admittedly this kind of goes out the window with a lot of tidyverse non-standard eval stuff. E.g. if you do `df %>% mutate(x = 5)`, then x does get set to 5 in the data frame, so that is logically an assignment of x in a visible scope using '='. Going by my logic, functions like mutate should ideally use a different symbol for operations that alter the input like this, but we run up against syntactic limitations of the language.

I think the argument is that, to the uninitiated, x = x + 2 looks more like an invalid equality than "replace the value stored in x with its current value plus 2".

Personally, it seems to me that = for assignment is so ubiquitous that this argument has become stale.

I still use the arrow because it's the prevailing recommendation in R style guides.

I use R quite a lot for data extraction, manipulation and visualisation, it is the most used tool in my area of academia. You are correct that RStudio seems to be the only IDE but I'd say most users know that R is the language and RStudio the IDE.

That being said many decent GUIs have been developed for a more traditional analysis feel, but still use R under the hood, I like JASP the most out of the current options.

Other things:

1. Unmatched simplicity of dplyr for data manipulation.

2. Great graphs with ggplot2.

Oh, and 1-based indexing. Try telling economics students why 3..5 means elements 4 and 5.

(edit: we are actually agreeing, see replies)

Doesn't 3..5 mean elements 3 and 4 : the 3rd and the 4th? 0-based indexing might feel less intuitive actually (element 3 is the 4th, and element 4 is the 5th). I don't know much R, I'm assuming that in the n..m notation, n is included and m is excluded (edit: also included, see replies).

I don't now about economy, but I think mathematicians use 0-indexed and 1-indexed sequences interchangeably and they usually (have to) specify which is the first term (u0 or u1).

R's indexing is not only 1-based, it's inclusive on both ends. So indexing from 3 to 5 actually gets you elements 3, 4, and 5. I've programmed a bunch with both R and 0-based languages and I greatly prefer R's way of doing indexing.

I'm pretty sure it's like this in Pascal, too. Which makes sense, since it's the only way to reasonably index 1-based arrays. For example, you'd expect the following code to set arr to the set "1, 2, 3, 4, 5", not to leave the last element uninitialized.

  var
    arr: array [1 .. 5] of integer;
  begin
    for i := 1 to 5 do
      arr[i] := i
  end;

Normally you would write "for i := low(arr) to high(arr)". I just wrote the numbers "1 to 5" to be explicit here.

> Doesn't 3..5 mean elements 3 and 4 : the 3rd and the 4th? 0-based indexing might feel less intuitive actually

Yes, you’re agreeing! The point of the parent was that 0-indexing is less easy to grasp

Oh, right! I parsed the last sentence in a weird way I guess. Also thanks rcthompson for the precision about intervals being inclusive on both ends in R.

Ordinary humans count from 1.

> I always thought R was a vestigial artifact of the bad old days of computing that had no place in the Real World

Why on Earth did you think that? Because it's not what the hip frontend devs use?

Probably because it's full of inconsistencies and gotchas, largely caused by backwards compatibility with S.

What programming language isn't full of inconsistencies and gotchas?

Its not as bad as most people make it out to be

Because it has five assignment operators and a tendency to fail silently and to keep going after something errors, producing bad results for people that aren't programmers and maybe aren't good at debugging, and is only usable if you install a third party package (tidyverse).

Keeping going after errors is common for many scripting languages, isn't it?

No idea. Silently failing and continuation is a complete anti-feature if you want correct results in your data pipeline though.

I get it, you like R. I'm not interested in litigating this any further.

I always just use = and never have any issues.

I had a little play with RStudio and it seemed very expensive for what it did. But I am not an R programmer might be missing the point completely.

There's a free community version.

Reply on news.ycombinator.com