> and python (a sane, real programming language)

So... R is an unreal language then?

Nah, it's just a re-implementation of S, which was really, really old and different from what people expect.

R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming.

Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view.

But yeah, lots of people are hateRs (unfortunately).

Wise words here.

In my humble opinion, applying S's syntactic sugar on top of Scheme-forged core did more bad than good to R. Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible.

As for the two approaches to solving problems (TIMTOWTDI vs Python's "one true way") I think that's a matter of personal preference; I, personally, appreciate the freedom that R gives me. Also, it might be anectodal, but I believe that - to some extent - it promotes thinking "outside the box", especially when you work in a team and review others' code on a daily basis.

> Most of R's quirks stem from the authors' desire to keep it as compatible with S as possible.

On the other hand, if it was not for that compatibility with S we would not be having this conversation: R would be just a footnote in the history of statistical computing like Lisp-Stat.

Exactly! I probably didn't make the trade-offs clear in my original post. I believe that the massive price increases in S-plus licensing may have driven lots of people to start using R, which would definitely not have happened without the S-compatibility.

Your very last point should be heavily against R, not in favour. Having multiple ways to do the same thing is fine when you work by yourself, but in a large team it makes the style of the codebase vary a lot based on who wrote each block of code and makes reviewing others' code more difficult. If you want to get anything done, reading code really shouldn't be your daily challenge of how "outside the box" you can think just so you can understand what is going on.

That's true if we're talking about the overall architecture of the project. And, since R permits so many different coding styles (and paradigms: native functional and several OO), the team should have someone (usually the most senior software engineer) play the role of an architect and design the structure of the code, data structures, API, and so on.

Perhaps having a fixed (and commonly agreed on) set of design patterns - like in Java - makes development easier and smoother, but most of the projects I've worked on have proven successful, so maybe it's not that bad either... :-)

> Nah, it's just a re-implementation of S, which was really, really old and different from what people expect.

Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!).

The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).

I use R daily at work, and often reach for it before Python for non-statistical tasks out of comfort.

But R's functions for non-statistical tasks often break the language's idioms. Those dealing with files and connections are especially ugly.

I wouldn't call it insane or unreal, but it's definitely not intended for general scripting.

I don't argue that R is not insane ;-)

As for (a bunch of) functions in the basic library (which, essentially, is a set of packages that you can discard or simply not use), I dare say it has little to do with the language itself. I don't like Python's regular expressions library, for example, but it's only a set of functions (or methods) that you can write on your own! The same goes for R's data-wrangling routines; there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library. Heck, you can even write your own DSL (think: Grammar of Graphics) if you think it could improve your code!

There are several quirks built so deeply into the core of the language that you cannot overcome them ("why can't I overload `+` for character strings??"), but they have nothing to do with the rather poor and unintuitive basic library.

> there's this tidyverse, and you can write good, reliable, production-grade code without using a single function from the base library

A different take on the subject (https://r4stats.com/2017/03/23/the-tidyverse-curse/):

> On the other hand side – I have met a guy using R in production. And he told me that he needs code that stayed the same for 5+ years. That is why he does not use dplyr or any tidyverse, it is still changing too much.

That's right! And I always keep telling my peers that they should think twice before they decide to use tidyverse packages in the production code. What I meant is that in R you always have choice - and even if you feel that the existing solutions don't meet your expectations, you can always write your own (even if it means writing a DSL like Hadley et al. did in ggplot2 or rlang).