I don’t know how you could keep the two isolated, without drastically dropping up the utility of LLMs.
Part of their wonder is how they can behave differently depending on the data they’re working with. We like that feature when the data is the “good stuff” (docs, compiler messages, etc.), but how you tell that apart from “bad stuff” (prompt injection on official-seeming pages).
We basically expose LLMs to the same social-engineering vulnerabilities that humans have.
I agree with all the motives you describe, yet come to the exact opposite conclusion.
The overwhelmingly common case is for an error in a nested call to be bubbled up to be handled by a parent call. If you make this common case look similar to the distinct case of actually handling an error, you just obscure where the real error handling happens.
Writing good error handling is Go is really hindered by two other issues mixing together:
1. There’s no Result type, so while it tries to treat errors as values, it’s missing out on a lot of the benefit of that idea.
2. Multiple function return values are implemented as a special case, and aren’t themselves a value
Most languages that support multiple return values, do it via some notion of tuples: returning a single aggregate value that you can pass around as a whole, but that also have some nice syntax for destructuring them into local variables. Go implements as a syntactic special case.
You can’t assign the multiple return values of a function call into a single variable. You’re forced to take all the parts, and pack them into a struct yourself. This means that you can’t factor your result-handling logic into testable functions, without needing to do this dance at every call site.
Recent macOS versions zero out memory on free, which improves the efficacy of memory compression. Apparently it’s a net performance gain in the average case
The industry assures us they’re just filling demand that already existed, that used to be fulfilled by a black market anyway. So now it’s all above board and taxed and hunky dory.
It’s a bit odd they spend a lot of money on advertising to stimulate demand though, hmmmmmmmm /s
FWIW, AoC is very non-representative of real-world string manipulation problems.
The AoC format goes out of its way to express all problem inputs and outputs in simple strings with only basic ASCII text, just for compatibility with the most programming environments. This is very different from almost all real-world problem, where the complexities of human language are huge.
Typed exceptions are unlike typed parameters or return values. They don’t just describe the interface of your function, but expose details about its implementation and constrain future changes.
That’s a huge limitation when writing libraries. If you have an old function that declares that it can throw a DatabaseError, you can’t e.g. add caching to it. Adding CacheError to the list of throwable types is an API breaking change, just like changing a return type.
Swift has typed errors now, but they shouldn’t be used carefully, and probably not be the default to reach for
Dynamic languages can execute code without type annotations, so you _can_ just dismiss types as redundant metadata. But I don’t think that’s wise. I find types really useful as a human reader of the code.
Whether you write document them or not, types still exist, and you have to think about them.
Dynamic languages make it really hard to answer “what is this thing, and what can I do with it?”. You have to resort through tracing through the callers, to check the union of all possible types that make it to that point. You can’t just check the tests, because there’s no guarantee they accurately reflect all callers. A simple type annotation just gives you the answer directly, no need to play mental interpreter.