Stream: show and tell

Topic: `pinterm`, a terminal pinball game that is also Web-ported


view this post on Zulip Peter Marreck (Oct 10 2026 at 22:26):

https://pmarreck.github.io/pinterm/ (web frontend)
AI-authored (I hate the term "vibe-coded") a terminal pinball game in Roc, then ported it to WASM/Web using libghostty. A Nix-controlled project (hopefully you're all into that).
Features: Multiple tables, sound, multiball, super retro terminal graphics rendered from a higher-resolution internal model, etc.
https://github.com/pmarreck/pinterm
Interesting note: The AI seemed to appreciate me having it code in Roc (!!!) because of its additional restrictions over the typical languages it is asked to code in, as well as the lack of having to pay much of a price for them. ;) It may have helped that I had already created a "writing-roc" skill with up-to-date information on Roc features and correct coding practices.
(When I had that written, the AI said, "I couldn't help noticing that based on our many interactions, this looks like your ideal language, in terms of the features you are constantly looking for." Me: "I know. That's why I sponsored it. Let me know when you're ready to rewrite all the goddamn Python." ;) )

view this post on Zulip Steve Howell (Oct 10 2026 at 23:04):

Nifty! I did a similar exercise recently with compiling games like Snake to two different UI targets. See #show and tell > browser canvas apps (and roc-ray) for more details. I see that there was a little C in there too haha.

view this post on Zulip Karakatiza (Oct 10 2026 at 23:35):

IDK if pixelating pinball is an original idea, but the gameplay is neat!
What Claude complimented about Roc - could it have been prompted by the text in your skill?

view this post on Zulip Aurélien Geron (Oct 11 2026 at 02:21):

Nice! Could you please share that Roc skill you wrote?

view this post on Zulip Peter Marreck (Oct 11 2026 at 05:40):

@Karakatiza I think it was simply due to the amount of guidance and simply "what it knows about me" (I work with AI a TON) and my long-term focus on basically all of the things that Roc has chosen as fundamentals (hat tip to @Richard Feldman). I don't know if someone else's AI would say the same, but when mine was like "yeah, this language is 1000% you" (essentially), I was actually not surprised, lol.

view this post on Zulip Peter Marreck (Oct 11 2026 at 05:41):

@Aurélien Geron @MagicMan https://github.com/pmarreck/llm_skills/tree/yolo/writing-roc
Feel free to raid the other skills in there.

view this post on Zulip Luke Boswell (Oct 11 2026 at 10:14):

Love it. Hope you dont mind I also posted on the Reddit page https://www.reddit.com/r/roc_lang/s/A212TZiMho

view this post on Zulip Richard Feldman (Oct 11 2026 at 20:16):

I'm impressed that it's playable on mobile in a browser too :smiley:

view this post on Zulip Karakatiza (Oct 11 2026 at 21:10):

Since you're heavily AI authoring, you may want to try roc-syntax-mcp - it has a powerful function search feature across packages, platform and your project, which the LLM actually uses instead of grepping, saving time

view this post on Zulip Peter Marreck (Oct 11 2026 at 22:54):

@Karakatiza
funny, I already wrote and have been using my own solution for more or less that very thing a number of months ago, https://github.com/pmarreck/codescan, although I just realized that it MAY not have a Roc plugin yet... this will now be rectified

view this post on Zulip Peter Marreck (Oct 11 2026 at 22:57):

it's basically semantic code search and tagged edits.
i've tried to make it better than the builtin harness tools for said purpose; so far so good

view this post on Zulip Peter Marreck (Oct 11 2026 at 22:59):

@Richard Feldman Well with Roc, Zig and Rust all supporting WASM builds (which was a fantastic architectural decision IMHO btw, I think WASM will acquire increasing importance), and GPUI etc. also supporting WASM, stir in a bit of AI to help wire it up and it's almost an afterthought to have Web build outputs now, which is of course fantastic. Case in point, just made these by forking the original projects and adding Nix and Web/WASM support (not Roc, but still cool):
https://pmarreck.github.io/wordcraft/
https://pmarreck.github.io/gridcraft/

view this post on Zulip Karakatiza (Oct 11 2026 at 23:00):

Wow, that looks powerful. I understand partial signature search works, too - signatures are ranked in the response. Mine is very-much ad-hoc, not generic, purpose-built for roc - it handles partial queries like ceil : -> Dec. It ranks by signature match and name

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:02):

