He’s even got some yellow as a backup

Is there a perfect building?

Probably not, since they exist in an environment — which is constantly changing — and are used by people — whose needs are constantly changing.

The same is true of software. Yes, programs consist of math which has objective qualities. But in order to execute in the physical world, they have to make certain assumptions which can always be invalidated.

Consider fast inverse sqrt: maybe perfect, for the time, for specific uses, on specific hardware? Probably not perfect for today.

You can learn to do anything. You’ll have an easier time learning if you like doing it. So what do you like? Or: what would you want to try and see if you like?

Also: why do you want to make a game? What interests you about that?

Why link to falsehoods without context?

Oviraptor
Oiaptor
Overaptor

eye twitch

Judge the code, not the coder.

Oh no, they learned how to make short and quippy — but wrong — statements.

If you think running an open source project is primarily about managing code and not people, then I humbly suggest you pay closer attention the next time you engage with one.

Source: https://wiki.c2.com/?ClosuresAndObjectsAreEquivalent

(Sorry dude, my time was limited by how long I could spare poopin in-between meetings.)

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing - is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil - objects are merely a poor man’s closures.”

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object.” At that moment, Anton became enlightened.

Here’s the thing… code is much closer to doing group therapy than it is to flipping burgers. The final produced artifact is somewhat less important than converging on the tiny itty-bitty details of how to collaborate on the journey of getting there. This is especially true for open source projects.

Spending time trying to understand the perspective of a chatbot-managed contributor is a waste of time. You’re not going to be able to build a community around having a good developer experience for doing XYZ if half of the people weighing in on “how to do that” are not developers who are directly experiencing the thing they’re poking at.

Edit: Also, on testing specifically… this is something I see teams get wrong all the time. The real value of a test suite is not from making sure your system works correctly, but from making sure it’s easy to inspect how your system works. If it’s hard to write or modify tests, that’s an indication that you’ve got some unwieldy abstractions floating around. LLMs don’t care about whether the friction of test-writing is increasing.

Very big agree. This is actually one of the things that I love about TypeScript.

Because the compiler makes a strong guarantee that type info cannot modify runtime behavior, you’re free to manage the type layer and implementation layer independently to whatever extent you desire.

That means you can get granular and pedantic in the places where you see value in having the compiler enforce things, or get loose and permissive where that makes more sense.

It’s an approach that I really miss when I have to use languages that require your runtime behavior to comport with type system rules. I wish more type checkers had some kind of Ron Swanson escape hatch.

Except that code is generally made of… other code. And generally gets transformed from some kind of source form to some kind of deployment form. And then executed by some kind of runtime, made of code. On some kind of OS, made of code.

The level of abstraction at which you make paper by hand is pretty much constant. The level of abstraction at which you make even a “hello world” program by hand is extremely flexible.

Depending on your operating environment, even an incredibly complex and impressive task may just be a matter of passing the right flag to a CLI tool that you already use.

Being attentive to the manual experience of how a codebase “feels” is pretty important for making sure a system has a coherent (read: not over-engineered) approach to bridging the high and low levels of the tasks it performs.

Not paying attention to that, because you can delegate it to a chatbot, is kind of like forgoing having light switches in a room because you can just keep a crane parked outside and have it slam a lighting fixture through the ceiling when you need it and then dump a mound of dirt to cover the hole when you don’t need it.

Like, that functions and accomplishes the task in a pinch, but you do not want to try occupying that room in person at any point to do any kind of detail work.

In order to be effective at software engineering, you must be familiar with the problem space, and this requires thinking and wrestling with the problem. You can’t truly know the pain of using an API by just reading its documentation or implementation. You have to use it to experience it. The act of writing code, despite being slower, was a way for me to wrestle with the problem space, a way for me to find out that my initial ideas didn’t work, a way for thinking. Vibe coding interfered with that.

If you’re thinking without writing, you only think you’re thinking.

– Leslie Lamport

Yep. This what I don’t get about people who are using these spaghetti-bots. How do they figure out the right solution to a problem without actually walking around the whole perimeter of the problem?

My guess is they are not, and they’re just waiting until someone complains and they’ll get a job somewhere else and leave the mess for someone else(‘s chatbot) to clean up.

Between that and the death of open source, our industry is about to become a disaster area.

The “dark forest” internet is in full swing

I mourn it too, because there are dumbasses like this who are buying the hype and setting the industry back by decades as a result.

When the moon hits your knees
And you mispronounce trees
Sycamore

It’s massively impractical. You’re never gonna believe it.

These things require silicon (good luck finding sand!), but they’re mostly glass and aluminum (ridiculously rare substances that we can’t use willy-nilly on stuff that only lasts for 25 years, and then how are we gonna recycle that? we have no idea how to recycle glass and aluminum!), and then to make it scalable you’re gonna want some safe battery technology like sodium-ion (but where are we gonna find a bunch of salt on this blue planet?)

If hardware cost/availability is an issue, there are a few hardware simulators out there. Wokwi (ESP32 sim) is free for personal open-source use.

Breathless wanky AI hype

Just waiting for another xz utils situation

World 1: 40,000 people die a year from traffic accidents, but the driver is always a person. The courts may or may not find them liable, but the victims’ families at least have a name and face, and an explanation of events and motivations that they can rely on to find peace.

World 2: 4,000 people die a year from traffic accidents, but the driver is always an opaque ML model. Nobody is named, let alone found liable. And even if you had a name, there is nobody who can explain the reasoning of the model to you.

I am not sure World 2 is unquestionably preferable.

I think we’re missing something about justice when we only look at how many people die and not also how the survivors are able to make sense (or not) of their loss.