Programming: Weekly Summary (November 10-16, 2025)

I would describe this week in programming blogs as a messy drawer that somehow still has your good scissors. There is a jumble of practical tricks, big ideas, tools fights, and a few quiet, nerdy joys. To me, it feels like walking through a flea market: you find a rare book on syntax next to a dusty Commodore BASIC manual, and right behind it someone is hawking a neat little trick for coalescing notifications. Strange mix, but interesting.

Small philosophies and the duck versus koala question

There was a neat, short piece that keeps sticking in my head, by Jos Visser, asking whether you are a duck or a koala. I dithered over it for longer than I should have. I would describe them as archetypes of skill and curiosity. Ducks do many things, paddling along the surface, visible and versatile. Koalas curl up on one tree and master chewing eucalyptus. The piece is small, but it nudges at something that kept popping up all week: how we choose to farm our attention in code and tools.

If you are the duck, you will like the posts that skim across many small wins. If you are the koala, you will love the deep dives about parsers, type inference, and transaction thinking. Both approaches showed up, and both felt useful in their own awkward, human way. I keep thinking about it when I flick between a tiny Go iterator and a 30 page rant about syntax.

Tools wars and editor tantrums

There was a streak of editor and tooling grief this week. Jack Baty unfriended Emacs for a while and flirted with NeoVim. He writes like someone packing a suitcase in a hurry, tossing out the bulky bits of an Emacs config and being surprised at how light the bag feels. Nearby, Alex Kladov had a thoughtful riff about read only characters in Emacs and the missed chances in VS Code. That one read like a letter to someone who uses editors as musical instruments. It reminded me of arguing football tactics in a pub: people are passionate, and no two setups are exactly right for anyone else.

Then there was the small, practical treasure by Michael J. Tsai about tracking Apple developer release notes in a Git repo. He is quietly furious at Xcode release notes that say nothing and praises a commenter who turned the foggy notes into organized markdown. It is the kind of thing that makes engineers grunt in satisfaction. Like finding a neat little shelf to put your spices on — suddenly your kitchen looks usable.

And the linting love from Filip Hráček about LINT.IfChange. He highlights a tiny Google tool that nags you when one file changes and the paired file does not. Simple, but oddly powerful. It felt like someone inventing a polite neighbour who taps your shoulder when you leave the bin out. Small automation, big peace of mind.

Patterns, primitives, and design you can hold

Several posts were about patterns you can actually drop into a codebase. Sherman On Software wrote about incremental ETL for SaaS developers. It is practical. The emphasis was on state, idempotency, and deterministic steps. If you have ever stitched together a nightly job and come back to a half completed run, you will know why this matters. The post reads like a carpenter explaining how to keep a jig square so the tenons line up later.

Anton Gubarenko had a little UI pattern in SwiftUI, the Discardable Slider. The idea is plain: let users tweak a control, but do not commit those changes until they hit Save. Makes sense, but the subtleties around floating point comparison and avoiding spurious updates are the bits that would bite you in production. I liked that one because it is the sort of UX detail you forget until it bites, and then you waste a whole week chasing it.

A different kind of pattern showed up in Burning the Midnight Coffee | Sir Whinesalot with Transaction Oriented Programming. It is a bigger idea, turning user relevant units of work into transactions with ACID-ish properties. I’d say it reads like a manifesto for making commands behave like promise keeping citizens. Some bits feel familiar; many shells and tools have been transactional in small ways for years. But framing it like this opens a few windows. It makes you look at a cp or a mv in a new light, like they should behave more like bank transfers.

There is also a lovely practical blast from the past: Chris Garrett explains modulo on the C64. You would think modulo is basic, but on BASIC V2 it is a missing toy in the box. The post is a perfect little tutorial — like a grandma showing you how to roll pastry by hand because the cheap mixer broke. Charming and useful for anyone banging on old hardware.

Lest we forget the tiny tricks that amuse, Evan Hahn did Fizz Buzz without conditionals or booleans. It is playful, decorative, and a reminder that constraints breed weird creativity. There are limits to the trick, sure; it starts misbehaving if you stretch it too far. But it is fun to read and try to re-implement in tea breaks.

Iteration, error handling, and the smell of loops