I basically dogfood all my own tooling on principle (also because you can't trust the AI, although this is slowly getting better); codescan is one of my better ones

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:02):

one thing i'd recommend is jina-code-embeddings-1.5 for the index portion; but I couldn't find one that worked out of the box... AI (of course, sigh) fixed it to work with oMLX, which I use on my Mac via Tailscale

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:04):

@Karakatiza it's working on Roc partial-query support right now; will be pushed in a few mins or so. I didn't actually have Roc support, so that's going up too.

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:12):

I am working on 2 apps with Zig backends and GPUI Rust frontends that work on 3 OS'es, 2 chip archs and communicate over a socket... in the course of doing so I had discovered a few Zig bugs; they disallow AI in any form so I had the AI draft the PR, double-checked everything manually (which is fine, that should be done anyway) and they accepted them "from this human" ;)

Anyway, I'm glad Roc's posture on AI is... I'm going to guess something like "optimistic skepticism" (which is the correct posture for all things IMHO lol)

view this post on Zulip Karakatiza (Oct 11 2026 at 23:17):

Just now learned of GPUI. Did you need a high-performance UI? (complex visualization algorithms?)

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:23):

@Karakatiza
No. But I love the Zed editor (hah, I believe @Richard Feldman is also working there!), and I wanted a good, stable, cross-platform UI toolkit (especially one that was already being dogfooded by a production app) and didn't like the other options available at the time (although I think there's more coming, which is FINE BY ME!)

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:24):

The apps I'm making are both utilities. Nothing glamorous, although they help solve a real problem and one of them wouldn't have been even possible for a single dev to do at all before AI.

They started out as "AI/agentic POC's" basically. But are useful in their own right.

Now I just need to release them. I'm close. ;)

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:27):

Lots of issues from AI-written code that is over 6 months old (but lately, kind of startling improvements!). Lots of me figuring out the right controls to use to basically force the AI to do things correctly. I wrote a doc explaining one of the main concepts, which was actually inspired by my past experiences working as a coder for implementing Sarbanes-Oxley controls for auditors:
https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
It's called "MFIC" (Mechanically-Falsifiable Independent Controls"
(Turns out that there is another thing MFIC can stand for. Call it prior art. I was OK with that. Hint: "Mother______ In Charge" LOL)

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:28):

Ever since I told agents to adhere to this, code quality seems to have gone up, and they've even quoted it back at me when _I_ was inadvertently trying to violate it, LOL (I love it when that happens)

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:31):

Anyway, Roc is VERY well-aligned to "profit" (marketshare-wise) in a world where agents write most if not all of the code.

You are seeing that happening with Rust right now. But we know why Roc is superior to Rust in a bunch of use-cases, and that's where Roc will also gain.

view this post on Zulip Peter Marreck (Oct 11 2026 at 23:33):

Opinion: As much as I also like Zig, Zig's conscious and arguably premature aversion to AI is going to hurt it rather severely.

view this post on Zulip Karakatiza (Oct 11 2026 at 23:40):

Life will judge them, as one saying goes.
Never liked Rust tbh :sweat_smile: On one hand, Roc is not directly comparable to Rust - different core properties. On the other hand, Rust is nowadays being misused for projects that don't need its benefits (super high performance with compile-rime correctness); there Roc is very well positioned compared to Rust and, as Richard pointed out in interviews, it in principle can (should IMO) overtake Go, Java etc. Roc is decently performant and hard to get wrong due to functional nature and strong type system.

view this post on Zulip Karakatiza (Oct 11 2026 at 23:42):

Hot take: with LLMs the "ecosystem maturity" is a non-issue for Roc. You can vibe-code any dependencies you need, the only limit is your own red tape.

view this post on Zulip Karakatiza (Oct 11 2026 at 23:42):

You are seeing that happening with Rust right now

Could you elaborate a bit? :slight_smile:

view this post on Zulip Peter Marreck (Oct 12 2026 at 00:53):

https://getartcraft.com/
they vibe-coded ALL Adobe apps via Rust. Their Photoshop equivalent opens in like... a half a second. It's frankly embarrassing. And (as I linked earlier) they're working on Microsoft Office apps as well. And all compile to the Web of course as well. WASM is FAST.
DHH (think of him what you may) has been trying to sell "just rewrite it by vibe-coding it in Rust" for a while now. His new Linux distro, Omarchy, takes full advantage of this apparently.
Then of course there's the infamous port of Bun from Zig to Rust, which was supposed to be "temporary", and then ended up apparently being useful enough to just friggin' switch to completely.

