I believe every reader understands that Claude’s behavior is faulty here, what the disagreement is whether or not it is a tragedy. As the result of the error is a minor inconvenience, there is no tragedy.
giving AI access to delete all your files -> human in the wrong for sure
I'm not saying the AI did make a mistake, but it should have been limited to the file it was working on, not everything in the dropbox. and yes, that's an error from the human
This is obviously bad model behavior (though I'd personally like to see the full transcript to see if there are any clues in there as to why it made the mistake.)
It's hardly new, though. We've been talking about models making stupid mistakes like this for years.
> We've been talking about models making stupid mistakes like this for years.
It seems like it should be a bigger issue that despite years of updates and improvements, AI agents still shit the bed in spectacular fashion like this. Simply shrugging our shoulders and accepting "agents be crazy" is precisely the opposite reaction we should take, especially as tech professionals.
Perhaps the joke about how meteorologists are the only professionals who can screw up badly on the regular and keep their jobs needs to be updated to include LLMs.
I wonder what this means for custom async implementations in the long run.
I was considering using my own AsyncBuilder to bring over a rudimentary "computation expression" capability. But that might be out of question now.
The post you replied to literally doesn't care about upgrades.
More enforcement also doesn't matter if its what you need to get specifically _what was asked for_, which is a thinner device in this case.
I also wouldn't like an X60 if it meant I have to leave things out of my bag.
AFAIK, the language is and was used in JB's projects.
JB is just very picky about when he wants people to see things.
He doesn't want outside voices influencing him and he still has some things he wants to think through. Doing that mostly solo takes time - it's not like the PL is the only thing he has been doing
If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I would like you to elaborate on how still being in closed beta is an argument against the thesis. To me it just looks like avoiding feature-requests, nitpicks and community interactions for a product he doesn't even want to sell.
I'd agree more except that as far as I know (I'll admit I've not been following the development that closely) he's been significantly building it in public on Twitch. So he's happy to spend time sharing it with the public, and has been from the start; it's just taken a long time to get it to a usable state.
> If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I think we're firmly in agreement here, except that IMO the default for software that's not for public consumption is to throw it over the wall, put the source up on GitHub or something, and not bother with documentation, explanation, or interaction. A carefully curated closed beta is kind of the opposite of that. If anything he's spending more time promoting it than I would expect.
Do people miss the word "ergonomically" in my original comment? Because yeah, the semantics is essentially the same, just as it would be the same for e.g.
double.TryParse("5.x5", out double val, out bool ok);
if (ok) { ... }
in case of a hypothetical variant of C# that doesn't have functions, only procedures, so you'd have to return the data from subroutine calls by ref/out/globals exclusively. It's still would be the same semantics — but quite different ergonomics.
So out of those three choices: return all results by assigning to ref/out parameters; return one result directly, all other by assigning to ref/out parameters; return all results directly — I personally prefer the last one. Almost nobody prefers the first one, yet people seem to be strangely attached to the second variant for some reason.
the set theoretic type system variant has one issue I think the algebraic one avoids:
An overlap between types is ambiguous, i.e. "int | int" doesn't make any sense to write. In a function parse_postal_code, where you either get the postal code, or an error code you wouldn't be able to differentiate.
You could write your own types for that, but now you've essentially recreated what the algebraic versions do by forcing a selection through the type constructor on the inner type instead of the wrapping union type.
That being said, in cases where there is no overlap I don't see why "the old way" shouldn't behave like typescript through implicit conversion as there is only one applicable constructor. Forcing explicit selection if there is overlap, but do it automatically when there is none seems like reasonable behavior that is a strict superset of what you wrote before.
At least the fallout will be less if you have to resolve your custom domain differently in the intranet due to something like this.
If github is "taken down" you can't just resolve the whole domain differently, you need to only resolve the packages differently. If your "Golang domain" is taken down, it should be a lot easier to hotfix until something proper is implemented (the quickest and dirtiest would be a hostfile-entry).
I don't know about you, but I do not want to block on every keystroke.
Program analysis can take time, asynchronous feedback is a natural fit.
None of the features I use from LSP should be synchronous.
I can almost guarantee you that a synchronous API would yield a much more complicated design just because many operations can not be expected to reliably work within a few milliseconds.
You want to rename something across multiple files? Well now you add file system overhead and blow straight past reliable frame timings. Good luck waiting for that operation to finish. Of course you could make the API beginRename, and queryRename, or whatever you fancy to see if the operation was successful, but now you're back to what you wanted to avoid: an asynchronous API.
Do mind that the example is actually one of the better cases, as many things you might want to do with a codebase are actually more expensive.
You will feel the hiccups from waiting in the UI thread and you will loathe the program for it.
I assume that the result of the rename operation must be known. I.e. if it was successful or not, or which files were affected. That implies 2 function calls. One to start the operation, and one to query its result. That is, by definition, already an asynchronous interface.
The only other (i.e. synchonous) way to achieve remote procedure calls is by blocking until it's finished.
If you insist on showing the result of a rename on the next frame, then yes, it must block the next frame until it's done.
Would you write your editor that way if it didn't use LSP but was specific to one language? If not, but you would write it that way with a language plugin, why? You still have to write a good product. You can't blame the plugin API for everything you get wrong.
As far as I know you might want to read the GLSL or Vulkan specification. At least there (and by extension in SPIR-V) you can select different floating point behaviors.
Historically graphics programming has been more concerned with looking good rather than being accurate, and behavior is likely different on each GPU. It's a "hop into the water and learn to swim" kind of thing as far as I'm concerned.
You will find errors for things you'll never have thought about and there is hardly any way to brace for it except trying on the go.
In short: Benchmark numbers were always more important than consistency (traditionally, GPU vendors competed on frames-per-second, not on image quality).
E.g. floating point behaviour is only the tip of the iceberg. Every GPU vendor also does mipmapping differently (to balance image quality versus required memory bandwidth).
Files not recovered -> human in the wrong
Files recovered due to independent backup -> no problem
Is there any scenario in which you'd accept Claude's behavior as faulty here?
reply