zero width jschear

AI Vibecheck, Q2 2025

Sat, 26 Apr 2025 00:00:00 GMT

We're solidly in the AI backlash backlash. Here are some thoughts about using large language model-based tooling (like Claude Code, Cursor and Goose) for software development in 2025.

On determinism

One thing that drew me to computing in the first place was the sense that, however complex computers were, they were fundamentally understandable. Computers aren't magic. I always find it extremely empowering when I can figure out a tricky bug by peeling back a few layers of abstraction.

LLMs are closer to magic. Unless I've missed some new development in interpretability, you can't stare at the matrices powering them to figure out why a model has given you a certain response. If you're having trouble with a tool, the solution is fuzzy: try a different model; try to stuff more relevant code in the context window; IDK, have you tried writing your prompt in all caps or asking more nicely? I would find it frustrating to be responsible for the quality of such a system. Maybe someone will figure out how to make useful assertions about the quality of their output.

Nondeterminism isn't new: probabilistic data structures are useful, and everything these days is asynchronous and distributed and horrifyingly complex. But do we have to inject more chaos into everything? I am heartened by newer tools that use LLMs to write a script or plan for invoking deterministic tools.

Also, just an aesthetic objection: dealing with tools that are confidently and cheerily wrong is annoying! Have some shame!

AI as anti-expertise

LLM tools are great at creating greenfield, prototype apps. I support the democratization of software engineering: I'm excited for more people to try building software, even if they vibe-code their way to victory.

But some of the excitement around AI tools feels like it's trying to devalue software engineering broadly. If a CEO can clone a SaaS app in a few days, who needs those highly-paid engineers? Part of what I love about writing software is understanding a topic deeply and crafting something that will stand the test of time, and I think that will still require deep expertise.

There's undoubtedly some "kids these days" energy here -- people have long made similar arguments whenever a new technology makes the practice of programming more approachable. "Real engineers write in assembly code." "How can you call yourself a programmer if you've never done manual memory management?" "These web developers are ruining the desktop with their Electron apps." I don't want to gatekeep software development.

I just hope that the vibe-coders still have curiosity about the systems they're building on top of. In the near future, I see a lot of haphazardly built software, in desperate need of people to understand and maintain it. Maybe not all that different from today.

First Steps with OCaml

Tue, 12 Mar 2024 00:00:00 GMT

These days, everyone is talking about ML. They mean Meta Language, right? (Let's pretend they do.)

Last year I attended the Recurse Center,[^1] a retreat for programmers, and one of my goals while at RC was to get more comfortable and productive writing in a functional programming language.

I was first exposed to the functional paradigm in college, while taking a programming languages course. At that time, my experience and understanding of programming were entirely influenced by Java and Python, and my poor uninitiated brain practically melted the first time we transformed an imperative loop into a recursive function. I finished that course excited about functional programming, but also intimidated by the jargon that came along with it (and these curly fellas: λ).

I've spent the past few years writing Kotlin (often using RxJava) in the context of an Android application, and have been increasingly convinced that many of the priorities of typed functional programming (using algebraic data types to model your domain, immutable data structures -- or at least judicious use of mutable state) are well-suited for developing software that is both understandable and evolvable. Even in languages that don't particularly encourage a functional style, limiting the use of mutable state minimizes implicit dependencies between parts of a program, making it easier to understand those parts in isolation and compose them without fear. And the general concepts seem to keep popping up in other areas I'm interested in, like build systems.

All that to say, I was eager to try out a more functional language. So why OCaml? Why not Haskell, Clojure, Scala, Elm, Scheme, Racket, Idris, Koka, Roc, Common Lisp?

OCaml has proven industry usage inside of Jane Street and Facebook. Regardless of whether you'd want to work at one of these places, they definitely have a track record of writing software that accomplishes stuff in the real world. (Has side-effects?)
OCaml has a pragmatic approach towards functional purity that I appreciate. You can reach for mutable state when you really need it, and evaluation is eager, so you don't have to learn a new evaluation strategy alongside a new language like you do with Haskell.
I'd been vaguely following along with the journey to add parallelism to OCaml after hearing about it on Jane Street's Signals and Threads podcast, and wanted to better understand OCaml's runtime system.

For a more complete discussion of "Why OCaml" and how it compares to other popular languages, I'd recommend reading this paper from Yaron Minsky of Jane Street (or watching his similar talk).

Tooling

One of my first priorities when learning a new language is setting up a comfortable development environment. Maybe I'm old fashioned -- I feel like the latest hotness is shoving all this stuff into a docker container or running it in the cloud somewhere -- but having a solid understanding of what tools are available, how they interact, and how to set them up on my machine is important to me.

Package management

opam is the OCaml package manager[^3]. opam can manage multiple side-by-side installations of the OCaml compiler, in environments it calls "switches". So there's no need for a separate tool to manage multiple compiler versions like nvm or rbnenv or pyenv or asdf or hermit or (if you've reached true enlightenment) nix.

My appreciation for the functional paradigm hasn't yet spread to my package management habits[^2], so on macOS I installed opam with homebrew, and followed the instructions it spit out to modify my shell environment.

$ brew install opam

Building, creating a project

The most popular build system for OCaml is dune (née jbuilder) created by (you guessed it) Jane Street. Dune itself is distributed as an opam package, so go ahead and install it:

$ opam install dune

One thing dune provides is an init command, which will create some reasonable project scaffolding:

$ dune init proj project_name