The thing is- agentic coding will absolutely benefit from every available restriction (typing, entire classes of bug made impossible, etc.) and Roc has those as well. But Rust is just... you know... still more popular. But arguably way better than C. ;)

view this post on Zulip Peter Marreck (Oct 12 2026 at 00:55):

Here's my personal bias: I can't stand Python and Go. I am hoping that trivial rewrites via agentic coding will cause a collapse of those spaces and an expansion of Roc, Rust, perhaps Zig (needs a few more restrictions IMHO but eh, that's why Roc got rewrote into it so...), Elixir, Lean 4 (proofs for hot paths = gold), and any other language that provides good restrictions and is nice for humans to read. Because agents bang into those All. The. Time.

view this post on Zulip Peter Marreck (Oct 12 2026 at 00:58):

The "nice for humans to read" is also key. Otherwise we'd just ask agents to write straight-up WebAssemblyText and translate that to WASM. ;) I think humans will always need to be in the loop at some points.

view this post on Zulip Peter Marreck (Oct 12 2026 at 01:00):

And as I think I mentioned earlier, Opus 5.5 actually COMMENTED about my choice of Roc. That was unusual. It was like "so not only does this have nice error messages, is sensibly designed, is easy for myself or humans to read, is well-designed, results in fast and compact binaries, has the correct functional-language restrictions, no runtime errors etc... but it's fairly ideal if a future consists of humans essentially pair-programming with agents. And it's also right up your alley."

view this post on Zulip Peter Marreck (Oct 12 2026 at 01:02):

One more thought while I'm buzzed and ranty:
Human DNA is vibe-coded. Nature provides the restrictions. And there is already PLENTY of identified "slop". ;)

DNA is looooong overdue a "code review" ;)

view this post on Zulip Karakatiza (Oct 12 2026 at 01:04):

The way aminoacids are represented by the base pairs is "inefficient", lol - many combinations unused

view this post on Zulip Karakatiza (Oct 12 2026 at 01:04):

Side-note: I am waiting for an emergence of a vector based programming languages. As in, pure graph, representation is not human readable by default. Bringing programming as close as possible to digital cognition. Humans will have to catch up using tools that project this "source code" into text. There will be a non-zero amount of organizations that will prefer more effective work in that to the auditability of any human readable language.

view this post on Zulip Aurélien Geron (Oct 12 2026 at 01:07):

That's an interesting thought. The human brain seems to sit right at the edge between digital and analog, king of alternating between the two (binary action potental, but continuous timing, binary threshold, but continuous neurotransmitter concentration, etc.). Perhaps cognition works best near this edge since you can get the infinite expressivity and information density of continuous representations along with the reliability of digital representations. Perhaps a vector language would also live on this edge.

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:08):

Karakatiza said:

I am waiting for an emergence of a vector based programming languages. As in, pure graph, representation is not human readable by default.

this is basically every programming language after the compiler is done parsing :smile:

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:09):

I hear this a lot, and as a compiler author it makes me laugh every time because it basically reduces to "imagine if computers could operate directly on data structures that weren't human-readable!"

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:09):

we could call them "compilers" :wink:

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:09):

(and then adding a human-readable representation after the fact is just "write the parser later instead of at the beginning")

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:10):

or to say it another way: essentially every language is human-unreadable and graph-based after the parsing step

view this post on Zulip Aurélien Geron (Oct 12 2026 at 01:10):

I hear you, but I think we're talking about a different thing: vectors as in machine learning embeddings. It's not just that it's not human readable, it's also that it's a continuous representation.

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:11):

oh, but that's just a different parser

view this post on Zulip Karakatiza (Oct 12 2026 at 01:11):

I did not understand Aurelien, but he probably understood me :grinning_face_with_smiling_eyes:

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:11):

source text -> AST
vector embeddings -> AST

:shrug:

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:12):

either way we're talking about a tiny percentage of the compiler's work, so I just don't think there's much to be gained

view this post on Zulip Karakatiza (Oct 12 2026 at 01:12):