A pair of posts from Jonathan Hall about implementing range-over-func iterators and handling errors during iteration in Go felt like a micro-series you could put on a syllabus. The first explains yield-style iteration using a scanner and callback yields. The second introduces the iter.Seq2 pattern and tries to design natural error handling for streaming matches. It is pleasant to see someone wrestle with the awkwardness of iteration and errors. He points out, correctly, that errors during streaming are awkward to report without making the consumer do double duty. He also admits the pattern can look redundant and ambiguous. Honest, pragmatic, and useful for people doing text processing or building pipelines.

Speaking of parsers and recovery, thunderseethe wrote two pieces that felt related in spirit. One is about pushing past the first error in type inference, and the other is a longer treatise called Reproachfully Presenting Resilient Recursive Descent Parsing. Both are for people who like the smell of AST dust. They argue for resilience in tools that interact with humans: not aborting at the first mistake, keeping a hole in the AST where someone typed garbage, and reporting multiple errors. The parsing piece is full of design choices and a reasonable scepticism of one-size-fits-all tutorials. Read it if you have ever typed code with red squiggles and wished the compiler could be more forgiving, or at least more useful when it is not.

Syntax, diagrams, and the shape of code

There was a recurring theme that syntax is not the be all. Paul Tarvydas made two posts that push hard on this point. One was titled Syntax Is Cheap. Paradigms Matter, and the other argued for diagrammatic syntax. The short version is: syntax is negotiable, but the paradigm you map onto matters more. Paul is arguing you should pick sensible representations for the problem. Diagrams for asynchronous flows, text for local transformations. That matches a tiny project I saw last month where someone drew an event flow and three bugs disappeared overnight. Diagrams are not fanciful, they are a different kind of syntax.

Innes wrote about structural regular expressions, an idea from Rob Pike. It sits in the same neighborhood as Paul’s diagram idea. Structural regexes let you reason about chunks of text rather than raw characters, and the examples—like picking out job titles from messy lists—were neat. It feels like the sort of tool that flips a problem from annoying to ordinary.

And then Paul Tarvydas again, with that slightly pugnacious tone. I’d say he is the person waving at the syntax police and suggesting better maps for the terrain. These posts made me want to pick a whiteboard and draw boxes until my tea goes cold.

Languages revisited and the comfort of old friends

There was a soft, affectionate theme running under a few posts. Ruben Schade wrote about Eskild Hustvedt rediscovering Perl. The tone is almost familial: old languages can be useful, nimble, and comforting. It reads like bumping into an old mate at the market who still does leatherwork. There was also a joyful hardware nostalgia in Matt Greer building a Pixel Pup e-Reader game that runs on GBA cards. Lovely detail about how the main game and puzzle packs talk to each other. These are reminders that programming is not always about the newest shiny thing. Sometimes you want to scratch an itch and make a small, clever object.

Types, inference, and SMT curiosity

On the more formal end, Philip Zucker wrote about doing E unification using SMT solvers. It is nerdy in the best sense. If you like thinking about substitutions, candidate generation, and boolean propagation, this is your jam. The post navigates the complexity without pretending it is fluffy. It hints at applications in theorem proving and smart constraint solving.

Pair that with the type inference work by thunderseethe and you see a thread: folks are trying to make compilers and analysis tools that tolerate humans and crazy inputs. They want systems that give good hints, not cryptic cliff notes. I found that humane stance refreshing. It is like teaching someone to ride a bike with training wheels that can be removed one day. The training wheels matter.

Concurrency, containers, and naughty locking tricks

If you like low level muck, Simon Willison had a cheeky post on using POSIX advisory locks as a side channel for cross container communication. It is one of those clever proofs of concept that is half neat trick, half mischievous. He walks through how a process can set a read-lock and another container can detect it. Useful? Maybe. Amusing? Definitely. It feels like finding a secret knock that only your Docker containers understand.

On a slightly more conservative note, Michael J. Tsai had another post about NotificationQueue and using custom dispatch source coalescing with GCD. He argues that GCD can do the heavy lifting for coalescing and gives code examples. Practical, dry, and exactly what you reach for when events start flooding your app like a rainstorm in November.

Patterns in languages and runtimes

There were a few nitty gritty language posts worth noting. Арсеній explained how Go interfaces do their quiet magic, with empty interface, method tables, and dispatch. It is the kind of internals post you read when you are curious how the sausage is made. Bart Wullems wrote about C 12 collection expressions and how to make custom collections work with the new syntax using CollectionBuilderAttribute. Small language ergonomics like this tend to spread quietly.