~/ocaml/
$ tree project_name
project_name
├── _build                    // Build artifacts. You'll want to .gitignore this.
│   └── log
├── bin                       // Where code for your application's entry point will live.
│   ├── dune
│   └── main.ml
├── dune-project              // Project-level dune configuration.
├── lib                       // Where library code will live. Create an .ml file in here to define a new module.
│   └── dune
├── project_name.opam         // An opam configuration file, should you ever want to publish your project. This is generated from the dune config.
└── test                      // Where test code will live.
    ├── dune
    └── test_project_name.ml

Last but not least, let's create a new switch.

opam switch create ./ 4.14.1 --deps-only

This creates a local switch, i.e. one that is stored in an _opam/ directory within the project instead of the default location. I prefer using local switches to isolate my project environments from one another, at the cost of having multiple installations of the toolchain on my machine.

Editing

You can grab the ocaml LSP server and formatter with opam. You'll have to create an .ocamlformat file to activate the formatter.

opam install ocaml-lsp-server ocamlformat
touch .ocamlformat

If you're using VSCode, the OCaml Platform Extension will hook up the OCaml LSP to your editor, giving you type hints inline.

The "standard" library

After writing a bit of code, I naturally found myself on Stack Overflow, the OCaml forums, and the OCaml discord, trying to find answers to my beginner questions. (I almost bothered a guy wearing a Jane Street shirt that I saw at the gym, but I resisted.) The first question experienced OCaml programmers seem to ask beginners who are soliciting help is "are you using Base and Core?" To the uninitiated, that sounds a lot like "are you using the standard library?"

One of the stranger aspects of the OCaml ecosystem is that it's sort of bifurcated into two worlds: code that uses the (standard) standard library, and code that uses Jane Street's Base and Core libraries, which are a wholesale replacement for the standard library. There are good reasons for following either path, and I don't feel particularly opinionated yet, but it's worth keeping this distinction in mind when encountering OCaml code in the wild or choosing libraries to use in your project. More on this topic on OCamlverse. There's also another popular stdlib-shaped library, batteries.

Lastly, a pile of helpful links:

The textbook for CS 3110 Data Structures and Functional Programming at Cornell.
Real World OCaml.
The OCaml lab from Stanford's CS242 Programming Languages class (Fall 2019).
https://www.baturin.org/docs/ocaml-faq/
https://borretti.me/article/two-years-ocaml
https://osa1.net/posts/2023-04-24-ocaml-thoughts.html

[^1]: If you're reading this, it's extremely like that you either a) have already attended RC b) should apply to RC. Do it!

[^2]: This was true at the time of writing, but now I've gone down the nix rabbit hole. Oops!

[^3]: There's also esy, and alternative package manager that appears to try to be a bit more friendly for those coming from the npm/yarn world. It also appears to encourage using lockfiles to pin dependencies which I certainly support, but it wanted me to install it via npm so I decided to stick with opam. If I was building a serious project in OCaml I'd probably reevaluate, and throw Bazel in the ring too.

iOS focus app

Tue, 30 May 2023 00:00:00 GMT

I'm working on an app to solve a tiny frustration I have with iOS.

iOS's new-ish "focus" feature lets you create a notification allow- or deny-list while in a "focus" mode. Meanwhile, "Screen Time" lets you block applications entirely, based on daily time limits or a nightly "Downtime" mode.[^1]

But what I'd like to do is allow-/deny-list entire apps on demand (a la SelfControl -- which helped me get through college), all from control center. There are a few apps that fill this gap, but they're all subscription based. Fair enough, get paid, but I don't need a ton of features and slick UI here.

Most of my iOS experience has been focused on developer productivity and CI -- so these are some notes on getting started in app development in 2023.

Tooling

I've been moving towards managing all of my development tooling with nix, but Xcode can't be installed via nix (as far as I can tell -- I imagine there are licensing issues), and Xcode really wants to manage the entire Swift toolchain. So no nix flakes here.

At a previous job I used bazel to build a large iOS codebase, but that feels overkill for a project with single-digit source files. Plus, .pbxproj merge conflicts aren't too bad when you're developing solo.

Code formatting

swift-format is nice. I built it from source and threw it in ~/bin.

To format all swift code in a directory (-in place, -recursively):

$ swift-format -i -r .

SwiftUI

I'm watching a few videos from a Stanford course to get up to speed on SwiftUI and how it fits into general app architecture.

[^1]: I do not envy the folks who had to figure out how to reconcile the overlapping concepts of "Do Not Disturb", "Sleep", "Screen Time" and "Downtime" with "Focus." There's a default "Sleep Focus," which is a pretty funny way of describing what sleep is all about.

It begins

Tue, 28 Feb 2023 00:00:00 GMT

I’ve built and thrown away more personal blogs than I’ve written blog posts. Maybe this time will be different!

Tech stack

This blog is a lightly-customized clone of the Astro blog template and is hosted and deployed using Vercel. I may later manage content with a headless CMS, but at the moment I’m authoring posts in markdown (or mdx) and using Astro’s static site generation.

I find the abundance of full-stack web frameworks to be both overwhelming and exciting (especially coming from mobile development). I’m heartened by the industry-wide adoption of TypeScript because I’m not sure how to be productive in the long term when using dynamically-typed languages.

After puttering around with Next.js, Remix, and a few other frameworks (meta-frameworks?), I decided to move forward with Astro, which I learned about on an episode of the devtools.fm podcast. This wasn't a particularly well-considered decision; I mainly just wanted to throw something online. (This was a case of vibe-driven-development.) htmx and fresh are also on my list of web technologies to explore.

The blog’s title comes from one of my favorite Unicode codepoints, the zero width joiner (U+200D).