If R were reprogrammed from scratch today, what changes would be most useful to the statistics community? Many people in the statistics community and other academic fields use R as their primary language for data analysis and statistical computing.  It is a wonderful and versatile language that has become extremely popular across both academic and industry.  The language has an interesting history which evolved as an improvement of the S language produced by Bell Labs (see e.g., Chambers 2020).  While it is a versatile language, the base version of R has a few well-known draw-backs, such as difficulties dealing with "big data", lack of labels on variables, etc.  This base functionality is often supplemented by popular packages, but new users can have difficulty learning the required methods.
Since R was developed essentially as an updated reprogramming of a previous language, it is natural to wonder if there might ever be an effort to create a new language that seeks to build on R.  In the event that such a project were ever to occur, what kinds of changes would be most useful to the statistical community?
 A: Preserving/translating existing R packages
Probably the greatest present advantage of R over other statistical computing programs is that it has a huge repository of well-developed packages that perform a broader class of statistical tasks than is available in other programs.  In the event that there were any attempt to reprogram a new version from scratch, it would be important to preserve as much of this as possible as valid code that would be compatible with a new program.  Consequently, in the event that there is any change in the base program that would render later code obsolete, it would be useful to have a parallel method of "translation" of code into the new program.
A: Bring data.table like syntax to data.frame
data.table's syntax (DT[i, j, by]) is so useful and such a faithful extension of data.frame that it should just be built in at this point. (If we are willing to entertain breaking changes).
A: Object oriented programming
OOP tools had not been in initially included into language. Currently there are S3 and S4 objects which makes that there is lack of consistency among different code (a problem that is more general than just OOP).
A: Standard object classes/structures for common statistical outputs
There are some special object types that have been developed in R to represent particular kinds of statistical outputs.  For example, there are objects of class htest that are used to represent the outputs of a hypothesis test, and objects of class lm, glm, etc., used for the outputs of statistical models.  However, there are a number of common statistical outputs that do not have special classes/structures developed.  As a result, they tend to be represented in an ad hoc manner.  It would be useful for common statistical outputs to have a defined class and structure in the base program, with consistent elements and printing method.
Here are some examples of particular outputs that would benefit from having a developed class/structure, with associated custom print methods, etc.  Giving these and other important statistical outputs a standard class/structure would allow users to develop, compute and print these outputs in a way that includes all required information and gives user-friendly print output.

*

*Sets could be represented by appropriate objects such as is presently in the sets package.  Having sets as objects in the program would be useful for a number of statistical outputs.


*Confidence intervals/sets could be represented as an object of class ci that includes a set object giving the confidence interval/set, the confidence level, the name/description of the parameter or quantity for the interval, and any other required information.


*Highest density regions (HDRs) could be represented as an object of class hdr that includes the set object giving the HDR, the coverage probability, and any other required information.
A: Multithreading by default
R was built as a single threaded application, but we can do better these days. Sadly Microsoft R is pretty much discontinued now...ir had many benefits over the original. https://mran.microsoft.com/documents/rro/multithread
A: Less reliance on C/C++/Fortran, aka solve the Two-Language Problem
One of the major drawbacks of R is that the actual performant code is mostly written in other languages (C/C++ and even Fortran).
This makes development and tinkering way harder (since now new users need to learn at least two, not one, language).
Julia, for example, is Julia all the way down to the LLVM layer.
This makes a novice Julia user proficient in both high and low-level functionalities necessary to actually develop a package or simply help improving other packages (not to say that the low-level complexity is easy, but you at least know the language already, to the point that it's not uncommon for newbies to contribute features to the core language).
So, if pure R could be made performant enough, the Two-Language problem would be overcome.
How to make that? This is harder said than done. Julia took a stance regarding type inference and JIT (just in time, aka at runtime) compilation, so R could need to give away some of its features to achieve that. Luckily, R (and some other languages) followed the footsteps of JIT compiled languages, and part of it is already featured.
A: More consistency in parameter names. For instance:

*

*matrix() has a parameter dimnames.

*write.table() has parameters row.names and col.names (with dots, and no dimnames parameter).

*There are functions rownames() and colnames(), without dots.

Yes, this is a tiny detail. But I have been using R on a daily basis for almost 20 years now, and I still have to look at ?matrix each and every time, because I tried to set row.names and am surprised why this doesn't work.
A: Build wrangling functions and labelled data into the base program
As a general rule, it would be nice to move some of the important functionality in key packages into the base program (as was done for the stats package at one stage).  In particular, the base objects in the program should be programmed to use some of the useful wrangling functions for "tidy data" (e.g., per Wickham 2017), should allow easy descriptive labels for all variables, and should handle time as a special variables in a way that is useful for tidy analysis of time-series data.

*

*Some of the wrangling functions for tidy data analysis similar to what exists in the tidyverse should be built into the base program.  There are a number of functions in that field that assist in wrangling data frames (but their names can be quite odd, owing to the fact they are not in base).  All base objects and functions should be programmed with the principles of tidy data in mind, and with core functions for important wrangling steps.  I concede that there is a trade-off here --- you don't want to add too many functions and increase complexity, but you want to add enough functions to do key wrangling steps.


*Objects such as vectors, matrices and data frames should allow descriptive labels for their variables, similar to what exists in other languages such as Stata.  The labels should be in addition to variable names, to allow variable description or labels for printing.


*The base program should handle time variables in a way that allows simple ordering of time-series, and standard operations you want to do with time variables.  Presently most of this is in packages in R such as lubridate and zoo.
A: Useful error messages
Compared to other languages (e.g. Python) it is very difficult to track down bugs based on error messages. Error messages are often not even informative about what part of the code causes the bug.
Optional static typing
Easy way to make sure that i is a number (as it is supposed to be) and not a data frame.
Some (maybe optional) way to get rid of bugs caused by scoping issues
For example I want to be able to tell a function that it should work just with its arguments and under no circumstances try to find variables in other environments (I'm looking at you global environment).
Native support of C++ extensions
Rcpp is a wonderful way to extend R to get performance gains but suffers from the problem that natively R supports only C (not C++). This limits severely what you can do with Rcpp and makes extending R through new packages more difficult than it has to be.
Of course, addressing any of these concerns would require a complete re-design of the language so R wouldn't really be R any longer.
A: Standalone executable
To execute the code you need to have R installed. This is similar to Python, which does however have some programs than can turn python into executables.
This makes it more difficult to share programms with users that do not have R installed.
A: Built-in reproducible environments
If R were designed from scratch, it would be great to have a built-in way to reproducibly use packages and have multiple versions of the same package installed, and bundle information about which packages the code was run with in a single file that could be used to rerun this code with identical packages. Ideally without requiring you to install the same package multiple times.
There are plenty of packages out there to create reproducible R environments, which causes fragmentation, and users do have to use one for their code to be properly reproducible.
A: Add more protected names
pi <- 3 should probably not be allowed.
A: Replace packages by standardized functions
There are so many packages and the definitions of functions differ between packages. For the same problem there are different functions from different packages, with similar names but different details. Actually you do not know what happens if you apply a function and you loose control about your code. If you want to know what a function does then the help is very scarce or only a paper is given as a reference. A function without a documentation is a risk for any user.
It would be better to choose the most useful functions in a selection process, standardize and modify them, and put them all in a default system with standardized help. This would also reduce redundant functioncs and increase the order. Currently R looks like a multiworld construction kit that needs refurbishing.
