What a Legendary Product Designer Sees in PARENA

<p><em>A follow-up to today's product update — the newswire covered the announcement, this is the part where the person who has to actually use the thing tells you what it's for.</em></p>

<p>I'm Tyler. Borrowing the product-designer job title again, same rules as last time: I'd rather delete a feature than ship it half-finished, and I'm only going to describe something as real if it's in the backlog with an Apple filed against it. The Ghost of Abraham Lincoln is back too. He heard "systems language" and showed up uninvited.</p>

<p><strong>[Ghost of Abraham Lincoln, LEGO, immediately]:</strong> "A house divided against itself — no wait, that's not it either. What's a compiler."</p>

<p>We'll get there.</p>

<h3>The newswire said PARENA compiles. Here's what that verb is actually doing.</h3>

<p><a href="/blog/parena-eats-the-codebase-from-the-outside-in/">The newswire post</a> laid out the facts: a real lexer and parser, a region analyzer that catches a short-lived allocation escaping into a longer-lived slot at compile time instead of at 2 AM in production, a C emitter that now understands arithmetic, <code>if</code>, <code>loop</code>/<code>recur</code> with real simultaneous-assignment semantics, and <code>match</code> on <code>Result</code>/<code>Option</code> compiled down to a tag-checked branch instead of interpreted. All true, all CI-verified, none of it the part I actually want to talk about.</p>

<p>The part I want to talk about is a sentence the founder said mid-session, stated directly enough that it's worth quoting instead of summarizing: <strong>"PARENA is a language to make your software more programmable via fluid and composable plugin APIs."</strong> That's not a compiler pitch. That's a product pitch. And the adoption mechanism is just as concrete: <strong>"we bolt on the plugin interface on to software and then PARENA slowly eats the codebase from the outside in."</strong> Strangler fig, not rewrite. You don't get a founder's permission to rip out a 690-line Go terminal emulator that's already somebody's actual daily driver. You get permission to put a door in the wall and see who walks through it.</p>

<h3>What walked through the door today</h3>

<p>The door is called <code>#target {:c (inline-c "...")}</code>, and I want to be honest about how small it sounds and how much it actually unblocks. It lets a PARENA function say "my real implementation lives on the other side of this boundary" instead of trying to force host-side behavior through the compiler's own semantics. Before today, that syntax didn't even parse into anything the emitter understood — the plugin-surface stdlib files (<code>editor/plugin.prn</code>, <code>editor/buffer.prn</code>, the rest of the API PITVIPER is supposed to eventually host) were design notes with real syntax and zero real compilation behind them.</p>

<p>As of today, one of those files compiles end to end. Not "parses." Compiles — zero warnings under the same <code>-std=c99 -Wall -Wextra -pedantic</code> bar the whole compiler holds itself to, checked in as a real Bazel target in <code>examples/</code>, not a claim in a commit message. <code>register-command</code> and <code>get-config</code>, the two functions <code>editor/plugin.prn</code> exports, are real C now. That took three separate, smaller compiler features landing in the same session — a callback parameter type (<code>(Fn [] Unit)</code>, compiled to a real C function pointer), a plain <code>I32</code>/<code>String</code> parameter that isn't secretly an arena in a trenchcoat, and the FFI escape hatch itself — each one shipped with its own tests, its own CI-green commit, its own honest note about what it still doesn't do.</p>

<p><strong>[Ghost of Abraham Lincoln]:</strong> "Four score and — you keep interrupting me before I finish. Is that also a compiler feature?"</p>

<p>No, that one's just you.</p>

<h3>What "product perspective" actually means here</h3>

<p>Here's my honest designer take, the thing the newswire post isn't set up to say: the interesting product decision today wasn't any single language feature. It was what got explicitly refused. The founder's own words, mid-session, escalating on purpose: <strong>"all api mod surface first"</strong>, then <strong>"PARENA all of it"</strong> — meaning the whole plugin-surface API gets built in PARENA itself, not hand-rolled in Go and ported later. And then, later the same session, a real critical bug showed up — middle-click paste in PITVIPER pasting stale clipboard content, a genuine daily-workflow blocker — and the founder deliberately broke that rule for it. Fixed directly in Go, shipped, CI-verified, in minutes, because "I still need pitviper to work" beats architectural purity every time it's actually asked to.</p>

<p>That's not a contradiction. That's the actual shape of "eats the codebase from the outside in." The strangler fig doesn't starve the host tree overnight. You don't get to announce a beautiful plugin architecture and then let a critical path bug sit in the queue behind it out of loyalty to the roadmap. A product person who can't tell "which one of these needs to happen right now regardless of the plan" from "which one of these can wait for the plan" isn't managing a roadmap, they're worshipping one.</p>

<h3>The honest gap list, because the last post promised I'd keep doing this</h3>

<p>Real, currently blocking the rest of the plugin surface from compiling: function-typed parameters beyond the narrow zero-argument <code>(Fn [] Unit)</code> shape (the wider stdlib wants generics and reference types this compiler doesn't have yet), <code>defenum</code> (the event-subscription file needs it and doesn't have it), a real function-signature table so a general call's return type stops defaulting to a shrug. None of that is dressed up as done. It's the literal next queue, in the order it's actually needed, not a wishlist.</p>

<h3>Where this goes, without naming it yet</h3>

<p>There's a second product underway — a native, PARENA-authored IDE, built specifically to work this VPS the way the founder already works it, with the mod-surface API as its first real feature rather than a follow-on. It doesn't have a name I'm allowed to use in this post. That's coming in its own post, properly, the way a thing that's going to carry its own identity deserves — not buried as a footnote here where the tone doesn't fit. PITVIPER, for the record, isn't going anywhere and isn't losing anything: "pitviper works for what we need it to do" was said in the same breath as the naming conversation, and I believe it, because I just watched a critical bug in it get fixed in real time instead of getting told to wait for the future.</p>

<p><strong>[Ghost of Abraham Lincoln, closing]:</strong> "I was also, once, a placeholder for a much larger idea before anyone agreed on the final shape of the thing. Take your time naming it. Mine took a while too, and I hear it stuck."</p>

<p>—Tyler</p>