Readit NewsAPIs should either be typed to be unary (possibly with optionality/ error), or plural (allowing 0..many).
I've dealt with similar woolly design before. Introducing clear distinction between cardinalities gave a major improvement in logical clarity.
Compressing data, with the increased information density & greater number of CPU instructions involved, seems obviously to increase the exposure to corruption/ bitflips.
What I did wonder was why compress the filesize as an exponent? One would imagine that representing as a floating-point exponent would take lots of cycles, pretty much as many bits, and have nasty precision inaccuracies at larger sizes.
I like the insight of splitting Intent and State. There's a lot to the article & I'm not sure I fully understand the latter half yet, but I'm filing this one away for further exploration.
None of them called Stanley, but there's definitely a fairly common pattern I recognise.
My experience suggests that speccing out such an interface well is a tremendous amount of work, and if you get it wrong (you most likely will) or if it needs to evolve it will generate lots of work since now it's set in stone and very hard to change so you're likely going to pay "interest" by working around its shortcomings for the foreseeable future.
I've seen the misguided adoption of microservices affect a couple of companies & products.
One approach I've been thinking of experimenting with is saving everything I say, and using an LLM with my custom knowledge base to answer a question. I actually think a borg-like communication structure in a company could be really efficient. If every communication was publicly available, and we used ML to make that information consistent and to answer queries, I think you could achieve coherence with a company much faster, move as a unit much faster, and get a lot more done.
However, it's still a pipe dream at this point due to the context length limits. The actual amount of important context at a company is many times what a model can keep in mind now. As models get bigger, or if a group can run multiple models many times to make the company info widely consistent, it would be much better.
For instance imagine now, 30 people at your company work on one project, and 50 people work on another. They might take a slightly different definition for a term, and do work which is ultimately counterproductive to each other. Usually, it takes a conflict arising to resolve this, and people are long stuck with the mutually-incorrect definition. If an ML algorithm can look at everything both groups are saying and point out inefficiencies, I think you could get more cohesion, especially before problems get big enough to be a drain.
That being said, this type of system is more of a pipe dream, and I don't think it will be feasible for a few more years. In the meantime, I'm struggling how to balance communication with work. Advice appreciated.
Confluence works well if you KISS - write just what the audience needs to know, in terms they can read & find.
Avoid writing grand tracts of wanna-be architecture, policy, theory or planning; just write useful actionable material on topics your audience needs. You will find this works.
Source: I led 400 devs and this was the only way that could scale.
http://literatejava.com/documentation/how-to-write-good-wiki...
So the problem is not that GCC assumes your code has no UB.
The issue is that the C (and C++) specifications persist in this obnoxious and odious desire to label definable behaviour as UB, with no justification.
All of the arguments about needing UB to support different hardware fail immediately to the simple fact that the specification already has specific terms that would cover this: Implementation Defined Behavior, and Unspecified Behaviour. Using either of these instead of UB would support just as much hardware, without inflicting clearly anti-programmer optimizations on developers where the compiler is allowed to assume objectively false things about the hardware.
Undefined behaviour should be used solely for behavior that cannot be defined - for example using out of bounds, unallocated, or released memory cannot be defined because the C VM does not specify allocation, variable allocation, etc. Calling a function with a mismatched type signature is not definable as C does not specify the ABI. etc.
My particular beef is disposable/ short-lived goods -- the impact on the Earth of a product that lasts for 30 years is far less than one designed to need replacement after 5.
Yet weenie product managers & vulturous MBAs are constantly engineering things weaker & less repairable.
Sometimes to make the unit cost 0.5 cents cheaper, but perhaps more often to force earlier replacement and another revenue opportunity.
Checked exceptions work well for occasional major "expectable" failures -- opening a file, making a network connection.
They work extremely poorly when required for ongoing access or use of IO/ network resources, since this forces failures which are rare & impossible to usefully recover from to be explicitly declared/ caught/ rethrown with great verbosity and negative value added.
All non-trivial software is composition, so the idea of calling code "recovering" from a failure is at odds with encapsulation. What we end up with is business logic which can fail anywhere, can't recover anything, yet all middle layers -- not just the outer transaction boundary -- are forced to catch or declare these exceptions.
Requiring these "technical exceptions" to be pervasively handled is thus not just substantially invalid & pointless, but actually leads to serious rates of faulty error-handling. Measured experience in at least a couple of large codebases is that about 5-10% of catch clauses have fucked implementations either losing the cause or (worse) continue execution with null or erroneous results.
https://literatejava.com/exceptions/checked-exceptions-javas...