> Given that the author works at an AI accelerator company
I actually believe he works at Buf.build and his resume is stale, the author previously posted about their Go Protobuf parser hyperpb which is a Buf project.
Maybe still "author recently worked at an AI accelerator company" though.
The question isnt whether such cases exist, but instead whether they actually need c++26 and what the downsides are to everyone else if c++31 or whatever is still constrained by it.
It is, Google Books did it over a decade ago (bought up physical books and scanned them all). There were some rulings about how much of a snippet they were allowed to show end users as fair use, but I'm fairly sure the actual scanning and indexing of the books was always allowed.
The reason is that the uniform distribution is very rare. Nearly no real world scenario were something is equally likely to be the values 2, 0 and -2, and where it's literally impossible to be -2.01. It exists but it's not the normal case.
In noisy sensors case there's some arbitrary low probability of them being actually super wrong, if you go by true 10^-10 outlier bounds they will be useless for any practical use, while the 99% confidence range is a relatively small rent.
More often you want some other distribution and say (-2, 2) and those are the 90th percentile interval not the absolute bounds, 0 is more likely than -2 and -3 is possible but rare. It's not bounds, you can ask you model for your 99th or 99.9th percentile value or whatever tolerance you want and get something outside of (-2,2).
> But why one would complain about YaML's whitespace? It is not obligatory.
The problem (as felt by me and also as identified by the person you replied to) is that you can't copy-paste/munge some stuff into the right spot and then just let the formatter to fix the indentation. It's not a problem that the format "at rest" has whatever certain indentation to be correct, its that while being actively editing your formatter cannot automatically set the correct indentation.
The flow that you're talking about of converting yaml to json and then putting it into yaml could work in some cases but thats very much a kludge. It will have numerous bad side effects unavoidable, including that it would discard comments in the middle since JSON doesn't allow for comments at all, theres no timestamps in JSON, there's no octal numbers, etc.
> The problem (as felt by me and also as identified by the person you replied to) is that you can't copy-paste/munge some stuff into the right spot and then just let the formatter to fix the indentation.
That problem I undestand, and that is why I suggested to convert both into JSON —or YaML with default_flow_style=True which would preserve datetimes and other non-JSON stuff— and copy-paste without the hassle of having to indent/unindent correctly. Of course that doesn't help with copying comments. That would need extra copy-paste operations, but still one hasn't the hassle of significant whitespace. The following is also valid YaML:
{"some_key": {
"attr1":
# an intermittent comment
"val1", "attr2": 12312 # more comments!
}
}
It doesn't seem weird at all to me: standard is essentially the consensus of the major browser vendors; a spec which all of Chrome, Safari and Edge don't implement is really just a hypothetical.
The origin story of whatwg is that Apple, Mozilla and Opera decided that W3C wasn't making specs that they wanted to implement, so they created a new working group to make them.
Even if all wire format encoding is utf8, you wouldn't be able to decode these new high codepoints into systems that are semantically utf16. Which is Java and JS at least, hardly "obsolete" targets to worry about.
And even Swift is designed so the strings can be utf8 or utf16 for cheap objc interop reasons.
Discarding compatibility with 2 of the top ~5 most widely used languages kind of reflects how disconnected the author of this is from the technical realities if any fixed utf8 was feasible outside of the most toy use cases.
Yeah, WTF-8 is a very straightforward "the spec semi-artificially says we can't do this one thing, and it prevents you from using utf8 under the hood to represent JS and Java strings which allow for unpaired utf16 surrogates, so in practice utf8-except-this-one-thing is the only way to do an in memory representation in things that want to implement or interop round trip with those".
It's literally the exact opposite of this proposal, in that there's an actual concrete problem and how to make it not a problem. This one is a list of weird grievances that aren't actually problems for anyone, like the max code point number.
Play Store also does this now and it's a fundamentally radical departure from the era where if you give the company your card info directly theres a high chance you aren't going to be able to get out of it without paying at least some amount more than you should.
Think gyms where you refuse to cancel even when you are physically there in person with someone to yell at and imagine trying to do the same online where there's not a phone number, or a phone number with a 1 hour wait and a CSR paid based on if they can successfully not give you what you want
I actually believe he works at Buf.build and his resume is stale, the author previously posted about their Go Protobuf parser hyperpb which is a Buf project.
Maybe still "author recently worked at an AI accelerator company" though.
reply