How can we document software and computational analyses in such a way that others can convince themselves of their validity, and build on them for their own work? The question has been around for many years, and a number of attempts have been made to provide partial answers. This post provides a brief review and describes my own tentative answer, inviting you to play with it. Explainable AI is a hot topic today.

Thirty years after my first contact with computational (ir)reproducibility, I am happy to note that many things have improved. Reproducibility, computational and otherwise, is increasingly recognized as an important aspect of scientific quality control, and mostly considered worth striving for.

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.