_nalply

It's fine. I still program for fun. I switched to Pi as harness, and instructed the model to careful stop early such that I can stare at code, and I tend to give extremly substantive feedback sometimes. It was not easy, and now I hope I found something that clicked for me. I modified the bash tool to force the agent to tell me what he does, and it helps wonders, the agent says, he wants to do X and I can verify if the bash commands do what the agent says. I also use lightweight sandboxing. I am happy that no financial pressures influence my use of AI. What's still open for me is how to discuss it publicly, since there's a large group of programmers jumping at programmers who admit they use AI.

Thanks for your honesty. It explained some things I watched before retiring. I am one of those people who loved programming and hated what corporate settings made out of it. Yeah, it's one of the better paid things. It's hard work, and there are things that pull it in exactly opposite directions. Sometimes even for simple things like CRUD, when something is requested that would go sideways, you have the choice of rejecting it and avoiding thinking hard, or taking it by the horns. I told my wife, sometimes you just can't leave, and it's not only emergencies. Because if you are in a deep session and you stop, you lose your own context. But it's very satisfying if you can wrap it up in a way that leaving notes for yourself for later suffices. But this style of work is not for everyone. And in corporate settings weird things happen, and sometimes I just felt shat on. But hell, it's paid well, right?

Okay, now that that is out, let me ask politely: in what way do you avoid acting as a meat proxy for AI?

EDIT: re reject, you can do that while acting as accepting it, by saying something like, yeah, let's do that but before starting, we will look at the problem, it's a game of shifting responsiblity to other people. For me that was a corporate game that has nothing to do with programming.

They have. Look in your account, it's in usage. If your usage exceeds what you have paid you will get told.

This said, it's a good offer. You can switch between many models quickly. They are rated by quality, speed and price, and it's shown with orange dollar symbols for price and bullets for speed and quality. Example:

    Anthropic Claude Opus 5.5

    Anthropic's flagship model with always-on adaptive
    thinking ($$$$$). Best for deep reasoning, agentic
    coding, and long-horizon work.

    Cost    $$$$$
    Quality ●●●●●
    Speed   ●●

There were several waves of Russians fleeing [0]

[0]: https://en.wikipedia.org/wiki/Russian_emigration_during_the_...

(This is incomplete, I think there is a fourth or a fifth wave, probably since about summer 2026.)

Some projects have their own jargon. Two terms I ran into recently are "surface" and "oracle." I'm a greybeard programmer who started in 1983, and both were new to me. I grasped them immediately once I asked my favorite florid model what they meant.

A surface is whatever the user interacts with: a GUI, a TUI, an API, or anything else. I once exposed some functions of a web app on the window object. Boom, a surface for working in DevTools.

An oracle is a simple, independent way to compute a result. It may be limited, but it's still useful for testing, because you can check the real implementation against it.

I understand that programmers like me may dismiss all this as hot air. But it's just jargon.

And "predictive surface"?

It's a surface that anticipates what you'll want next and shows it before you ask. For Spinal, this might be simple. Say you query for all functions whose names start with x, that take an int32_t argument, and that return void. The result list doesn't just give you names; it also shows, visually, how often each function was edited, how long it is, and how complex it is. In other words, it displays information eagerly.

Disclaimer: I'm not affiliated with Spinal. I'm only guessing from the demo on their site.

It's the typestate pattern. The compiler enforces valid state transitions and so you can't just pass to the same function. It's useful to ensure that only some transitions are allowed. To be honest, the connection state presented by GP is a bad example. But you shouldn't say "it defeats the point".

A better example is an HTTP writer. One state is `Headers` with the methods `add_header()` and `body()` which returns the response in state `Body`. This enforces that one can't add headers after `body()` has been called. But you can finish the response in the `Body` state. If you do something not in this order, you get a compile error.

I got a car whose cruise control state was never displayed (the mechanic used the wrong dashboard), but since it worked anyway, I accepted it. So that's a data point (me) that modal buttons do work.

