I absolutely understand what you're saying. It makes complete sense. But I will never, ever shake the sense that software that isn't as fast as possible is offensive, immoral, delinquent -- the result of sloth, lassitude, lack of imagination, and a general hostility toward our noble Art.
"Fast enough" will always bug me. "Still ahead of network latency" will always sound like the dog ate your homework. I understand the perils of premature optimization, but not a refusal to optimize.
I'll put TB Barricade against Pro-L 2 and TB Reverb against Pro-R for sure. I mostly use other stuff for EQ and compression, but those two are really very similar to the FB offerings.
Really. It amazes me that I still find out about new Linux plugins after years of producing music on the platform. It could not have been easy to compile this; the information is all over the place online.
The ability to filter (!) for compression, saturation, etc. is so great.
Author, here. This is exactly the question I was trying (perhaps ineptly) to pose: If we designed a programming language with the idea that it would be primarily or exclusively vibe coded, what would that language look like? Might it look something more like Lean? Or more like theorem provers in general? Or would it look more like a natural language PL (think Inform 7)? Or what about a heavily declarative DSL like FAUST (for audio DSP)?
None of our existing programming languages were designed for quite the circumstance in which contemporary programming now finds itself; they all address an ergonomic situation in which there are humans and machines (not humans, machines, and LLMs).
It's possible, I suppose that the only PL that makes sense here is the one the LLMs "knows" best, but I sort of doubt that that makes sense over the long term. And I'm repeating myself, but really, it seems to me that a language that was written entirely for the ergonomic situation of human coders without any consideration of LLMs is not addressing the contemporary situation. This is not a precise analogy, but it seems to me a little like the difference between a language that was designed before vs after multicore -- or before vs after the internet.
There might be. And I certainly bear no ill will of any kind toward the project or its devs. But I am in terminals all day long, and I hesitate to use one that is written in a language that hasn't yet hit 1.0.
Foot is way more my speed. Fast, extremely stable, and (most importantly) barely noticed. When it comes to terminals, the slightest flicker -- the merest bug -- and I'm gone. And that happened to me with both ghostty and alacritty.
I keep hearing this, but I fail to see why "the massive, well-maintained set of critical libraries upon which UNIX is based" is not a good reason to use C in 2025.
I have never seen a language with a better ffi into C than C.
I take a more skeptical view of the relationship between politics and technology (not specifically on cryptography, though I think my point stands in this context) in a recent (scholarly) article:
Abstract: A consideration of the political meaning of software that tries to add greater philosophical precision to statements about the politics of tools and tool building in the humanities. Using Michael Oakeshott's formulations of the “politics of faith” and the “politics of skepticism,”[Oakeshott 1996] it suggests that while declaring our tools be morally or political neutral may be obvious fallacious, it is equally problematic to suppose that we can predict in advance the political formations that will arise from our tool building. For indeed (as Oakeshott suggests), the tools themselves give rise to what is politically possible.
"Fast enough" will always bug me. "Still ahead of network latency" will always sound like the dog ate your homework. I understand the perils of premature optimization, but not a refusal to optimize.
And I doubt I'm alone.