infinitebit

I feel this way about code. Writing things by hand is the quickest way for me to fully understand it, and that is what I am paid to do, to understand it. It will be executed millions and millions of times for every time it is modified, so even if writing it by hand is 10x or 100x as slow, it is still a better payoff.

> “why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?”

Because this is a myth. it is not true that there is zero cost to fix it. LLMs become less effective the more convoluted codebases become just like humans, if only at a different rate.

has the estate of arnold lobel been compensated for this?

THANK YOU. I’ve always felt this way about PR review. I feel like people should write a natural language description of the change, and every section of it should link to part of the diff, and every part of the diff should be linked to by part of the description. That or just leave a comment on every chunk of the diff.

The second recursion example introduces 2 syntax features without explaining them (let, square brackets)

Oh my god thank you. I have been trying to put into words what is so draining about pair programming with claude, and “doing creative work to impart meaning to the words” is exactly it.

this seems like more anthropomorphizing. even if it has similar results often enough to be useful, next token prediction is not searching a solution space.

you even end with a paragraph saying “it’s not too dissimilar from what we do”. how is that not anthropomorphizing?

and if what we do isn’t “thinking” then what is or ever has been?

I agree with the idea that the taste, for lack of a better word, was the only thing that ever mattered. What I disagree with is the idea that slop that is “good enough” is indistinguishable from something that is crafted is “indistinguishable by the market”. I think it is indistinguishable in the short term, but very distinguishable on a long enough time span. The same way that hacked together slop has always been “good enough” to close a ticket and even get someone a promotion, but later costs the company thousands of engineering hours to rewrite once it becomes completely unreliable, slow and impossible to modify. We’re just speed running that now. It’s the same battle engineers with “taste” have been fighting with sales teams and product managers and lazy teammates before LLMs, just in fast forward.

I started toying with perlin vector fields as a level design tool for a game idea, then became more interested in visualizing them than the game they were meant to support. this weekend i realized i think im making a (short) ~game in which you control a dust mote riding air currents, trying to gather enough water to fall back to earth as a raindrop

i love this. i don’t understand why web games like this aren’t more prevalent

Does anyone here know any mathematicians who can’t do long division or basic algebra?

Probably not, because they *don’t exist because learning basic math is necessary to learn higher level math*. Whether or not we have calculators to do basic math is irrelevant if you want to become a mathematician.

I’d argue that “whether or not the average dev will be writing any code by hand in 5 years” is irrelevant to whether or not one should learn to code *if they want to master designing and building complex software* using whatever method they will be using.

I’ve recently started using PBT at work and it has been more than worth it, and I want to try Model checking next.

“The second condition falls out of the first”. Hi claude!

i don’t think anything in the article advocates for not prioritizing “single source of truth”, as in, if we know that there are multiple sources of truth for something, it should absolutely be deduped. the article is more saying “be a bit more skeptical of any two pieces of code actually representing the same thing” and “be more willing to break apart an abstraction that is trying to represent multiple truths.”

I feel this deeply. Although abstraction isn’t a one way door, “deduplicating” logic tends to be much easier than breaking big functions back down, and so these days I tend to leave a comment with the date wondering if it is too similar to some other code. then if i come across it again months later and it still is, then maybe it is safe to make it DRY.

I think DRY is the first heuristic for “good code” that most junior devs actually grasp, and so they become very dogmatic about it for a while