tylermw

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 :)

Absolutely correct. CRAN takes down and rejects packages all the time for minor issues and violations of their rules and guidelines. And there are a lot of them: https://cran.r-project.org/doc/manuals/r-release/R-exts.html

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.

Honored!

I've done exactly what you're talking about using tree-sitter (via the tarborist VS Code extension), specific to targets pipelines:

https://bsky.app/profile/tylermw.com/post/3mjmcykuows2d

So yes, it is possible and quite useful!

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!

tarborist: targets + tree-sitter https://open-vsx.org/extension/tylermorganwall/tarborist

GH: https://github.com/tylermorganwall/tarborist

A non-Apple entity using "macOS26" as their organization name? Are you trying to trigger everyone's corporate phishing training?

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 work! It's always fun to see a new renderer in the wild.

Looks like the author fixed the graph!

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:

https://blog.yiningkarlli.com/2019/05/nested-dielectrics.htm...

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.

What's going on with this plot's y-axis?

https://bsky.app/profile/tylermw.com/post/3lvtac5hues2n

For 28 Years Later, note that while the iPhone sensor did in fact ultimately collect the photons for the movie, they attached substantial professional-grade glass to the front to augment the phone camera.

Yes, the distortion noted in the article is also seen in wide angle lenses on traditional cameras.

Importantly, the base R pipe implements the operation at the language parsing level, so it has basically zero overhead.

Yes, you are correct, I should have typed "runs". But the point is that MITRE runs the U.S. National Cybersecurity FFRDC that maintains the CVE system, and FFRDCs are deliberately structured to minimize potential conflicts of interest (GP comment) and are definitely distinct from private industry (parent comment).

MITRE is a Federally Funded Research and Development Center (FFRDC), which is a distinct type of federal contractor with strict conflict of interest regulations. They are owned by the federal government, but operated by contractors and are specifically structured and regulated to minimize conflicts of interest, so are distinct from "private industry" in many regards.

You can read a congressional report by the CRS describing FFRDCs and their role here: https://www.congress.gov/crs-product/R44629.

trace is great for shimming in your own code to an existing function, but it’s not an interactive debugging tool.

Funny you mention namespacing: R 4.5.0 was just released today with the new `use()` function, which allows you import just what you need instead of clobbering your global namespace, equivalent to python’s `from x import y` syntax.

e.g. avoid dplyr overriding base::filter

use(“dplyr”, c(“mutate”, “summarize”))

I’m using ellmer to power some research on LLMs at my job—it’s great!

Note that there's a great C99/C++ single header library, tinyobjloader, that provides robust (in my experience) and feature-full OBJ loading, including triangulation of n-gons and full material parsing.

https://github.com/tinyobjloader/tinyobjloader

It's fairly mature and handles many of the parsing footguns you'll inevitably run into trying to write your own OBJ parser.

For simple operations like the dot product (that also map extremely well to SIMD operations), yes, the CPU is often better, as there not much actual "computation" being done. More complex computations where the data does not need to transfer between the host and device amortize that transfer cost across multiple operations, and the balance can quickly weigh in favor of the GPU.

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.

Non-linearity is the norm in industrial experimentation :)