Programming Leftovers

posted by Roy Schestowitz on Apr 16, 2026

• Andrew Nesbitt ☛ Standing on the shoulders of Homebrew

  The bottleneck isn’t Rust or Ruby, it’s the absence of a stable declarative package schema. Until that exists, every fast client is fast because Homebrew already did the slow work.

• Alperen Keles ☛ On The Simplicity of Humanness

  The essence is, our laziness is the reason we engineer simple systems. LLMs lack this laziness, which results in the fact that they don't have the incentive or the process to simplify, given that we don't externally create such mechanisms. That is why Anthropic had to introduce a separate command (/simplify) to enable such post hoc simplification process.

  The thing that touches me the most about this idea is that I have been frequently amazed by the simplicity of human-engineered artifacts. All the algorithms I've ever read seemed simple, perhaps too simple in hindsight. All the codebases, even the gigantic ones, can be broken into simpler modules, sections, abstractions, hierarchies that allow us to understand the system. A great deal of modern advances in computing are due to simplification, malloc made memory allocation simpler, structured programming made control flow simpler, Rust made memory management simpler, typically via removal of our mental burdens.

• Chris ☛ Object Oriented Programming in Ada

  Ada is incredibly well designed. One way this shows is that it takes the big, monolithic features of other languages and breaks them down into their constituent parts, so we can choose which portions of those features we want. The example I often reach for to explain this is object-oriented programming.

• Zig ☛ 0.16.0 Release Notes

  This release features 8 months of work: changes from 244 different contributors, spread among 1183 commits.

  Perhaps most notably, this release debuts I/O as an Interface, but don't sleep on the Language Changes or enhancements to the Compiler, Build System, Linker, Fuzzer, and Toolchain which are also included in this release.

• Kavin Gnanapandithan ☛ Tracking down a 25% Regression on LLVM RISC-V

  As shown in the image below, LLVM requires about ~8% more cycles than GCC for that specific benchmark on the SiFive P550 CPU.

  I have included snippets of the relevant basic block assembly. Practically all the cycles were spent on the assembly below.

• Cal Paterson ☛ Dependency cooldowns turn you into a free-rider

  Frankly, dependency cooldowns work by free-riding on the pain and suffering of others. Fundamental in the dependency cooldown plan is the hope that other people - those who weren't smart enough to configure a cooldown - serve as unpaid, inadvertent beta testers for newly released packages. If there's a problem, those poor saps get hacked, everyone notices that they got hacked, and the problematic package/executable is yanked before the dependency cooldowners' thresholds are reached.

  Even if this worked for individuals - I think it's impossible to sustain it as a sensible or moral system for the entire ecosystem to observe.

• John Mikael Lindbakk ☛ Introducing Brunost: The Nynorsk Programming Language

  Many countries have multiple languages. Wales has English and Welsh. The Irish got Gaelic, and Cornwall in England has Cornish. In Norway, we technically have three languages: Bokmål, Nynorsk, and Sami.

  One can argue that we can technically speak Nynorsk as well, which is true, but there is no "pure" Nynorsk dialect. Nobody speaks "pure" Nynorsk, at least not unless going out of their way to do so. There are many dialects that come pretty close, but none are Nynorsk. This makes Nynorsk a purely written language, which I find fascinating.

  One can make similar arguments about Bokmål and Sami, but people speak Sami. And I would argue that a lot more people speak "pure Bokmål" than Nynorsk.

  Or maybe I'm just pulling this out of my ass, and I don't know what I'm talking about.

  The point is that I made a purely Nynorsk programming language: Brunost.

• Paul Tagliamonte: designing arf, an sdr iq encoding format 🐶

  🐶 Want to jump right to the draft? I'll be maintaining ARF going forward at

  /draft-tagliamonte-arf-00.txt.

• Sandor Dargo ☛ C++26: Structured bindings in conditions

  Structured bindings were introduced in C++17 as an alternative way of declaring variables. They allow you to decompose an object into a set of named variables, where the collection of those bindings conceptually represents the original object as a whole.

• Mitchell Hashimoto ☛ Simdutf Can Now Be Used Without libc++ or libc++abi

  Simdutf was the final remaining libc++ dependency in libghostty-vt2. After updating Ghostty to use this new simdutf build, we were able to remove libc++ and libc++abi completely from our dependencies.

• Erlang ☛ Erlang/OTP 29.0 Release Candidate 3 - Erlang/OTP

  Erlang/OTP 29.0-rc3 is the third and final release candidate before the OTP 29.0 release.

  The intention with this release is to get feedback from our users. All feedback is welcome, even if it is only to say that it works for you. [...]

• Buttondown LLC ☛ A sufficiently comprehensive spec is not (necessarily) code

  What I'm getting at here is that a specification is an abstraction of code. For every spec, there is a set of possible programs that satisfy that spec. The more comprehensive and precise the spec, the fewer programs in this set. If spec1 corresponds to a superset of spec2, we further say that spec2 refines spec1. A specification is sufficient if it does not need to be refined further: no matter what implementation (within reason) is provided, the specifier would be satisfied. A spec does not need to be fully comprehensive to be sufficient.

• Armanc Keser ☛ My PR has been waiting a year, or the exponential curve behind open source backlogs

  CPython has over 2,200 open PRs. At the 2022 Python Language Summit, a core developer presented on the backlog specifically and pointed out a chicken-and-egg problem: no active reviewer for a module means no reviews, which means no new reviewers get trained.