But "should not depend in the GUI to keep up" is wrong, I think. It needs at least one LED per mode. Because sometimes it's a bit annoying. Rarely cruise control doesn't engage or turns off by itself or something caused the cruise control mode diverge from what I have in mind, and a quick glance would help to resync.

I think the possiblities that a minority can leave the group is an important escape valve for them. Now assume that in the future they are going to be not such a minority anymore like today, then what happens? Maybe some oscillation like for Lotka-Volterra situation, perhaps a bit different?

I found grandparent's post still useful because it caused something to click in my head. I then researched and found that threads and processes share a lot of functionality. In the kernel both processes and threads are represented by `task_struct` instances.

So, respectfully, you shouldn't dismiss grandparent with "This isn't really true".

Lipreading Deaf here.

I tried to lipread the Inauguration, and where it was successful I did read the same nonsense, but often it wasn't possible because they weren't looking at the camera or the microphone was in the way.

The Seagulls, however, the only thing I could read was amm-amm-ammmmm-am-am-aaaammm. Nothing else. Of course, the doll has very simple mouth mechanics.

I am Deaf. I lipread German, but rarely lipread English and was successful with lipreading people speaking English as not their native language, namely Greek, Estonian and Marathi but never from the Anglophone world. Turning older, my lipreading competence declines, and I prefer talking in my local Signed Language.

What this article is missing, I think, is that lipreading is not replacing auditory input with visual input because there are too many, let's just call them homophones. I find the word "visemes" a bit too cute. You need a lot of context. So I always struggle if someone asks me a very short question, because I don't know what it's about. Someone comes to me, says hello, and asks the question, and I don't have an idea what they want to know.

Re gameplays, the context is special, because you can assume that the football coach is not shouting "HAKUNA MATATA" over the field. This simplifies lipreading during gameplays. Essentially it devolves into something like a set of radio buttons.

How do you manage zone 5 cardio 4x a week without PEM?

I thought up to 3x a week and never consecutive days is the maximum.

Have some air at the top of the top reservoir, assuming that the top reservoir is at most about 10 m deep in water (to avoid damage from storms). Or have the air in separate chambers fixed to the top reservoir.

Ah, so you meant UB = unspecified behavior, not UB = undefined behavior.

Maybe. Bugs that come from spooky behavior at a distance are notoriously hard to debug, especially in production, and it's worthwile to pay for it to avoid that.

It's WASM. WASM runs in a sandbox and you can't have UB on the hardware level. Imagine someone exploiting the behavior of some browser when UB is triggered. Except that the programmer is not having nasal demons [1] but some poor user, like a mom of four children in Abraska running a website on her cell phone.

[1]: http://catb.org/jargon/html/N/nasal-demons.html

I thought so, but "Copyright" is always the same? Haha, that's dangerously clever or cleverly dangerous.

That's Henry George.

I don't understand all consequences yet, except one, that the wealthy and powerful object to it because it hurts them and so the Land Value Tax is rarely introduced. Even if it gets introduced, it will abolished soon thereafter.

AI is one sharp tool cutting slices from the old internet. But perpetrators have used different tools from the start: SEO spam, algorithmic feeds, embrace/extend/extinguish, building moats, the attention economy, and many others. AI is just the next newfangled sharp tool.

In other words, I don't think that AI is killing the web.

It's being profit-oriented and running amok in an unleashed way. It's prisoner's dilemma. You know, if you don't do it then someone else will do it and you lose. Enshittification is one consequence. The internet experienced it from the beginning. But only about fifteen years ago companies learnt how to squeeze the last drop out and, like in the tragedy of the commons, everybody is worse off.

And what's the most catastrophic? People are confused. They look at the tools but not at some famous people behind these rampages. Of course as leaders they just optimize the hell out of the internet with the target that their companies thrive. But in doing so they cause heavy damage.

