Why Gaiwan Loves the Predictive Power of Universal Conventions

A one-stop-shop for your entire dev environment: bin/launchpad

Close to four years ago we released Launchpad, a tool which has been indispensible in our daily dev workflow ever since. In the latest Clojure Survey, over 85% of respondents indicated "The REPL / Interactive Development" is important for them. We already explained at length in our Why Clojure what exactly we mean when we say "Interactive Development", and why it is so important.

In order to do Interactive Development, you need a live process to interact with, connected to your editor or IDE. This is where Launchpad comes in. It focuses on doing one thing well: starting that Clojure process for you to interact with, with all the bits and bobs that make for a pleasant and productive environment. It's a simple idea, and we've heard from numerous people how it has made their life easier. But not everyone seems to get it.

Ovi Stoica has been doing great work on ShipClojure, and as part of that work he created leinpad, a Launchpad for Leiningen users. It's been very validating to see people pick up these same ideas and run with them. Launchpad is for Clojure CLI only, we switched away from Leiningen as soon as the official CLI came out in 2018 and never looked back. Leiningen vs Clojure CLI is perhaps a topic we can dig into in another newsletter, but needless to say it's good to see a Launchpad alternative for people still using Leiningen, by need or by choice.

The Leinpad release announcement sparked some interesting discussion on Clojurians Slack, going back to some of the Launchpad design decisions. Launchpad strongly recommends that people create a bin/launchpad script, just like we also recommend that people create a bin/kaocha script to invoke the Kaocha test runner. In both cases there are two related reasons why we feel strongly about this. We want both of these to become universal conventions, so that when you start working on a Clojure project for the first time, you can safely assume that bin/kaocha runs your tests, and bin/launchpad starts your development process. In any project you can put something in that location that does that job, regardless of your stack and setup. It's a form of late binding, and it means a new hire doesn't need to pore over the README, or worse, ask around, to know how they're supposed to run the tests or run a dev environment.

Each time people instead decide they prefer bb run launchpad, or clj -X:kaocha, or any other variant, they break the predictive power of that convention. They muddy the water for everyone. This is why we resisted a -X style entrypoint for Kaocha, despite later accepting a community contribution that implements one. A convention is only as powerful as its adoption rate.

Besides being a convention, it's also a place where you can customize the Launchpad (or Kaocha) behavior. For Launchpad this is especially important because the goal for the bin/launchpad script is to be a one-stop-shop for your entire dev environment. That can mean installing npm packages, running docker containers, loading stub data, anything you need so that a new contributor can arrive, run bin/launchpad, and be productive.

Recently a team member had trouble running Launchpad because their babashka version was out of date. They reached for the tool they usually use when confronted with "works on my machine" issues: Nix. Nix ensures a reproducible environment, where everyone is using the exact same versions and packages. It's like tools.deps but for system software, and solves some of the issues around Phantom Dependencies.

This meant replacing the bb shebang with nix-shell. This shows the power of a filesystem convention like bin/launchpad. The facade stays the same, but what's under the covers is now radically different.

-#!/usr/bin/env bb
+#!/usr/bin/env nix-shell
+#! nix-shell -i bb -p babashka
+#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/refs/tags/25.11.tar.gz

Later on I introduced GStreamer to the project, to support multimedia playback. This too is (partially) a system dependency, and some people on the team struggled to get it working. In this case I was able to build on the nix-shell approach, adding the additional dependencies. So instead of adding a section to the README that explains how to either brew or apt install gstreamer, I added the necessary bits to our one-stop-shop. And all the while it's still just bin/launchpad. I'd love to see a cultural shift where we no longer accept ten steps of outdated instructions in a README just to get a dev environment. Dev tooling is part of our job, and we do ourselves, our team members, and our employers an injustice by treating it with any less care than we give to the customer facing bits of our software.

#tea-break

At Gaiwan we share interesting reads and resources in our #tea-break channel.

EU Tech Map and European Alternatives: We care about EU's software rebellion to move away from American companies and doing things in-house, supporting OSS, etc. It also sets a benchmark and a path for other countries to follow.

The job losses are real — but the AI excuse is fake by David Gerard. Layoffs are done for economic reasons, but blamed on AI because that sounds better, and meanwhile the whole situation is used to get people to accept lower job offers. What's your experience with this?

An AI Agent Published a Hit Piece on Me by Scott Shambaugh. In case you haven't seen it already, this is 🤯

One or more of us is considering this really cool open source Linux device, by an Indian team. And not as expensive as you might have thought. (We are not compensated for writing about this Kickstarter project; we really just think it's cool.) So many devices, so little time...