Sven Reinck wants dependency diagrams that nudge you toward clean architecture by looking wrong when the code is wrong. The instinct is sound, the history is unkind, and the difference between expressing complexity and measuring it is where the whole idea lives or dies.
Jordan Lord lays out three constraints he applies before building anything: a one-page description that survives without padding, a piece of core tech that can outlive the product, and a single defining constraint that shapes the user experience. Scope, leverage, and identity - one filter each. Great stuff.
MethodHandle has been in the JDK since Java 7, and most Java developers have a vague sense that it exists somewhere near invokedynamic and lambda internals. David Lloyd's ongoing series covers the mechanics thoroughly. What it doesn't cover is when you'd actually reach for it - and why.
Most teams don't trust their code - they trust the people who wrote it, or the streak of days without incident. That's not the same thing, and the difference is becoming harder to ignore. Trust in a system isn't social capital or accumulated momentum: it's demonstrated, repeatedly and verifiably, by the system itself. If you have to read the code to know it works, you don't know it works.
I chose 21 matches in nevet, the bot that accompanies bytecode.news, deliberately. It's a command, triggered with 21 matches, and it wants you to take between one and three matches every turn; the...