Ask this question in the 1940s and they would tell you it’s math. We are making machines that do math to kill Nazis. Now take this vacuum tube and plug it in over there and then go get me a cigarette.

Three words to solve this problem: direct mail marketing.

Just kidding, that just goes into my RL trash can.

It is like SQL injection. Probably worse. If you are using unsupervised data for context that ultimately generates executable code you will have this security problem. Duh.

Worse because there's really no equivalent to prepared statements.

Sure there is. A common way is to have the LLM generate things like {name} which will get substituted for the user's name instead of trying to get the LLM itself to generate the user's name.

Parameterized queries allow you to provide untrusted input to the database in a way that's guaranteed not to be interpreted as instructions.

There's nothing like that for LLMs.

That's what I explained. You are trying to do something with an untrusted name and the LLM will not treat the name as instructions because it doesn't see the actual name.

You mentioned having the LLM generate a placeholder, whereas the important thing is what it accepts. You can feed an LLM nothing but placeholders but that's very limited since it can't see the the actual data in any way. You're really just having it emit a template. Something simple like "make a calendar event for the reservation in this email" could not be done. In contrast, parameterized queries let the database actually operate on the data.

It may be limited but that doesn't mean it's not similar. For example MySQL can't check the weather when given city string as a paramertized query, but that doesn't mean MySQL doesn't have parameterized queries.

Querying external information is a different category of thing altogether.

The key thing (really, the only thing) about parameterized queries is that they allow you to provide code and data with a hard separation between the two.

LLMs don't have anything of the sort. They only take in one kind of thing. They don't even have a notion of code versus data that you could separate, or fail to separate. All you can do is either tolerate it sometimes taking instructions from the stuff you want treated as "data," or never give it anything you consider "data." You propose this second one. But never giving it "data" is very different from a feature that allows you to provide arbitrary data with total safety.

HeidiSQL is written with Lazarus/FPC.

It was kind or that way in early days of high end personal computing. I remember seeing an ad in the early 90s for a 486 laptop that was $6,000. Historically prices have always gone down. You just have to wait. SoTA is always going to go for a premium.

Yeah, the problem is if you don't understand the problem space then you are going to lean heavy on the LLM. And that can lead you astray. Which is why you still need people who are experts to validate solutions and provide feedback like Op.

My most productive experiences with LLMs is to have my design well thought out first, ask it to help me implement, and then help me debug my shitty design. :-)

I’m seriously thinking about getting a custom made bumper sticker with the following text: ‘; select 1/0;

DRY is more about support and maintenance than anything else.

I see a lot of attacks on DRY these days, and it boggles my mind. Maybe it is being conflated with over-engineering/paramterization/architecting. I don't know.

But I do know that having to fix the same bug twice in the same code base is not a good look.

It’s not that. It’s when you need to change how the function behaves but for only one of the callers.

Note to self: invest in a used book store ASAP.

I experimented with cc65 and wrote a simple game that ran on my actual C64 hardware. It was a lot of direct memory access, unrolling loops, and avoiding stack usage. A fun time overall, and it ultimately ran smoothly, but I see do why people who attempt anything serious on a C64 tend to focus on using ASM.