# Caleb Stanford Blog

## Research areas

research

I’m on the academic job market this year, and have spent the last few months writing (and rewriting) application materials. It’s a process that really makes you figure out who you are as a researcher and it’s turned out to be surprisingly useful and fun. I designed a diagram of my research areas (actually, credits to Ariana for the final image, she made it in ChemDraw!) and I’m really happy with the way it turned out! See below (this is Figure 2 in my research statement):

I am thinking of making some visualizations of my research in other ways, maybe not for the research statement, but perhaps for my website. I have spreadsheet data for all the papers I’ve ever submitted, with conference tiers, rejections, areas, etc. and that could make for some interesting summary tables.

## Software Reusability PSA

research

PSA: vetted installation instructions and examples/ directory considered mandatory

Having been on academic “artifact evaluation committees” a few times, there are many ways the process fails to encourage some of the most important aspects of making software reusable. The biggest glaring problem is installation: in my experience, 90% of the pain of trying to reuse someone else’s software or git repository is just trying to get the tool and its dependencies installed, and the present system almost completely ignores this by having researchers submit pre-built virtual machines, so that the installation process is not checked at all by the reviewers.

Besides installation, all software should have an examples/ directory. I am surprised by how often I come across software that doesn’t, and I spend several minutes poking around trying to understand the software without much luck. A basic examples/ helps a lot more than well-documented code, unit tests, or even a README because it’s the first place I will go to see how I might actually use your project for some intended use case.

## On Finite Computational Complexity

logic research

Some notes on an idea for defining better computational complexity for finite languages, using regular languages: here.

Edit: Something I didn’t justify very well is why I called this computational complexity; it might be more appropriately called description complexity. But because regular expressions admit efficient evaluation roughly corresponding to their size, description complexity of the minimum regex can be taken as a proxy for the minimum computational resources required, if we restrict computation to that which is expressible using regular languages.