Yep, as someone who both uses lots of R packages and writes lots of R packages (which, in turn, import other R packages), I've grown to appreciate the strictness of CRAN: if a package is on the CRAN, I'm just about guaranteed to not have installation issues or have it screw up my environment. To me, that's the one major job of a package repository, and CRAN does it well, even if it does cause package authors pain at times :)
The fact that there is a human (and one with expertise in R) reviewing each incoming package makes pure vibe coded slop much, much harder to get approved.
> The proof is in the pudding. Every single grad student of mine that was brought up on the tidyverse produces gigantic R markdown files with 20 imports to accomplish something that would be shorter and much much easier to understand (and review!) with a base package or with one of a small number of packages (box, data.table) designed by people who understand programming.
The fact that young people are producing sub-optimal code (in terms of whatever optimization criteria you are choosing--here, it sounds like terseness) is not strong evidence that a particular software ecosystem (tidyverse) is flawed. Young people producing bad code is not surprising. They're your grad students, mentor them, and maybe they'll adapt to your ways of thinking. Or not.
> One of the reasons R has lost ground to other languages recently is that most R code these days is ugly
Citation needed, surely. The fact that this article is about an increase in the number of CRAN submissions and pseudo-quantitative indices like the TIOBE index show R's slice of the pie is growing provides evidence to the contrary.
Yes, the main benefit is caching and reproducibility: with targets (or any other DAG-based approach), you only recompute what needs to be recomputed and you are assured that no stale inputs or temporary analysis artifacts end up in the final product. If you don't own the underlying data sources and those sources can change at any point, a DAG-based approach helps ensure that.
Thanks for all the work you (and the rest of the contributors) have done putting this together! I think bringing tree-sitter to R has already shown massive benefits: Just air alone has been a big improvement to my workflow.
I read this article a week or so ago and immediately implemented a VS Code extension that I've always wanted: a static analysis tool for targets pipelines. targets is an R package which provides Make-like pipelines for data science and analysis work. You write your pipeline as a DAG and targets orchestrates the analysis and only re-runs downstream nodes if upstream ones are invalidated and the output changes. Fantastic tool, but at a certain level of complexity the DAG becomes a bit hard to navigate and reason about ("wait, what targets are downstream of this one again?"). This isn't really a targets problem, as this will happen with any analysis of decent complexity, but the structure targets adds to the analysis actually allows for a decent amount of static analysis of the environment/code. Enter tree-sitter.
I wrote a VS Code extension that analyzes the pipeline and provides useful hover information (like size, time last invalidated, computation time for that target, and children/parent info) as well as links to quickly jump to different targets and their children/parents. I've dogfooded the hell out of it and it's already vastly improved my targets workflow within a week. Things like providing better error hints in the IDE for targets-specific malformed inputs and showing which targets are emitting errors really take lots of the friction out of an analysis.
All that to say: nice work on extending tree-sitter to R!
Author here. I wrote an R package to generate realistic sky maps for a given location and datetime (with scattered light, realistic moon phases, stars, and planets all at physically-based brightness values) to support plausible 3D renders of real terrain and data visualizations.
This is pretty astounding. Honestly, this is the feel-good "our company is helping save dogs" story that should have been featured at the super bowl. The fact that AI can be used by a motivated and smart person to facilitate the production of custom mRNA immunotherapy via genomic sequencing for their dogs cancer just hints at the possibilities of the future, if we choose to embrace science rather than reject it.
Nice results! SIMD can be a pain, good to know Zig makes it easy.
However, note that the plot under "Native SIMD Throughput Comparison" is extremely misleading: for an accurate proportional comparison between bar charts, you should start the y-axis at zero. The way the data are presented makes it look like a 10-100x gain, rather than the actual 2x improvement.
When you're dealing with large populations (here, the study include 230,065 students--a very large number), even small shifts due to some treatment can be significant. It is very hard to generate top-down policy interventions that shift the mean of a population in significant ways: if this treatment effect (banning phones) is real, 1.1 points represents a very big policy win that can easily be applied elsewhere. The devil is in the details, however: they exclude some recent data based on the pandemic, but baseline off of 2022-2023, which was still in the throes of the pandemic. The data they show looks to have around a 0.5-1 sigma variation in percentile from 2022-2024, so the shift from the baseline of around 1 to 4 definitely looks significant, but it will be interesting to see if sticks over time.
There is a way to model this type of situation for watertight dielectrics with interface tracking: you assign each material a priority value, and a transition between materials occurs when entering that material only if it has a higher priority than your current material. Yining Karl Li has a great article about it:
that inspired me to add the feature to my renderer (rayrender.net).
The downside to priority tracking (and possibly why PBRT does not include it) is it introduces a lots of overhead to ray traversal due to each ray needing to track a priority list. Modern raytracers use packets of rays for GPU/SIMD operations, and thus minimizing the ray size is extremely important to maximize throughput and minimize cache misses.
The developing S7 object system (https://github.com/RConsortium/S7) is looking fairly promising in that it combines many of the nice properties of S3 and S4 (validation, multiple dispatch, sane constructors) while still being fairly simple and straightforward to use.