Pandas like features

[data pulverizer]

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.