On Friday, 13 November 2020 at 21:28:30 UTC, data pulverizer wrote:

> You act as if I'm banning people from writing code in R - I certainly don't have the power to do that. And yes, it varies from situation to situation, as I clearly eluded to.

All I'm saying is that any project that interoperates with R or any other language has to accept that the programmers you're targeting are going to write code in the other language. If for no other reason than the fact that they've already written tens of thousands of lines of code that they don't want to throw away.

> I've done a lot of projects in R. I'm well aware that sometimes it is unavoidable for the client. What I am saying is given the choice, you should probably choose a different tool apart from "some minor instances". I've seen R go spectacularly wrong because of the type of language it is, it makes assumptions of that the programmer means which can cause epic bugs, and very often, it does it silently and it happens all the time. You can never be sure that *any* piece of R code will work as it should. It's just the nature of the language.

Well, I don't want to get into a big debate about R, but I don't for the most part agree with this view. R was designed to be used as (1) a functional language, and (2) a specialized tool to quickly solve a specialized set of problems. It's remarkably difficult to write incorrect code if you're using it as it was designed to be used, which includes pure functions and immutable data structures. It originated as a dialect of Scheme and that's the foundation everything is built on.

Where I do agree with you is the type system. Not only is it a dynamic language, it has an extremely weak type system, which most likely has something to do with the fact that it originated down the hall in the same place that gave us C. I nonetheless don't agree with the conclusion that it should never be used. I've seen loads of R criticism, and it's almost always something like this. Here's one I've probably seen 50 times:

x <- 1:10
j <- 4
x[2:3+j]

The code returns [6 7]! It should obviously return [2 3 4 5 6 7]! R is trash!

That's nonsense. Operators have precedence in every language. The critic would have gotten the "correct" answer with x[2:(3+j)]. No language is going to work if you don't understand operator precedence. Another is that x[-1] drops the first element. If you come from another language, that might not be what you expect. If you come from a language that forbids negative index values, you might even think this makes R unusable. Honestly, the vast majority of R critiques are not different from the folks that post here about how D does things wrong because it's different from C++ or Python or whatever language.

On Friday, 13 November 2020 at 22:59:23 UTC, bachmeier wrote:
> Well, I don't want to get into a big debate about R ...

You already did so by reading something else into what I was saying

> I nonetheless don't agree with the conclusion that it should never be used.

I never said this. From the beginning I said that there are some instances where R could be used.

> I've seen loads of R criticism, and it's almost always something like this. Here's one I've probably seen 50 times:
>
> x <- 1:10
> j <- 4
> x[2:3+j]
>
> The code returns [6 7]! It should obviously return [2 3 4 5 6 7]! R is trash! ...
> Another is that x[-1] drops the first element. If you come from another language, that might not be what you expect.

This is not what I'm talking about, but there are *many* known issues with how R behaves, but you seen not to have selected any of the well known ones. Here are just a few:

1. R can suddenly decide that your character (string) should suddenly become a factor - even if you know about this it can still difficult to tell when this occurs. That's why stringsAsFactors exists.
2. R can suddenly decide that your selection in a matrix should be a vector. So if you were selecting mat[, 1:n] and n == 1 you don't get a matrix anymore, and your code will fall over. That's why drop = TRUE/FALSE exists. Can still be a difficult bug to find. I've seen this happen MANY times. The behaviour in Julia mat[:, 1:n] when n == 1 is the expected one.
3. Recycling elements instead of throwing an error - loads of bugs for this one.
4. sapply will return whatever it wants with the same argument types. One minute a matrix and another time a list and so on. With the SAME ARGUMENT TYPES!
5. Dates will suddenly unpredictably morph into numbers. cat("Today is: ", Sys.Date()).
6. The flimsy and almost unusable set of OOP tools. S3, S4, "R5" - Refererence Classes, and R6 - how many languages have that many OOP systems? Mone of which are particularly effective.

These are just a few of the popular ones but there are MANY more. When your code base grows, these and many other types of issues start to have a serious impact on the stability of your application. There are places for R, but you have to be VERY careful where you put it.

> R was designed to be used as (1) a functional language, and (2) a specialized tool to quickly solve a specialized set of problems. It's remarkably difficult to write incorrect code if you're using it as it was designed to be used, which includes pure functions and immutable data structures.

Sounds as if you're "quoting from authority here". The flow of what you've said here is misleading. If you said, "R is *weakly* 'functional-like' and has some convenience as a result", I might reluctantly accept that. But R doesn't have anywhere near enough features from functional programming to be even *used* as a functional language. How can you have so much instability built into a language can call it functional? R is the opposite of functional ethos! It has obscene permissiveness on some issues and irrational restrictiveness on others.

> Honestly, the vast majority of R critiques are not different from the folks that post here about how D does things wrong because it's different from C++ or Python or whatever language.

This is not true. I can write code in D and be pretty sure that it does what I think it does - even before thorough testing, you win massively just with static typing. C++ too. Even before the new Python function type system it was still pretty robust for a dynamic language, now you can fairly well gaurantee some things. Julia in principle is all but a static language with dynamic-typing "tagged on". R occupies a particular space as a programming language, and it's a space I'm wary of, and I think others should be careful, cognizant of it, and use it accordingly.

On 30.10.20 13:15, Russel Winder wrote:
> Having thought about it on and off for a decade, I am happy with the status
> quo around Python. Python code is (or should be) highly maintainable code
> designed for execution on a single threaded VM, easily understood and amended.

Weird. If you had given me those requirements as a list and asked me to relate them to Python, I would have told you you made a list of weak points of Python.