Show Notes
I'm always interested in what factors shape the design of a programming language. This week we're taking a look at a language that's wholly shaped by its need to support a very specific kind of program - audio processing. Anything from creating a simple echo sound effect, to building an entire digital instrument based on a 17th-century harpsichord.
The language in question is Faust, and this week we're joined by Romain Michon, who works on and teaches Faust, as we look at how it's designed, what kind of programmers it's for, and how it does the job of turning audio-pipeline definitions into executable code.
And one of the surprising parts of that compilation strategy is the decision to have it compile to multiple targets, from the expected ones like C and Rust, to the exotic destination of FPGAs (Field Programmable Gate Arrays). FPGAs are like reprogrammable circuit boards, and Romain dives into Faust's attempts to go from a high-level description of an audio program, all the way down to instructions that tell a chip exactly how it should wire itself.
So rather aptly for a technology podcast, we start this week with what your ear can hear and go all the way down to logic gates and circuit boards…
–
Try Faust in the Browser: https://faustide.grame.fr/
Faust Online Course: https://www.kadenze.com/courses/real-time-audio-signal-processing-in-faust/info
FPGAs: https://en.wikipedia.org/wiki/Field-programmable_gate_array
VHDL: https://en.wikipedia.org/wiki/VHDL
Verilog: https://en.wikipedia.org/wiki/Verilog
Grame: https://www.grame.fr/
The (Strawberry Jam) Gramophone: https://www.grame.fr/articles/gramophone
Gramophone Workshops: https://www.grame.fr/evenements/atelier-gramophones-65ca16b19fec4
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Twitter: https://twitter.com/krisajenkins
More from Developer Voices
How would you manage 30 million lines of PHP? You can't rewrite it - you'd be fired long before you delivered. That was the problem facing Facebook around 2011, and their answer was to add a type system, giving birth to the Hack language. But adding types to PHP turned out to be the easy part. The hard part was building a type checker that developers used to "edit, save, refresh" would actually tolerate. So how do you type-check tens of millions of lines of code fast enough that nobody notices?
Building something people actually want is supposed to be the happy ending. But it arrives with a bill attached: feature requests you didn't ask for, pull requests you'd rather not maintain forever, users demanding the one thing you swore you'd never build, and — if you're unlucky — a company where the sales team quietly starts deciding what engineering works on. DuckDB has spent the last two and a half years working through that list. So how do you stay a database engineering team when success keeps trying to turn you into something else?
My guest this week is James Brown, an engineering lead at Schroders, and that's a useful vantage point — asset managers carry all the regulation and organisational weight of a bank, mixed with the first-to-market pressure of a startup. James starts with his own "Claude mania": months of agents running around the clock, and the wave of anxiety that hit him one morning walking to the shop without one running at home. From there, Clair — the plugin he's building to give coding agents proximal awareness of each other, using git orphan branches as a zero-infrastructure message bus; why AI behaves like oxygen in a room full of tiny fires; what "going well" actually measures inside a regulated firm; and why he thinks team sizes won't change, even when the number of teams does.
There's a problem that's bugged the database industry since the 1980s: you run an expensive query over millions of rows, cache the result, and then a single new row arrives. Logically that's one small update, but most engines throw the cached answer away and recompute everything from scratch. Some will handle changes incrementally, but only for "simple" queries - and the rules for what counts as simple are arbitrary and brittle. So can you incrementally maintain *any* SQL query, no matter how complex? For decades the answer was no. Then an award-winning paper called DBSP proved that the answer is yes - all queries are simple enough.
AI is changing the way we all build software — that much seems clear. But the landscape is moving so fast that even the people paid to keep up are struggling. MCP or skills? Fine-tune or just prompt? LangChain or let a thousand agents loose? With almost 70 competing technologies and a shelf life of maybe six months on any advice, how do you figure out what's actually worth your time?