I don't think that's what they said. They said they could remove AI from the workflow without much disruption.

My father-in-law has (among other things) done a fair amount of editing or proofreading prose, mostly on paper with red and blue pens. He says that when the page looks like it's covered in blood, that means it was good writing. For bad writing, it's so bad that you can't really work with it.

I would not want to take a block of text written by AI and try to edit it to sound human. It's too hard to fix. (And I suspect this is why people don't - they just paste the AI output.)

I think the same may be true of AI code. You're not going to fix it. You can't edit it to be the code you would write. All you can do is re-prompt to try to get the AI to fix it.

Perhaps so, but it was a really nice time.

The Iron Curtain had fallen; there was hope for Russia to become a democracy, and the weight of living in fear of dying in a nuclear war was lifted. China was becoming, perhaps not democratic, but at least economically liberal.

The economy was doing reasonably well for most people - it wasn't the high inflation of the eighties, and 2008 was not yet on the horizon. It wasn't yet the two-level economy that it became - if you were lower class, there was still a plausible route to the middle class.

AIDS was becoming manageable rather than a death sentence. Climate change wasn't really on people's radar as a real worry yet - there wasn't a sense of doom about it.

There was still hope that technology would free and empower us rather than enslave us.

And no, I wasn't a teenager or in my early twenties. Though I did have a pretty sweet life then...

> The Iron Curtain had fallen; there was hope for Russia to become a democracy, and the weight of living in fear of dying in a nuclear war was lifted.

seems like you are confusing early 00s with early 90s

For the international stuff, that's possible. Still... Russia wasn't an adversary yet, even in the early 00s. Neither was China. Nobody was building bomb shelters and doomsday retreat bunkers.

the bunkers were due to "gub'mnt gonn get us" in the wake of ruby ridge and waco

weirdos and nutjobs running their cults. not hyper-rich, deepy engaged technical types.

But this is one of the classic blunders! "Things are going wrong, so we have to do something! This is something, so we have to do it!"

Well, no, we have to do something that will help. Doing something that makes things worse isn't the answer, and the worse things are, the less we can afford to do so.

"This might help, but also might really mess things up" is not the answer - not in politics, not in economics, and not in climate change.

But I agree with one part of your post. Persuading nations to become poorer voluntarily is not a viable strategy.

Because you cherry-picked 1985. It went below 160:1 in 1986 and hasn't been back since, until now. So it's the weakest it's been in literally 40 years; that's at least potentially a big deal.

Just buy the bottom and sell the top. Are they stupid?

I think there's a difference between general AIs and AIs specifically trained on attacking. General AIs probably can't do those things.

I don't think that difference applies to anything in my comment at all. At no point did I imply that general-use AI could do those things - my point was that general-use AI cannot even do the things its designed for without strict human guidance.

Right, but only a small fraction of the agents used the board.

If you put agents (AI or human) in impossible situations, they do some pretty insane things - things that definitely are not what you were trying to get them to do. And that's your[1] fault for putting them in the impossible situation.

[1] "Your" meaning the one putting them in the impossible situation, not you, the reader.

With cybersecurity, it might be "defense dominant" in the sense that we can eventually patch all of our systems to be robust to hacking from even the strongest AI agents. Although it may get worse before it gets better. In a defense dominant world, widespread access to powerful AI could be fine.

However, other areas of risk such as biosecurity may be "offense dominant". For example, we cannot exactly patch the human immune system to defend against artificial viruses the same way that we can patch computer systems.

> My guess is that your ASM is inflected by structured programming everywhere.

I think you're probably right. To expand on this:

In asm, you can have things that are clearly functions. You have a stack discipline going in and out of them. They end with stack cleanup, then a RET or some such, which pops the return address off of the stack and jumps to it. Within that function, you have JMP instructions (or whatever) that move around within the function. You may also call other functions, by pushing variables on the stack, and then calling JSR or whatever to push the program counter on the stack and jump, and when those functions return, you'll be right where you were in this function. That's all sane, and it's "structured assembly".

Non-structured assembly would be like the example in your second paragraph. You're in one function, and you JMP (not JSR) into the interior of a second function. Or, you simply don't have functions, just labels that you jump around do. That's not structured, and not sane.

I have no idea what the parent meant by, "My guess is that your ASM is inflected by structured programming everywhere."

(I am the GP)

Your response was far better than mine. If those instructions were executed more than a couple of times and the constraints/assertions were identical, I'd absolutely throw them in a function. I'll handle what I need to before/after the function.

I would never branch to some coincidental label. That is why I love ASM so much. If you are sloppy or lazy, you will most likely be punished severely for those choices.

(Tangential, but when I first learned ASM in college, I felt like I learned more in that one semester than all the sum of all classes in my entire degree.)

By "inflected by..." I'm suggesting that Structured Programming has altered how you write assembler even though of course assembler doesn't inherently provide that structure.

When you need to do X here and there, you write code to X and then you call it where it was useful - you don't have code in one function just jump to a label in a completely different function because, in this era where structured programming is taken for granted - that seems crazy. And it is, but only the same way that chattel slavery seems crazy today, in the Antebellum South it was just usual and likewise in 1950s computer software just jumping into unrelated code was normal.

One of the principles of structured programming is that you organize your code into functions, and that they have single points of entry, and single points of exit. We still have a lot of multiple points of exit in functions these days, but the reasons for them usually fall into either those of clarity (less nesting/branching) or performance by skipping unnecessary work, and the consequences of them are less dire in modern high level languages because such languages have GC (no fear of skipping a memory cleanup step) and features like try..finally to ensure code closing file handlers or logging or whatever is executed at the end. But we have largely eliminated multiple points of entry from most code. The main remnant I can think of is in the form of coroutines, though they are structured and limited enough (like modern gotos) and have well defined lifecycles that it's more forgivable.