Debugging Compiled Code for R with Positron(tylermw.com)
tylermw.com
Debugging Compiled Code for R with Positron
https://www.tylermw.com/posts/coding/debugging_cpp_in_positron.html
10 comments
Tyler is actually using R for exactly what R and it's predecessor S were designed to do since the beginning. You can read more about it's history by googling John Chambers who helped develop S at Bell Labs.
Another strength of R, albeit via the tidyverse-package, is in data manipulation. It excels in taking some misfit, human friendly, pile of excel-sheets with implied relations and turning it into rectangular data sets that can actually be analysed. Sure there are faster alternatives if you are doing big data, but if you need versatility R is a good friend.
A large number of statistical packages in R make use of C++ for their core algorithms. See here, for example: https://cran.r-project.org/web/packages/Rcpp/index.html
Unlike many other languages, R has a native/built-in tabular data structure. So when your data have tabular structure R is by far the best glue for building pipes between external libreries. If the data fits in RAM it literally doesn't have to leave the data.table object throughout the whole pipeline (including all the cleaning and transformations).
The only meaningful alternative I see is Python with maybe Polars or DuckDB.
The only meaningful alternative I see is Python with maybe Polars or DuckDB.
Fellow R / Polars user here. How (in what applications) do you use DuckDB?
DuckDB is great for medium data: Too big for memory, but small enough to fit on local storage. It's also extremely performant for loading data and supports a wide range of storage backends. It's also really well integrated with R and can really speed up certain queries, as long as the DuckDB engine can translate them to valid SQL.
>> As someone who basically uses R as a nice LISP-y scripting language to orchestrate calling low-level compiled code from other languages
Except... this is exactly was R was created to do, with a focus on mathematical/statistical libraries written in things like FORTRAN.
R is great as a glue language for these purposes if the purpose of calling that low-level compiled code is largely to work with data and especially if that data is not so large/computationally intensive to work with that it does not need to be distributed across hardware.
Except... this is exactly was R was created to do, with a focus on mathematical/statistical libraries written in things like FORTRAN.
R is great as a glue language for these purposes if the purpose of calling that low-level compiled code is largely to work with data and especially if that data is not so large/computationally intensive to work with that it does not need to be distributed across hardware.
I think I got a little confused by the language here, my mistake
I dunno why you would blog about, and even create a blog tag for, Positron without linking to it :-/
https://github.com/posit-dev/positron (Elastic V2)
https://github.com/posit-dev/positron (Elastic V2)
> As someone who basically uses R as a nice LISP-y scripting language to orchestrate calling low-level compiled code from other languages
When I read this, I think, would `bash` or something equally portable/universally installed work?
R is a beautiful thing when limited to its core uses But in my experience, the more we build away from those core uses, the more brittleness we introduce. I wish the Posit team would focus on the core R experience, resolve some of the hundreds of open issues on its core packages in a timely way [0,1], and just generally play to R's strengths.
[0] https://github.com/rstudio/rmarkdown/issues
[1] https://github.com/tidyverse/ggplot2/issues