[jlebar]

> The problem is people using R without trying to learn about the language itself

It's not the user's fault.

Like, congratulations on being better at R than the author of TFA. Maybe you're smarter than him, maybe you've put in more time learning, maybe you've just spent your time more intelligently, maybe you lucked out and bought better books...who knows.

But this line of reasoning completely misses the author's point, which is that despite having used the language for years, he still finds it inscrutable. "It would be easier if you were better at R" is a tautology, and unhelpful. The issue is that the author finds it hard to become better at R.

We can disagree as to whether or not it's objectively hard to become better at R, but this is a perfectly valid criticism to make. It's not the user's fault.

[baldfat]

Its a 4 year old article and R has changed a TON with new things BUT.... R has grown a ton in users as well as features.

R really is a functional programming language that people don't take advantage on. All languages have strength and weaknesses and YET the complaint is R has too many ways to do any one thing which allows us to have data.table, dplyr, ggplot2, magrittr (pipping %>%). [EDIT RStudio and RServer are also a big example of R growth in features and quality]

As I learned R my code has changed dramatically and I think R has one of the largest gap between the code you start with and when you are proficient. My starting R code is really embarrassing.

[jcizzle]

I think the person you are responding to is simply saying some things are more complex than others and require more understanding and experience. R apparently falls into that category. If the author wants to gain that experience, I think the time spent on this blog post may be better used to reading a book on R. Fault might be a strong word, but the author has certainly made a decision on what they spend their time on and the results are as expected.

[RockyMcNuts]

some things require more understanding and experience, for no obvious benefit...in which case they're anti-patterns, or not best practice in language design.

there are a lot of things in R that are good but it's an old language and there's a lot of cruft.

like "R has three object oriented systems (plus the base types), so it can be a bit intimidating." http://adv-r.had.co.nz/OO-essentials.html

and believe it or not, there are things that require looping through a data frame and when I had to do that a few years ago it was unbelievably slow... going multithreaded was non-trivial, writing that section in C was non-trivial...ended up rewriting the whole thing in python and was a lot happier.

[mziel]

If you want to go over data-frame in parallel just replace call to lapply() with mclapply().

I agree about 3 OO systems, but let's not mix things up here. Casual user (who doesn't know sapply) doesn't interact with that.

[RockyMcNuts]

hmmh, here's the problem I was trying to solve.

data frame has 2 columns, 20 years of portfolio returns, and 20 years of % withdrawn.

using a starting portfolio value, calculate the 20 ending portfolio values for each year and the dollar amount withdrawn.

worked ok looping through the data frame, but was unreasonably slow.

never figured out how to use a vectorized method that could go through the frame building each new element from the one previously calculated.

maybe I missed something obvious?

(the parallel part came in because I was doing it on a lot of portfolios, so to speed it up just launched the same slow function on several lists of them in parallel. writing that one function above in C probably would have been OK. I think I got it to work but then I couldn't get the right version of compiler to work with the right version of R which supported the other libraries I was using. was a few years ago so maybe things weren't as stable. I never said I was very good :)