And then Steven Giesel described xUnit.v3 console capture changes, an example of small but impactful API changes. It is not exciting in the headline sense, but if you write tests, knowing your test harnesses changed is the sort of detail that saves headaches.

AI, maintenance, and the risk of instant legacy code

A loud note this week came from Henrik Jernevad warning about using AI to generate instant legacy code. I’d say he is waving a cautionary flag. The point is this: AI can accelerate output, but if you stop understanding what it writes, you end up with code nobody owns. The metaphor he uses stuck with me: it is like getting a caterpillar that turns into a moth and flies away leaving a shed skin. If you do not keep control, maintenance becomes a guessing game.

That theme echoed in other pieces, indirectly. Small automation stories, like LINT.IfChange, or the Apple release notes project, show the healthy end of tooling: things that help humans stay in sync. The scary end, AI that writes code you no longer grok, is where the instant legacy lives. If you rely on agents, do the homework. Read the output, understand the choices, and treat the model as a power tool, not an apprentice who can be left unsupervised.

A few odd little pleasures and bookmarks

Angelo Pesce posted a bookmarks column with links to multilingual models, video stabilization, the demo scene, and a curious mix of retrocomputing and machine learning. It is the kind of page you save and come back to when you want a random fifteen minute detour. The weeknotes from Denis Defreyne had a human touch: a small tale about Zig memory allocator puzzlement and a side note about wanting a vernier caliper. You get the mix of tooling, games, and life. It is a reminder programming is not only code; it is kits, hobbies, and the odd collection of measuring tools.

There were also pieces that felt useful in the everyday. Bart Wullems on how to unlock collection expressions in C# 12 for your own types is a good how-to for making code nicer. Philip Zucker on E unification felt like advanced seasoning for people already cooking with SMT. Jonathan Hall on iterators is a useful note you can slap into a code review comment.

Agree, disagree, and the little fights

A few quiet disagreements peeked through. Some authors want syntax to be elastic and cheap, others want more rigid transaction semantics. The tension is not hostile, it is like different people arguing about the fastest route home. Paul Tarvydas pushes for changing the map, while Burning the Midnight Coffee | Sir Whinesalot asks for sturdier transactional guarantees. Both are right in their own lanes.

There is also a cultural friction between the old guard that rejoices in Perl and the new guard cherishing fancy type systems. But that is a gentle disagreement. People are nostalgic without being blind; they admit new languages have their charms. It is like arguing whether hand stitched shoes or modern trainers are better. Different uses.

Things worth clicking through

If you click just a few links this week, try these in no special order:

• thunderseethe on resilient parsing and pushing past the first type inference error if you like compiler internals. The parsing essay is long and opinionated, which is exactly the right thing for such a topic.
• Sherman On Software on incremental ETL if you are doing SaaS data engineering. It is a useful checklist that will save you a production headache.
• Henrik Jernevad on AI produced instant legacy code if you are handing code writing to models and wondering whether someone will fix it later.
• Simon Willison if you like weird hacks that teach you about the underlying system. That POSIX lock trick is a great brain snack.
• Matt Greer for the Pixel Pup e-Reader project if you want something deliciously retro and concrete.

These are small suggestions, not a map you must follow. Click around. It feels like a weekend of poking under the hood.

I would say the week had a comfortable balance. There were tool griping posts and also small, useful recipes. Big ideas rubbed shoulders with tiny tricks. The recurring motif was human centredness: people want tools that remind you they belong to humans, not the other way round. Whether that means better error recovery in compilers, tiny helper scripts that keep files in sync, or taking a closer look at AI generated output, the tone this week leaned towards careful craft rather than theatrical reinvention.

If one thought threads through the noise it is this: keep control of the things that matter, and be playful with the rest. Keep a small set of rules that save you time and grief. Use diagrams when textual syntax hides intent. Use transactions when you need consistency. Use idempotent steps in ETL. And for the love of all that is oddly useful, keep a stash of retro tricks for rainy Sundays.

There is more beneath every link. If any of these snippets twitch your curiosity, go read the full posts. They are not long novels, mostly practical, some whispered manifestos, and a couple of mischievous hacks. It is the kind of reading that makes you want to change one thing in your workflow and then sit back and watch whether it helps.