5,645 karma · joined December 7, 2024
In contrast, if you prefer phones with blue bodies for no particular reason and your first phone happened to be blue then it's at least possible that's an example (or maybe you just really like that color, I dunno).
Note that I view ? as a language construct rather than an operator. If for whatever reason someone insisted on including that in the strict left to right requirement the second example still works and is easy to read. I just don't like those semantics as much because the parenthesis in something like a ? ( b >> c ) : d are otherwise unnecessary. The implicit parenthesis of expr ? expr : expr seems preferable to me.
> Except that there are almost no circumstances in which "((a & b) + c) >> d" is a sensible expression.
That doesn't seem like a convincing argument to me. The question is whether or not the rules set you up for scenarios where misunderstandings are likely. Strict left to right does not - for example, given a & b << c it is immediately clear that the desired interpretation is not the actual one while b << c & a will unmistakeably do what you want.
Your employer has gone beyond testing in prod to vibecoding live in prod, secrets included. Yes that's completely insane. Perhaps this exact mentality is how the primary system wound up broken in the first place?
When a couple thousand dollars worth of perishable food shows up on your doorstep, what then? Not everything on amazon can be returned.
I absolutely detest it (TBF I haven't used it for the past ~2 years) but I also recognize that it's an incredibly difficult problem space that lacks an obviously good solution, the tool itself is inherently and irreducibly complex, it's a free project with extremely limited resources, it's been consistently improving over time, etc, etc.
I don't think that qualifies. There's an important distinction to be made between an aesthetic preference versus a professional not appreciating a tool being mucked with. Anything that interferes with my workflow without immediately providing substantial benefit is something that's actively harmful. In fact even if it does hypothetically provide huge benefits I still might not want to deal with it right this second.
If an end user encounters an error while staying within the bounds of "expected usage" then the bug is guaranteed to be valid. You just don't necessarily know whose bug it actually is (for example a broken library versus broken usage of the library by the consuming program).
So if you're strictly adhering to the spec in this case then unfortunately NULL is not an acceptable way to signal a generic error condition. Hence all the seemingly bizarre special values. (In a strange turn of events all those experts doing things that looked weird turned out to know what they were doing. Go figure.)
For bug reports (at least IMO) a minimal example to reliably reproduce the error without any fuss is the basic building block. The reporter doesn't need to understand why it works let alone offer an explanation. In fact for complex projects more often than not any purported explanation will be subtly incorrect and actively misleading. If anything further "documentation" of bugs is unwelcome. Unambiguously demonstrate the defect and GTFO.
IT is aware of surveillance. Lawyers have a legal responsibility to take all reasonable steps to safeguard confidential client information. A lawyer misusing a work device is probably roughly equivalent to a healthcare worker doing the same.
That said I wouldn't trust a compiler to be hardened against malicious input and anyway you presumably need to run the output so all of that should be happening in a hardened sandbox regardless.
If your laptop is successfully compromised by the pentesters then pretty much by definition you weren't being responsible. Though I agree that pentesters going after personal devices is ethically dubious.
This person definitely should have known. You don't download and run arbitrary binaries outside of a VM. At this point you don't even compile code from an untrusted source. This is the power user equivalent of falling for a phishing email.
I don't think their node problems were anywhere near that simple. You also left out the part where AMD moved to chiplets while intel stubbornly remained monolithic for quite a while. And a whole list of other missteps.
Granted their rocm support was abysmal several years back and they lost my trust as a result. But nvidia is hardly any better and intel doesn't seem to be a viable alternative ...
You might as well ask "but what if all the options are bad" while standing on a sinking ship contemplating your next course of action.
That's a touching sentiment or whatever but the nature of the thing is that it will inevitably be opened and that it cannot be closed thereafter. So (I think) we'd all be better off putting our efforts towards predicting the likely outcomes and figuring out how to make the best of them.