Well, an "arms race" doesn't always involve using the arms. For example, the Cold War was an arms race, but it was focused on the stockpiling of nuclear weapons, not their actual use.
Because the Essence that is the arrangement of molecules replicates onto other molecules, and it is more effective at replicating when it dedicates some of it's molecules to perceive and model it's own existence, in order to run experiments on it. That way it's more likely to find a behavior for the rest of the molecules to successfully replicate. So the molecules experience themselves, and the experience becomes more intense the more advanced the experiments are that can be run on the model.
What is the Essence? In my head I picture movement or electrical fields propagating from some sort of proto cell like structure, but the more I try to “zoom” in, the more I try to find the finger that caused the ripple on the pond surface, so to speak
That comic doesn't show someone working around a bug in such a way that their flow breaks when the bug is gone. It shows them incorporating a bug into their workflow for purposes of causing the bug to occur.
It isn't actually possible for fixing a bug to break a workaround. The point of a workaround is that you're not doing the thing that's broken; when that thing is fixed, your flow won't be affected, because you weren't doing it anyway.
It might be as simple as a property name containing a typo, and the workaround being to expect that incorrectly spelled property name. When the typo is fixed, the code that was expecting the misspelled property breaks.
Maybe it's a bad workaround, but your users will almost certainly implement bad workarounds.
> It isn't actually possible for fixing a bug to break a workaround.
That's not true. For instance, if there's a bug in formatting, that might be worked around by handing the unintended formatting. But now you're (maybe) not handling the intended formatting, and a fix would break you.
I don't think this is "apologizing mode", rather "funny post-mortem blog post" mode. I found it ironic when the company claimed it will "perform a post mortem to determine exactly what happened" when what happed probably was caused by munching up dozens of these.
> and being unintuitive is the only one that this will fix
That's also how I'm approaching it. If all the condensed common wisdom poured into the model's parameters says that this is how my API is supposed to work to be intuitive, how on earth do I think it should work differently? There needs to be a good reason (like composability, for example). I break expectations otherwise.
Right: for me that's when "prompt engineering"/"context engineering" start to earn the "engineering" suffix: when people start being methodical and applying techniques like evals.
You've heard of science versus pseudo-science? Well..
Engineering: "Will the bridge hold? Yes, here's the analysis, backed by solid science."
Pseudo-engineering: "Will the bridge hold? Probably. I'm not really sure; although I have validated the output of my Rube Goldberg machine, which is supposedly an expert in bridges, and it indicates the bridge will be fine. So we'll go with that."
"prompt engineer" or "context engineer" to me sounds a lot closer to "paranormal investigator" than anything else. Even "software engineer" seems like proper engineering in comparison.
If it's actually validated, according to rigorous principles, it's not a guess, but a system of predictions with a known confidence interval, that allows you to know if you can be sure of something.
Right now, you cannot get that far. And if you happen to... Tomorrow it will be different.
Predicting tides is possible. It requires enormous amounts of data and processing to be sure of it. Right now, we've got tides, but we don't have the data from the satellites. Because the owner is constantly shifting the prompt, for good reasons of their own. So we can't be confident - or we can only be so blindly.
Funny how you use a scientific term to discredit applied statistics. I've built useful non-deterministic systems many times and they had nothing to do with AI. Also, particle physics would like to have a word with you.
Guessing, how a non-deterministic system would behave.
Statistics isn't guessing. But it is guessing when the confidence interval is unknowable and constantly shifting. We're not talking relativity, we're talking about throwing pancakes at a wall to tell if there's a person behind it.
One could say the whole point of wrapping exceptions is to add additional metadata _if such data is available_. Otherwise, the most basic metadata is tracked automatically: stack locations.
Technically, the actual whole point of wrapping is to avoid leaking implementation details. If you let "FooLibraryException" bubble up, and then you stop using Foo Library, then all of the users of your code are going to end up broken waiting for "FooLibraryException" when now you throw "BarLibraryException". This diminishes any value exception handlers theoretically could provide since you end up having to wrap everything at each step anyway.
Checked exceptions were introduced to try to help with that problem, giving you at least a compiler error if an implementation changed from underneath you. But that comes with its own set of problems and at this point most consider it to be a bad idea.
Of course, many just throw caution to the wind and don't consider the future, believing they'll have moved on by then and it will be the next programmer's problem. Given the context of discussion, we have assumed that is the case.
reply