Hacker News Reader

Comment by azalemeth | Hacker News Reader

R gets a lot of hate, not least because it's quite annoying to parallelize at times, but I think it's a lovely free language with an enormous ecosystem and a lot of highly mathematically literate users, oft based at universities, and oft beholden unto no corporate interests. Arguably that's also R's greatest weakness too.

This is quite a nice modernisation of colour palettes in base R, which otherwise does feel a bit like it's from the 1990s. Colour palettes are particularly important for (not) biasing data representations -- a great paper about it is https://www.nature.com/articles/s41467-020-19160-7.

View on HN

R is hard to parallelise compared to python?

lapply(list, DoSomething)

To parallelise to 16 cores , rewrite as

mclapply(list, DoSomething, mc.cores = 16)

What’s the equivalent in python ?

Probably something like:

    with multiprocessing.Pool(core_count) as p:    
        p.map(do_something, list)

The parallel code structure looks very different from the standard for loops in python.

So there is a lot of rewriting to get things to work on parallel in python compared to R.

In R you just replace lapply with mclapply.

But, many R tools are already vectorised, so your shift from lapply() to mclapply() is about as fair a comparison as claiming it's "just" a shift from python's builtin map() to pool.map(). Anybody can play this game, and it's not helpful. I've been using+teaching R now for nearly seven years and the number of times I've used lapply can be counted on one hand.

> just

https://justsimply.dev/

I use sapply all the time to transform data all the time. It tends to be less code (no counter, no output initialisation ) and easier to follow if that style is familiar.

I am curious now, what do you use instead of lapply (or other *apply variants)?

There is also this in the futureverse if you like for loop style code more:

  library(doFuture)
  plan(multisession)

  y <- foreach(x = 1:4, y = 1:10) %dofuture% {
    z <- x + y
    slow_sqrt(z)
  }

https://dofuture.futureverse.org/

> just

This isn't documentation or a guide or helping someone.

It's a friendly competition between languages so it gets to use the perspective of someone that's familiar with things.

Serialisation/deserialisation code will bite you unless you are very careful.

so, only twice as much code!

My gripes with R are that the language itself is a mess and I found it hard to reason about code. The ecosystem is what keeps people using it.

I agree and disagree.

R itself isn't a mess. Typical R code tends to be.

In theory, this reflects one of R's strengths, which is its ability for flexible metaprogramming. In practice, this becomes a weakness because people abuse it to introduce all sorts of inconsistent notation that makes zero sense without reading the documentation of the package even to understand 'syntax'.

From a language point of view, R is not too bad. The ecosystem is a mostly positive thing, but at the same time, it's the variety in the ecosystem that's creating this chaos around offerred packages and R code in the wild.

> R itself isn't a mess. Typical R code tends to be.

The same can be send about Perl - it is not hard to write readable code but there is code around which was written without regard to readability/maintainability or any consistency at all. Languages which are trying to force a single style (e. g. indentation as a part of the syntax like in Python or configurable format tool like 'go fmt') and have as little TMTOWTDI as possible are favored nowadays.

R is king for analysis of tabular data e.g. data exploration, model fitting, and visualizations where all the code can be contained in one .R file.

R not as good as other languages for production-level work though or for analyzing non-tabular data (e.g. streaming data, or data in unstructured formats).

I also find R packages (writing, installing, documenting) to be a better experience than the python packaging system. i.e., very little rewrite necessary to convert a bunch of R code into an R package.

Huh. Those are my gripes about python, and it would also die without the ecosystem.

Except that python also lies about it.

"You don't need curly braces, indents are enough"

"what do you do when your code is more than 80 chars long?"

"Oh, that's simple. Because Python is simple. You wrap it in a curly brace."

If you have a blank line between two parts of a function, why does this fail when you paste it into the interpreter? Solutions? Oh, that's simple. Just put four spaces on the blank line. Unless your linter doesn't like that, because it means you have a line with trailing spaces.

And I'm not even touching advanced crazyness, such as package management and versions.

Thanks for listening to me complain. I'm going through a difficult transition right now.

I'm definitely not defending Python. I think that language is a mess as well. There is no law of conservation of programming language derps, unfortunately.

I think people are annoyed about the idea of having to know R, Python and Julia. So we stick to our guns with Python even if Julia is possibly better. Heck, if I'm ever learning another language, it's Janet then Rust. Or Type/Javascript if life ever throws me thataway. To paraphrase: stop trying to make Julia happen.

Also the Julia community is lovely, but R folks are so smug about tiny things like (the admittedly very fine for its applications) ggplot2. Also: have you heard SAS or Stata users telling you they can run neural networks using their built-in matrix languages? Yes we can! Yes we can!

I'd rather stick to my R guns than my python pea-shooters, thank you very much.

Reply on news.ycombinator.com