Post

Isolating a program from complex systems for testing is a lot of effort. Often solved with dependency injection of mocks, or exterior composition (to mocks). Mocks can drift and DI introduces codepath complexity. So: Build mock env from specs

Distributing software libraries for multiple languages is extremely costly for a software company (such as bluesky). Quality drifts between languages, maintenance burden is huge. So: Build _ API in our teams' lang from specs

This one might be too extravagant so we'll see, but... Writing software for each platform (native ios, native android, web, etc) is extremely costly and requires middleware ecosystems like react native So: Build app for target platform from specs

0 reposts63 likes

Amending upstream is extremely hard to do. Monkeypatching, inheritance, configuration (if allowed), or forking. So: import spec, amend with your specs, lock in with tests

one thing that may threaten people: if specs are the valuable artifact, couldn't you 1) have frontier LLM describe all the specs of an enterprise SW app by analyzing its surface, docs, input, output 2) have LLM recreate that enterprise app's full functionality, writing the underlying code itself

Ok ok wait, then you build a reference endpoint - a server that's basically a dummy, no live data, stateless as far as possible - that can be used during development to verify against. Then it's basically a oneshot project to build apps on any platform, any language.

Oh I so want this, a static pds and a static api server that return known results and reject api calls that aren’t in a known state. And publish the JSON for both requests and responses.

UB in C is not "anything you *didn't* explicitly specify to work the same way [may vary]". Almost all behavior is defined in C, with a (mostly) well-defined list of exceptions. This is very different from everything being undefined unless you explicitly nail it down

Yeah. I took a run at it about 5 months ago, but didn't have time to get to (that's right!) the 2nd 80%, so I had to leave it at "promising but unproven."

The second 80% still needs someone with a deep understanding of the language and platform itself, for now. But spec and harnessing means that you only need 1 or 2 platform experts, instead of multiple teams.

“Nondeterministicly build other platform from specs” is a bandaid. If the spec is precise enough to do that effectively, it will look *a lot* like real code. And If we’re close to real code, we might as well be writing it with a compiler.