At the recent SciCodes Symposium, I brought up the question of reviewing research software during the panel discussion. One panelist then raised the question of why we should review research software. I found this question surprising at first, but I do agree that it deserves an answer. Here is mine.

This is a follow-up to my earlier post entitled "Going for robustness", focusing on scientific research.

I suspect that most people in the Western world (at least) are realizing that we are living in interesting times. News of floodings, droughts, and wildfires are ever more frequent. We hear that this is due to climate change, which most governments promise to fight, but don't. Our economies keep growing, but our quality of life is not improving. Digital tools are ever more prominent in our lives, but don't make us happy either.

This is a contribution to the Challenge problem: Fearless extensibility by the Malleable Systems Collective. As superheroes know very well, with great power comes great responsibility. Malleable systems offer a lot of power to their users. In exchange, users have to take responsibility for the system they have tailored to their needs, since there is nobody else to blame.

Yesterday I participated in the International workshop “Software, Pillar of Open Science”, organized by the French Committee for Open Science. In the course of the various presentations and discussions (both in public and during coffee breaks), I realized that something has been absent from such events all the time: the vast majority of scientists.

Regular visitors to my blog have probably noticed that it looks different now. However, the visual changes are only a side effect of a more profound change: I now use a different static site generator, coleslaw.

This post is a follow-up to my previous one, Deconstructing the Mastodon client. My topic is a scenario that traditional Mastodon clients handle rather badly, wheres my home-grown solution handled it very well: lengthy and branching conversations. Such conversations happen all the time on social networks. Someone posts an interesting question or observation, which is commented by many others.

Ever since I joined Twitter in 2011, and then moved to Mastodon in 2022, I have been unhappy with the timeline view proposed by both of these communication platforms as their main interface. Now I have finally done something about it: I wrote my own Mastodon client. Or perhaps rather a non-client, because the concept of "the client" is a big part of what I disliked.

A few years ago, I discovered Mike Caulfield's The Garden and the Stream: A Technopastoral and understood why I wasn't happy with my blog. Blogs are streams, timelines of posts. Each post has a timestamp, and is considered "finished". Later changes are technically possible, but culturally limited to corrections. A blog post is considered a published essay, and therefore comes with a date of publication.

A few days ago, Google announced its experimental project Open Source Insights, which permits the exploration of the dependency graph of Open Source software. My first look at it ended with a disappointment: in its initial stage, the site considers only the package universes of Java, JavaScript, Go, and Rust. That excludes most of the software I know and use, which tends to be written mainly in C, C++, Fortran, and Python.

In my last post, I have discussed the two main types of scientific models: empirical models, also called descriptive models, and explanatory models. I have also emphasized the crucial role of equations and specifications in the formulation of explanatory models. But my description of scientific models in that post left aside a very important aspect: on a more fundamental level, all models are stories.