January 6, 2025

Reproducible Research in Computational Science (via)

I came across this paper through another Coursera course I'm exploring about reproducible research in preparation for a talk I'm giving in March and found it both enlightening and a little depressing. Enlightening because it offers an interesting perspective on some of the problems with the current state of data work that contribute to the replication crisis. As a software engineer, it's wild to me that it was not just acceptable but totally normal and inoffensive to publish exclusively the results of a computation, without providing any data or code that could allow someone else to reproduce the results. This is improving since the time this paper was published, but it is still very standard to find no indication of how a given analysis was run or result was achieved in a given paper.

The author describes one system their team at the journal Biostatistics implemented to tag papers with confirmed reproducible results which, at the time of this paper's publication, had been done successfully on 5 out of 125 papers. That was a little depressing to read. The author later points out that, like so many things in life, the standard we get is really just whatever the community is willing to expect and enforce.

link/#papers#reproducibility#research

dltHub (via)

I had a super interesting conversation with Ananth Packkildurai of Data Engineering Weekly today and a couple of interesting tools came up. One was this: dltHub. There are a lot of people trying to solve some of the main pain points in data engineering, and I'm convinced (like Ananth) that functional languages and approaches to software engineering have a lot to offer in solving them. This tool in particular appears to attempt to automate away some of the painful parts of the process, and I'm super curious to explore their approach. It seems like a really hard thing to do well. The problem of extracting data from traditional sources (DBs, files, APIs) and moving it elsewhere is well solved, but it's the increasingly complex transformations, large volumes, and disparate end use cases that are causing the strain with the current standard data stack.

link/#data-engineering#tools