I agree, yes. But it's a bit like saying the only way to not die in a car crash is to not drive. If we're in a situation where using LLMs is unavoidable, I would rather make them safer.

> Well there’s your first problem. A line in the prompt is not a safeguard. Even if you could trust the model - and you cannot - there is always the issue of prompt injection. A proper safeguard means actual sandboxing.

You're right. I did not completely sandbox it and air gapped it. But I also wented it to do some actual work.

If I completely sandbox it, but still leave it the ability to compile stuff, it's just going to build it's own (bad) version of the tool. That's obviously not what I want either.

The obvious thing to me would be for the LLM to notice it's limitations, reason through why they might exist and explain to the user that it cannot do it's job without such and such.

But that brings us to my original comment that these things are over-optimized on completing the task by any means necessary.

For instance, I was playing around with Claude a few days ago and it decided that it was missing a tool and it was going to get it one way or another.

First, it tried apt. No sudo, so no install that way. Tried installing via mise, but it didn't have the permissions. Then moved on to grabbing the source from github and building it.

Should I have included a "DO NOT UNDER ANY CIRCUMSTANCES INSTALL ANY TOOLS"? I mean, I had to after that. But how many other things am I missing? And at what point do the safeguards become so long they get consumed by compaction, or just ignored by the model?

I doubt Google is distributing the Android code to third party OEMs that way.

It feels like the models have been very optimized at getting shit done. But not so much at figuring out what the limits should be.

That is still dangerous and it shows that the models ARE misaligned with what their users are wanting/asking them to do.

Judging by public statements, Google is one of the 3 big western AI companies. Surely they should be rolling in cash and working hard towards AGI.

And yet, for whatever reason, they can't help themselves from further restricting user freedoms on Android. Why?

I don't want to be conspiratorial, but surely it's not money, right? It has to be control. Someone high up at Google just seems to resent people having control over their own devices.

Seriously, you can run the windows version of GTA V on a phone. It runs pretty ok as well.

Programmers look at data and see opportunities for running a pipeline of transformations (map/filter/...). And they tend to write their SQL like this as well. Or use something like Linq or one of the various pipe syntax SQL extensions.

I would say that this is a major reason why there is this sentiment of "SQL is yucky" by developers. The mental models just don't match.

Now, I don't think this is necessarily a Madoff situation, or even a dotcom one. Ed Zitron is certainly not Markopolos. Especially evidence wise.

But, getting a date wrong doesn't necessarily mean that he's wrong in general.

But the rest of your app still gets the simplicity of a declarative programming model.

https://docs.oracle.com/en/java/javase/23/docs/api/java.base...

Or this 6 word beast: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.dynal...

This is probably the most enterprisey sounding, but not the longest class I could find: https://docs.oracle.com/javase/8/docs/api/javax/naming/spi/I...

Autodesk (since you mentioned CAD) itself dates back to 1980s. And even then, they had at least 15 people working on AutoCAD. That's a small team size. Today, they have over 14000 employees. Some random website tells me they had ~5000 of them 20 years ago. You can make anything work when you throw an army of people at it. It's not exactly a good point towards small teams being able to build complex imperative/OOP apps.

That's not to say that Apple is not dropping the ball here. I don't really have any Apple devices to check for myself, but I know that Microsoft, for instance, has been doing much more than just dropping the ball when it comes to UI. But, I'm not sure that has anything to do with imperative vs declarative.

The main difference between various retained, OOP, functional, immediate, declarative, ..., approaches is how they treat this state.

For imperative/retained/OOP libraries, you operate on this state itself. Your nodes/widgets know their own state, how to render themselves, their place in the hierarchy and so on.

For immediate/functional(?) libraries, this state is a cache. It's not something you work with directly.

Despite not really liking React itself, I think it has found the best model.

You take a retained core, possibly OOP, maybe ECS or whatever, and you write a declarative wrapper around it. This lets you escape the easy-mode declarative landscape when needed, but most UI can still be simple to write.

But, once you start hitting things like differently sized elements, search and so on, you start running into platform limitations that you won't be able to resolve in React land.

Async is just difficult in general though. It's not really a surprise that most libraries/frameworks converged on similar designs.