• Lawrence Tratt ☛ Retrofitting JIT Compilers into C Interpreters

  C interpreters are a common language implementation technique and the basis for the reference implementations of languages such as Lua, Ruby, and Python. Unfortunately, C interpreters are slow, especially compared to language implementations powered by JIT compilers. In this post I’m going to show that it is possible to take C interpreters and, by changing a tiny proportion of code, automatically turn them into JIT compiling VMs (Virtual Machines)1. This offers a point in the language performance design space that was previously out of reach: better performance while retaining full compatibility with reference implementations.

• Zach Mitchell ☛ I don't care that it's X times faster

  This also isn't to say that it's illegal to write the absolutely most optimal code. I just think that if this is your goal you need to come with receipts and be able to make your case. If your project was entirely vibe coded, benchmarks and all, you're going to get shredded. Not by me (probably, I tend to keep to myself on the internet), but other commenters are probably going to shit on you (for better or worse) if/when they find your claims lacking.

• Lewis Campbell ☛ Saying Goodbye to Agile

  RIP Agile, we hardly knew ye.

  And I mean that literally - because no one was ever clear on what it was.

• Ben Werdmuller ☛ One size fits none: let communities build for themselves

  Genuinely, there were gasps. I don’t think I’ve had a similar reaction at any talk I’ve given since. Years later, one of the attendees told me it was a mind-blowing moment: one of those sessions that immediately changes your perspective.

  I went on to explain.

  Instead of releasing a rigid social network out of the box, we recognized that for communities, one size didn’t fit all. Instead of giving everyone the same configuration, the same interface, and the same collection of tools, each community owner would easily compose their own combination of functionality and experience in order to best fit the community they served. By then, Elgg had been translated into 80 languages and there were a ton of plugins from across the ecosystem; there was a lot to configure a site with.

  The underlying point was that a social networking platform existed to support a real human community, and needed to be responsive to its needs. How could we, as platform developers, possibly know what every community needed? We couldn’t; we didn’t. It was better to put that power in the hands of people who did.

• Perl / Raku

  • Perl ☛ Making an Asynchronous Clocking Drum Machine App in Perl

    Let’s Make a Drum Machine application! Yeah! :D

    There are basically two important things to handle: A MIDI “clock” and a groove to play.

  • Perl ☛ Making an Asynchronous Clocking Drum Machine App in Perl

    A MIDI clock tells a MIDI device about the tempo. This can be handed to a drum machine or a sequencer. Each clock tick tells the device to advance a step of a measured interval. Usually this is very short, and is often 24 pulses per quarter-note (four quarter-notes to a measure of four beats).

    Here is code to do that, followed by an explanation of the parts: [...]

• R / R-Script

  • Rlang ☛ logrittr: A Verbose Pipe Operator for Logging dplyr Pipelines

    dplyr verbs are descriptive: let’s make them more verbose!

    Yet another pipe for R.

  • Rlang ☛ TheseusPlot 0.2.0: Visualizing Decomposition of Differences in Rate Metrics

    TheseusPlot is an R package that decomposes differences in rate metrics between two groups into contributions from individual subgroups and visualizes the results as a “Theseus Plot”.
    

  • Dirk Eddelbuettel ☛ Dirk Eddelbuettel: qlcal 0.1.1 on CRAN: Calendar Updates

    The nineteenth release of the qlcal package arrivied at CRAN just now, and has already been built for r2u. This version synchronises with QuantLib 1.42 released this week.

  • Dirk Eddelbuettel ☛ Dirk Eddelbuettel: anytime 0.3.13 on CRAN: Mostly Minor Bugfix

    A maintenance release 0.3.13 of the anytime sticking with the roughly yearly schedule we have now. Binaries for r2u have been built already. The package is fairly feature-complete, and code and functionality remain mature and stable.

  • Rlang ☛ Marathon Man II: how to pace a marathon

    Determining your optimal pace is complex. There’s the theoretical pace that you can achieve – a mix of biomechanics, physiology and training – but it can be very hard to know what this pace is. Anyway, this theoretical pace is what you could achieve when all goes well. You need to factor in the conditions on the day – how you slept, how you fuel, mental attitude, is it windy? can you get in a group and work with others? and so on. A runner may toe the line in the shape to run a sub 3 h marathon, but by the 30 km mark, the story may be very different.

    In the last post, we saw that positive splitting (otherwise known as slowing down) is inevitable. So it seems the best strategy is start out faster than your goal pace, bank some time so that you account for the fade.

• Shell/Bash/Zsh/Ksh

  • Jan Skriver Sørensen ☛ Homebrew breaking git tab completion in zsh

    GIT TAB COMPLETION in zsh suddenly stopped listing my aliases. No git ls, no git tags-ls – only built-in commands. Worse, commands beyond the most common ones lost their help descriptions entirely. git re would show rebase, reset, restore with nice descriptions, but git rep fell through to a bare list of names with no context. Something was clearly off.

  • Rachel Kaufman ☛ Do other people not like colors? or: adventures with ANSI codes and grep

    The folks working on this set of scripts didn’t notice, because they don’t use color when grepping. I came along as a user of the script and spent multiple days whining that “it didn’t work,” until I had a few minutes to dig into the code today.

    The easy fix is to put unset GREP_OPTIONS at the top of the script.

• Java/Golang

  • Paweł Grzybek ☛ Repository pattern in Go service

    When you start a new project, it feels nice that everything lives in a single main.go file. When things start to grow, you split things into multiple files. We will add tests later, right? Requirements change, someone joins the team, and in the meantime, you swapped SQLite for Postgres. In no time, your pedantically maintained project became an untangled mess of layers dependent on each other, with no clear separation of concerns, and previously neglected tests are close to impossible to implement at this point. Some good habits are worth picking up from the get-go, and in the world of Go services, the repository pattern is one of them.