Maybe. Maybe not. Given the human material (yes I know a dehumanizing formulation, but that's what Corporate does) it seems it's better not to step on anybody's toes except if it's abundantly clear that the person doesn't have a voice in things, but even then it's risky. Corporate is self-selecting: companies that don't generate profit die off sooner or later. Therefore we can conclude (if a bit shakily) from the norm in Corporate not to insult anybody that internal strife has been very damaging and therefore that Corporate self-selects in an evolutionary manner to avoid anything that leads to internal strife.

Or add spirits.

Another way: Let ferment it to the max. If fermentation doesn't consume all the sugar, then it's somewhat stable.

Ancient wines also had resins added. Today these would probably have tasted almost medicinal, but often they are diluted before serving. Wine dilution is still a custom in some parts of Italy. I was invited to a party in Tuscany and they served a lot of Lambrusco amabile and for the children they diluted it and because Lambrusco amabile is rather sweet it was a little bit an oldfashioned soft drink. I tried it, too, and it's refreshing. I don't know whether it's sacrilegous but as one says, in Rome do as Romans do.

It's a font that morphes the text fragment "am-" into the curly dash using a ligature.

https://chriscoyier.net/2025/05/10/the-am-dash/

But that won't help for long. If the Amdash becomes popular, then AI will pick it up, because "am-" is just a text fragment and AI can learn to produce it.

Even worse if a future version of Unicode adopts the Amdash, then nothing will stop AI.

Or the opposite happens as one already said here: Nobody will use the Amdash.

Yes because "pics or it didn't happen"

Autism is seen as a large and wide spectrum of many different symptoms all called "autism". Using terms like "high functioning autism" is probably not a helpful way to talk about some color on the spectrum, however.

Source: I am the parent of a child with autism.

Perhaps unsigned could help here with understanding.

unsigned means, don't use of an integer MSB as sign bit. __nonstring means, the byte array might not be terminated with a NUL byte.

So what happens if you use integers instead of byte arrays? I mean cast away unsigned or add unsigned. Of course these two areas are different, but one could try to design such features that they behave in similar ways where it makes sense.

I am unsure but it seems, if you cast to a different type you lose the conditions of the previous type. And "should this be legal", you can cast away a lot of things and it's legal. That's C.

But whatever because it's not implemented. This all is hypothetical. I understand GCC that they took the easier way. Type strictness is not C's forte.

True.

This would be only useful in typedefs. An API could declare some byte arrays not strings. But again, whatever.

I do understand.

I imagine that it could work a little bit like unsigned: a modifier to integer types that tells that an integer's MSB is not to be used as a sign bit.

__nonstring__ tells that the last byte of a byte sequence doesn't need to be NUL.

I would find it sensible allowing putting the attribute to a type, but whatever.

That's a simplification.

AFAIC an Armenian scientist integrated Sci-Hub with Libgen, perhaps the one you meant. But the story is a lot more complicated. It's not wrong to say that Libgen is something that Russia did for the world.

Edit: I meant Russia-not-the-state.

Perhaps. I read about horror stories of servers chasing leaving customers and harrassing them for not tipping or too little.

But of course GP was deliciously ironic, so take all with a grain of salt and a dash of black humor.

The thing is, you sound hopeful, which I think you should find worrying by itself.

To be explicit: You feel the chilling effect.

Wikipedia (https://en.wikipedia.org/wiki/Chilling_effect) says:

> [...] a chilling effect is the inhibition or discouragement of the legitimate exercise of natural and legal rights by the threat of legal sanction. A chilling effect may be caused by legal actions such as the passing of a law, the decision of a court, or the threat of a lawsuit; any legal action that would cause people to hesitate to exercise a legitimate right (freedom of speech or otherwise) for fear of legal repercussions.

In other words:

A chilling effect is when people are scared to use their rights because they fear legal trouble. This can happen because of new laws, court rulings, or threats of lawsuits. It makes people hesitate to do something they’re normally allowed to do.

You are wondering whether to go abroad. BOOM.

> In the long run the invisible hand will dole out rewards and punishments

Only in competitive markets.