I also got excited when I found out about R Markdown, and how well is integrated with RStudio. I believe that it is a decent alternative to Jypyter Notebook.
What's Next for R?
61–70 of 72 posts
Re: What's Next for R?
#62Earlier quoted context omitted.
True, the default semantics of R's data structures are somewhat arcane (of course as they're based on S [1] from the 70's). And the current support for e.g. 64bit integers leaves something to be desired. But behind the scenes, R is just a lisp with some data structures that are adapted to statistics and data science. All base data structures are by default immutable. And e.g. the vector type is extremely performant a…
This 5 minute video by Wickham was eye opening for me regarding the lispiness or R. https://youtu.be/nERXS3ssntw
modern Lisps don't use unquote/quote like that.
This looks more like 'FEXPRS' from decades ago.
1962 the ideas of macros were introduced and macros are source code transformers, which take source code and generate new source code. This can also used in a compiled implementation, where macros translate the code before compiling.
FEXPRs are then functions which get arguments unevaluated and can decide at runtime which to evaluate and how.
Re: What's Next for R?
#63I know this is a dead horse, but I think R seriously shot itself in the foot with its data structures[1]. I don't really see a solution for this, as fixing it would never be backward compatible. I'll always pick Python over R because the data structures actually make sense to me as a programmer (objects that look like lists, dicts, matrices, etc. or any combination of the above, and they all behave in very predictabl…
True, the default semantics of R's data structures are somewhat arcane (of course as they're based on S [1] from the 70's). And the current support for e.g. 64bit integers leaves something to be desired. But behind the scenes, R is just a lisp with some data structures that are adapted to statistics and data science. All base data structures are by default immutable. And e.g. the vector type is extremely performant a…
In typical Lisps a vector would be a one-dimensional array, which by default is not specialized to a particular data-type. So the most general data type would be the n-dimensional array and a vector would be a one-dimensional array. A matrix would be a two dimensional array. In Common Lisp one can also ask Lisp to generate a type-specific array (like a string, a bitvector, an array of single-floats, ...).
In R it's slightly different. The vector (being generally without dimensions) is the base data type and n-dimensional arrays are made of a vector and dimensions. A matrix is then a 2d array. Also vectors/arrays are by default type-specific.
> support for macros
From what I've seen, R does not support macros, but functions which can retrieve/generate code at runtime. That's an early mechanism which got replaced by macros in Lisp. Macros in Lisp are source code transformers and can be compiled - thus they are not a runtime mechanism like in R or earlier Lisps with so-called FEXPRs.
Re: What's Next for R?
#64Earlier quoted context omitted.
You only have to go through the learning process once. You are able to use the language for a lifetime. I find it so strange how much emphasis we tend to put on things being simple to learn and pick up.
Because if things aren't simple to learn and pick up, people will get discouraged and move on. As was the case in the comment above. Great documentations and tutorials go a long way.
The most rewarding things I've learned in life have not been easy by any stretch of the imagination.
Re: What's Next for R?
#65I know this is a dead horse, but I think R seriously shot itself in the foot with its data structures[1]. I don't really see a solution for this, as fixing it would never be backward compatible. I'll always pick Python over R because the data structures actually make sense to me as a programmer (objects that look like lists, dicts, matrices, etc. or any combination of the above, and they all behave in very predictabl…
The only thing you need to understand about R data structures is that everything is a vector, including scalars. You have atomic vectors and lists, which are a special kind of vector. Everything else is built on top of those.
This is an insight you gain very early in your R experience. It breaks down rather quickly. Not that it is not true — there are just too many details around the core concept.
Re: What's Next for R?
#66Disappointed in the lack of discussion of R-Shiny or Plumber. R-Shiny is a full stack platform for web apps, and it’s how I leveraged my data science background to get into web development. It’s incredibly powerful in my opinion, with the only obvious limitation being the speed of R itself. And Plumber. It’s become the defacto method for deploying R code in a REST api. It too is still maturing, but I see it eventuall…
I understand where you are coming from and had similar experience.
After learning a fair bit of web-development, I feel R should focus on an analytics oriented path.
R just isn't designed for a web-app. Web-apps are much better and faster developed in more focussed languages / frameworks (node/python/django/express, etc) and can be seamlessly integrated to leverage R modules / scripts.
Re: What's Next for R?
#67Earlier quoted context omitted.
For larger-than-RAM data I would recommend diskframe.com It uses dplyr and data.table syntax to manipulate data on disk
I've not used diskframe.com, but from experience can recommend the 'fst'[1] file format with 'fsttable'[2] for reading on disk data tables. [1] https://github.com/fstpackage/fst [2] https://github.com/fstpackage/fsttable
disk.frame uses fst as the underlying format
Re: What's Next for R?
#68Disappointed in the lack of discussion of R-Shiny or Plumber. R-Shiny is a full stack platform for web apps, and it’s how I leveraged my data science background to get into web development. It’s incredibly powerful in my opinion, with the only obvious limitation being the speed of R itself. And Plumber. It’s become the defacto method for deploying R code in a REST api. It too is still maturing, but I see it eventuall…
on the shiny note - check out streamlit. declarative python equivalent. it's pretty incredible how easy it is to use
[deleted]
Re: What's Next for R?
#69I started at a company using Shiny for their applications and R as part of their data pipelines. A huge pain point for us is the packaging system. It is absolutely awful. Packages constantly get overridden so we have to install packages in a specific order. Whenever I have reached out to the community (including prominent members, which have written R books) I have always been told to just use the latest version of a…
At my old work we would “freeze” CRAN, by downloading a complete dump of everything and setup R to install from that version instead of the online version as a way of version controlling packages.
So instead of defining our app to use version 1.4.5 of a package, we would use “latest version from 3rd of May”.
Re: What's Next for R?
#70Future could be predicted with some data from the past. That's a bit ironic that we are discussing about the future of R. Programming languages never got this much attention. Everyday is a new day for a programming language and specifically R-programming enthusiasts. R is experiencing threats from Python, Julia but R still survives. R’s future is as bright as a sky with data.table and spark’s API with R.