No, the point is AI would much more efficient at coding with that

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:12):

but that doesn't require a new language

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:13):

like you could write a vector embeddings -> Roc AST parser right now if you wanted to

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:13):

or -> Rust AST or anything else

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:13):

and then keep the rest of the compiler

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:14):

so if it's really a lot better, people are really missing out! I bet anyone working at frontier labs could get a proof-of-concept of "vector embddings -> AST of whatever language they use there" in a weekend

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:15):

(I am personally skeptical it would make any significant difference, for the record :smile: )

view this post on Zulip Karakatiza (Oct 12 2026 at 01:15):

We can skip the "new language" part :) The point is, AI will work on an opaque representation of a program, on its own schedule. LLMs are obviously are not designed to take advantage of that, but some other type of AI will (I am intentionally using a very generic term)

view this post on Zulip Karakatiza (Oct 12 2026 at 01:17):

Oh, and that representation would have to cover the model of the world, not just the program logic. AI would reason about the problem domain with this

view this post on Zulip Richard Feldman (Oct 12 2026 at 01:17):

ah that sounds much more different then! :thumbs_up:

view this post on Zulip Aurélien Geron (Oct 12 2026 at 01:22):

Here's what I meant by digital vs analog.
1) Compute 2 + 2 => digital. It's strict.
2) Detect cat on a picture => analog. There's a complex continuous space of cat pictures, the border is fuzzy.

Until recently programming languages were digital-only. Since neural nets came along, we can now express more "analog" things. But we're really distinguishing the two, and sort of patching them together. Perhaps there's a way for LLMs to use a vocabulary consisting only of vectors (e.g., 2048-dimensional embeddings) to express both.

view this post on Zulip Peter Marreck (Oct 12 2026 at 03:07):

@Richard Feldman I may have missed prior discussion on this, but your mention of AST made me think of macros and coder-accessible AST. At the risk of wayward discussion (apparently, gaming-related innovation is universal coder discussion catnip? LOL), Paul Graham perhaps famously said (more or less) that lisp and macros are what made his early career. I see that Roc has no macros, and that that was probably an intentional design decision done for simplicity reasons (which makes sense). That said, I was always appreciative of how macros were done in Elixir (sparingly, and somehow, the community has continued to make it sparingly) and also note that Elixir's UTF-8 parsing is generated on-the-fly direct from the (still evolving) UTF-8 spec largely through the liberal use of macros.
I don't know if this is a "nope, never gonna be in Roc" topic (because I wasn't present for those discussions), but just thought to submit those datapoints. Not requesting anything. ;)

view this post on Zulip Peter Marreck (Oct 12 2026 at 03:09):

I mean except for quote and unquote JUST KIDDING (i have been imbibing; frozen apple cider with whiskey should be a regulated substance)

view this post on Zulip Peter Marreck (Oct 12 2026 at 03:10):

@Aurélien Geron I think I get what you're saying and it's fascinating.
In addition to sitting on the boundary between the discrete and the continuous, the brain may sit on another boundary: that between the rational and irrational

view this post on Zulip Peter Marreck (Oct 12 2026 at 03:12):

discrete: "We have eliminated an entire class of bug with this language feature"
continuous: "The evolution of Roc syntax is more/less user-friendly, IMHO"

My favorite junction between these things is in naming things (yes, one of the hardest things in programming, and with good reason). UI is another one. "We made it possible for the user to do this" vs. "We made it trivial for the user to do this"

view this post on Zulip Luke Boswell (Oct 12 2026 at 04:11):

I think from memory the main issue with macros is that they make it difficult to provide really fast feedback.

You now need to execute arbitrary code before you can report errors etc. I suspect they could invalidate our caches for the type checked modules too.

view this post on Zulip Aurélien Geron (Oct 12 2026 at 04:32):

Several common use cases for macros are covered by compile-time evaluation: parsing/validating static string literals, precomputed lookup tables (e.g., CRC tables), compile-time string hashing, and a couple more.

We're mostly missing some automatic boilerplate derivation (like Rust's #[derive(...)]), some syntactic sugar, AST-level diagnostics & reflection (e.g., assert_eq!(a, b)). So far, the last one is the only one I've missed, but it's no longer needed now that the expect statement prints more diagnostics.

Macros also obfuscate the code, and mess with editors.


Last updated: Oct 15 2026 at 17:56 UTC