4 ms·

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

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.

altairiumblue 8y ago
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.
- Cosi1125 8y ago
  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... :-)
kgwgk 8y ago
> 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.
- disgruntledphd2 8y ago
  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.

altairiumblue 8y ago

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.

Cosi1125 8y ago
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... :-)

kgwgk 8y ago

> 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.

disgruntledphd2 8y ago
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.