ocrow

Seems like a coherent, sensible proposal, as one might expect from djb. Any notable protocols use them?

I've tried this approach of instructing the LLM to look for opportunities to abstract, but it's not good at finding the commonalities after the fact, when possibly related functions have already diverted unnecessarily. It writes "sloppy" code, that is to say code that is locally correct but which fails to build towards overall generalizations, but that sloppy code is a cul-de-sac: easy to write, but adding to messiness, and really tough to improve.

When a good programmer writes a new feature, they are looking for both existing and new abstractions that can be applied. They are considering their mental model of the whole system and examining whether it can be leveraged or needs to be updated. That's how they avoid compounding complications.

In order to take a big picture view like that, the LLM needs the right context. It would need to focus on what its system model is and decide when to update that system model. For now, just telling it what to write isn't enough to get good code. You have to tell it what to pay attention to.

To most effectively enable stalking applications

Yes! Curiosity is the way to open these doors. The first step is to keep a log of your thoughts. Anything that pops up, write it in your ideas book. Having ideas isn't an all or nothing. It's a practice. Get into the practice of writing down your small ideas and you will develop the ideas muscle.

I had a family member who had sudden onset of massive seizures. He could not remember any of his passwords or hints at all. It was a real challenge getting into any of his accounts to figure out what needed doing.

A lot of LLM/AI writing these days can feel lost in the weeds – the specifics of very detailed techniques are interesting undoubtedly, but writing that steps back and looks at the big picture, informed by those details, could be very useful for people who want to think about where this all may be going.

This is a good check on how good your help request is. Hopefully the problem statement includes a brief summary of the approaches already tried and why those were dismissed.

They can ask. We're the ones choosing to ignore his wish.

I think Alzheimer's is a particularly difficult case. Before diagnosis, many of us imagine that we wouldn't want to exist in a highly deteriorated state with no ability to care for ourselves. But as you start to decline, you still feel like yourself, just a very forgetful version of yourself. On which day do you decide that what remains of your mind isn't enough to make your available future days better than no future days?

The instinct for self preservation is strong. Knowing what will come requires foresight and clarity. You may lose the capacity for informed decision making before the point where it's clear that there's not much to live for.

Many of us lack the insight that Kahneman perhaps had that in order to take control of the end you may need to leave some good days on the table.

Mid X here. The name doesn't bother me. If it works that'd be fine. OTOH this doesn't solve a problem I have. I rigorously unsubscribe all promotional emails, and that seems to work fine.

To unpack that a little, he looks to the writings of the early developers of object oriented programming and identifies the ways this assumption became established. People like Bjarne Stroustrup (developer of C++) took on and promulgated the view that the inheritance hierarchy of classes in an object oriented system can be or should be a literal instantiation of the types of objects from the domain model (e.g. different types of shapes in a drawing program).

This is a mistake is because it puts the broad-scale modularization boundaries of a system in the wrong places and makes the system brittle and inflexible. A better approach is one where large scale system boundaries fall along computational capability lines, as exemplified by modern Entity Component Systems. Class hierarchies that rigidly encode domain categorizations don't make for flexible systems.

Some of the earliest writers on object encapsulation, e.g. Tony Hoare, Doug Ross, understood this, but later language creators and promoters missed some of the subtleties of their writings and left us with a poor version of object-oriented programming as the accepted default.

It's more specific than that. See sibling comment