WTF Bites
-
When completing the survey, please do not use the back button of your browser as this will cause an error.
Good jorb, ${whoever}!
-
Is this a covid costume?
It's a celebration of anal prolapse.
I thought it was a tentacle personally.
-
E_TENTACLE_NEITHER_PURPLE_NOR_GREEN
-
-
@topspin you know how they say you can't hear pictures, I hear that one saying "...TAKE OVER THE WORLD" juuuuuuuuuuuuuust fine.
-
... I can respect this.
-
@topspin you know how they say you can't hear pictures, I hear that one saying "...TAKE OVER THE WORLD" juuuuuuuuuuuuuust fine.
Error: Asset not cached, loading, one moment....
https://youtu.be/IYcYVjCSFDo?t=23
Sound byte loaded. Reverting with data...
-
@cvi I have respect for doing this - but more respect (for once) for the legal team for actually permitting this.
-
@cvi I have respect for doing this - but more respect (for once) for the legal team for actually permitting this.
So long as the constituents in the agreement are able to reasonably comprehend said agreement, I'd imagine you could get away with quite a bit...
-
Status: Bitch, I'm not getting permission from a deleted user to delete this folder!
Edit: Fuck it, can't fix it with permissions. Nuked using
root.
-
WTF of my day: Author of the popular NuGet package
Moqpushes an update wherein he sends a hash of your scraped Git email to a service to then nag you into subscribing to said sponsorship service. This service is run by the author. Oh, and the "nagging" consists of pausing the build for a bit to output a message to the terminal and also creating awarning. Which makes it doubly fun for those people whose company treats warnings as errors. And, of course, the warning cannot be disabled.This change went down like a lead balloon.
https://www.reddit.com/r/dotnet/comments/15ljdcc/does_moq_in_its_latest_version_extract_and_send/
Oh, and he assures people that he's not doing anything nefarious and only sending a hash of your email. Which we can't check because the code for this sponsorship service is both closed source and obfuscated.
I mean I get that he'd like to see more money for his work - after all, it is a very popular package - but this seems to be one of the worse ways to go about it.
edit: And, as it turns out, the update version of
4.20is explicitly meant as a joke. Which turned the lead balloon into one made of depleted uranium.
-
@Rhywden Another reason why build servers should not have access to the internet.
-
@Rhywden Another reason why build servers should not have access to the internet.
Yah, that's what some people are reporting as well - their build servers don't build the project with this version included.
-
I can't think of a single reason why you'd want keys to be in alphabetical order ever.
If there is no other logical order for the elements, that's probably the least-bad possible order for e.g. later devs debugging the code. Probably not a big deal when the list is easy to scan but if there are more than a dozen or so elements, alphabetical order makes it easy to see if some key exists or not.
But yeah, forcing alphabetical order in all cases is retarded.
-
the update version of 4.20 is explicitly meant as a joke
As opposed to a "that went really badly, so I'd better laugh it off and hope people don't send assassins"?
-
the update version of 4.20 is explicitly meant as a joke
As opposed to a "that went really badly, so I'd better laugh it off and hope people don't send assassins"?
Sort of like a stand-up comedian in Alabama who jokes: "Boy, there are a lot of family trees who look like a circle in here!"
-
the update version of 4.20 is explicitly meant as a joke
As opposed to a "that went really badly, so I'd better laugh it off and hope people don't send assassins"?
Given how he was defending his change from all comers in at least one Reddit thread, “it was joke” is more of an apologist retcon.
-
But yeah, forcing alphabetical order in all cases is retarded.
It's a damn good idea to have a defined order, but it turns out that key creation order is usually the best option, i.e., it keeps the order that you first put things in (modulo any time you remove things). You can then have a style check for alphabetical ordering if you must, so long as it is something you can easily explicitly say "no, deliberately don't want that here".
Technically speaking, maps that maintain creation order do so by keeping the leaf elements in a linked list (as well as whatever mechanism handles lookup, often a hash table as that has excellent performance features) whereas maps that maintain alphabetical order do so by keeping everything in a sorted balanced tree.
-
It's a damn good idea to have a defined order, but it turns out that key creation order is usually the best option, i.e., it keeps the order that you first put things in
I don't think the discussion here is about how the keys are ordered internally. What's discussed here (at least, how I understand it) is about the order keys appear in the code (
{ name: ..., start: ..., end:...}in the OP). It's all about helping humans read (and hopefully understand?
) the code. Whatever is done internally with those keys... is not a pointless question, but it's a different one.That said, yes, keys should have a defined order, but it should be obvious that in many cases this won't be the alphabetical one. Even in cases where there is no clear order, alphabetical order isn't necessarily the best one (it might make more sense to e.g. group some related items together, even though there is not necessarily an order between or inside those groups).
-
The thing is, in JSON, key order being alphabetic is the defined behaviour. If you are writing JSON in your code, writing it in non alphabetic order is
WRONG.See, JSON to spec only permits alphabetic ordering, so eslint’s behaviour is somewhat cromulent here. The fact that most runtimes will accept JSON not to spec is entirely a different behaviour, especially since
{ key: "value" }also isn’t strictly legal JSON even if it is legal for defining an object in JavaScript. (Keys should be double quoted just like string values)I suppose the argument that could be given in eslint’s favour is that by forcing you to have alpha order, you shouldn’t produce bugs later on iterating over the keys expecting them in a different order. But that is separately a stupid argument…
-
So TR
here is JSON, not (just) eslint. 
Not quite sure what to make of all that. Probably forget it as I'm not currently working with JSON, and hoping I never will. I already have to deal with Fortran that looks older than I am (and I do have a
), so I'll let someone else fight that fight.
-
the update version of 4.20 is explicitly meant as a joke.
Maybe he was stoned when he came up with the idea.
-
@remi yeah, the underlying
is that defined order being alphabetic, because you cannot rely on insertion order in any meaningful fashion because of how JS pollutes its shit everywhere to the point that they had to invent a second way of iterating over the contents of an object because the first one got so broken.
-
See, JSON to spec only permits alphabetic ordering,
Since when?
© Ecma International 2017 3
6 Objects
An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs.
A name is a string. A single colon token follows each name, separating the name from the value. A single
comma token separates a value from a following name. The JSON syntax does not impose any restrictions on
the strings used as names, does not require that name strings be unique, and does not assign any
significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by
JSON processors or in specifications defining specific uses of JSON for data interchange
-
There are at least 7 JSON specifications, but I don't think any of them care about key order.
-
So TR
here is JSONNo,
is anyone thinking that the order of keysnames in JSON objects matters at all. Or that names must be unique (because
).
-
Remi is still correct though, JSON as defined is still pretty WTF-y, with things like forbidding trailing commas and a total lack of comment support.
Which leads to the next WTF, of Microsoft choosing JSON as format for fucking configuration files (though technically it's a variant that's supposed to support comments).
-
@dkf like I said, I don't deal with JSON so I just assumed that @Arantor was right. If not... well, forget I said anything then.
I don't care either way about the
-ness, or lack thereof, of JSON. The -ness, or lack thereof,of Fortran is more than enough for me right now.
-
I blame the Mandala effect in my defence, could have sworn it was mandated because every current engine enforces it this way in actual use.
It is all bullshit for configuration, and as much as I hate YAML, it is a legit improvement over JSON for config.
-
@Arantor I have yet to see an engine that cares about JSON key order. I've seen plenty that (wrongly) care about the indentation, requiring not only there to be indentation, but requiring spaces, not tabs and throwing a hard error on tabs.
Coincidentally, I ran into a case where some program was parsing JS comments for API documentation creation. Those comments had to be in yaml inside a comment block, with a single leading space after the comment character for the line. And yaml really doesn't like inconsistent indentation. So even if the rest of the file was indented with tabs... Those lines had to have just the right number of spaces. Oh, and this was a run time error, not a build time one.
-
“Let’s use a chatbot to serve information that could also just be on a static page.”
I had reason to try and reach PostNL’s customer service. Once you navigate their help pages, you basically get four options: “Daan” the chatbot (who, of course, only really points you to things you’ve already looked at on your own), try and get hold of a human chatperson (with “Daan” getting in the way first), phone them up, or write a letter. In exasperation, I ended up clicking on that last one just to see where that would get me.
That opens the chat window, so that the bloody chatbot can tell you the address … because they can, I guess?
-
Remi is still correct though, JSON as defined is still pretty WTF-y, with things like forbidding trailing commas and a total lack of comment support.
It is meant to be a serialization format that is sort-of human readable and editable for debugging purposes. And for that it is appropriate. What is a
is that it does not require the keys to be unique but leaves meaning of repeated keys open to variation between implementations. Which might end up being a problem. Even a security one (if your validation uses different interpretation that the deserialization somewhere deeper in the stack).Of course there was … and still is … shortage of good, human-friendly serialization formats, which meant that some started using JSON including its limitations, and others created a bunch of mutually incompatible extensions: JSONC, JSON5, HJSON, HOCON, CSON …
… looking it up, I ran across this critique of TOML. And the point about types is 1. also applicable to JSON, 2. mostly JSON's fault and 3. quite good as far as configuration files go: distinguishing types of scalars at the parser level is superfluous, because the eventual interpretation is up to the application, and most values won't be string or number, but specific enums and other types, while the distinction between number and string will always never be meaningful.
Which leads to the next WTF, of Microsoft choosing JSON as format for fucking configuration files (though technically it's a variant that's supposed to support comments).
And since its an extension, they could have allowed trailing commas too and things would be mostly fine. The other extensions like JSON5 and HJSON do allow them. But no, that would have been too useful.
-
… looking it up, I ran across this critique of TOML.
TOML is awful. Yet another damn language for configuration things that pretends to be simple while having the yawning abyssal maw of complexity hiding underneath like that strange monster in the deserts of Tattooine.
JSON has its faults, but at least you can both read it by hand, normalise it and get something approximating sanity. In that, it beats ASN.1, XML, YAML and TOML.
-
@Benjamin-Hall said in WTF Bites:
@Arantor I have yet to see an engine that cares about JSON key order.
I wanted to say anything that deals with JWTs, but apparently no, they are not required to be canonical. There is a definition of canonical JSON (rfc-8785), but the JWT spec explicitly states the token payload does not have to be canonical.
There is probably a crypto-related thing or two that does insist on the input being canonical, and in practice anything that produces JWTs does use canonical formatting to make them, but otherwise readers generally don't care.
-
@dkf well, TOML was basically an attempt to create a normalised 'standard' form of INI file...
-
TOML is awful. Yet another damn language for configuration things that pretends to be simple while having the yawning abyssal maw of complexity hiding underneath like that strange monster in the deserts of Tattooine.
TOML is the illegitimate child of
art and scienceINI and JSON. It tried to get the better of both, but got the worse instead and some gratuitous complexity on top (there are too many ways to write everything, though not as many as in YAML).JSON has its faults, but at least you can both read it by hand, normalise it and get something approximating sanity. In that, it beats ASN.1, XML, YAML and TOML.
ASN.1 does not belong in this list. ASN.1 is not a data format, it is a schema format. An object defined by an ASN.1 schema can be written in JSON (JER), XML (XER), one more poorly defined text representation (GSER) or a bunch of binary formats. Which, unfortunately, don't have completely self-describing structure unlike e.g. protobuf, which makes it harder to evolve them backward-compatibly.
Anyway, for configuration I quite like HCL used in terraform & co. It is also almost isomorphic to JSON, terser where appropriate, and supports simple expressions for cross-referencing things. But it's something that needs to be tailored to each application, and I'm not sure how close the other implementations follow the reference Go one.
In the past I also thought about using jsonnet for configuration.
Anyway, if you want to see true abomination, look no further than helm. Trying to emit YAML, with its 2-D syntax, with go templates, with their fragile whitespace control, is a real treat. God help you if you fail to eat the leading, but not the trailing whitespace (to keep the important newline) of control structures by carefully writing
{{-if/range/end/…}}while your IDE is “helpfully” inserting the trailing-. And that convention isn't even really documented anywhere.
-
I blame the Mandala effect
I'm disappointed with my image search for Mandela mandalas.
-
I blame the Mandala effectI'm disappointed with my image search for Mandela mandalas.
Did you ask Bard for help, or possibly Midjourney?
-
Remi is still correct though, JSON as defined is still pretty WTF-y, with things like forbidding trailing commas and a total lack of comment support.
Why would an inter-process data interchange syntax need comments?
is using it for things it's not designed or intended for.
-
Or that names must be unique (because
).Unique names are what you want 99.999999% of the time, and the other 0.000001% can be adequately handled with a list. It's a good thing JSON property names must be unique.
-
Or that names must be unique (because
).Unique names are what you want 99.999999% of the time, and the other 0.000001% can be adequately handled with a list. It's a good thing JSON property names must be unique.
World integrity check--I agree with you!
-
@Benjamin-Hall I'd more question whether or not pushing it into something like the JSON standard or into JSON parsers is the right choice.
It complicates parsers in the sense that they now should check for it. You basically can't write a proper parser that uses O(1) memory (I mean, I guess you can just ignore the requirement, but then you're also not following the standard(s)).
I feel like pushing it into the parsers kinda violates the principle of being conservative in what one sends, but liberal in what one accepts.
That said, it's less annoying than the trailing commas. And, frankly, much of the problem is with the fact that nothing that I encounter that consumes JSON seems to bother with giving useful error messages to me.
-
-
@Benjamin-Hall I'd more question whether or not pushing it into something like the JSON standard or into JSON parsers is the right choice.
Yes. Yes it is. A parser that can't assume unique keys can't return a regular hashmap. It'd be PITA to work with in the common case. Have you ever seen code that handles XML? All API functions return lists because they can't assume uniqueness, and so your code becomes 30%
.get(0)by mass.
-
the principle of being conservative in what one sends, but liberal in what one accepts
That's not a good principle. You don't want to follow it unless you are looking for inspiration for front page articles. Because in practice if you accept garbage, garbage is what you'll get, and when you'll need to become a bit stricter to handle some case you didn't care about before, people will just be pissed at you for breaking things that used to work. Better be strict in what you accept from the start.
I mean, I guess you can just ignore the requirement, but then you're also not following the standard(s)
While most parsers should be strict, and they are, and that's a good thing, it is not mandatory to be. Prohibiting it in the standard wouldn't mean that all parsers must signal an error on it, it would mean that they can signal an error, and that writers are not allowed to produce it. And since most parsers collect the data into some structure, it would be trivial for them to check that they already set this item.
You basically can't write a proper parser that uses O(1) memory
I would also note that if both uniqueness and order were specified, you could again. Because then you just need to remember the previous item and check the next one is strictly greater in the defined ordering.
-
@Benjamin-Hall I'd more question whether or not pushing it into something like the JSON standard or into JSON parsers is the right choice.
Yes. Yes it is. A parser that can't assume unique keys can't return a regular hashmap. It'd be PITA to work with in the common case. Have you ever seen code that handles XML? All API functions return lists because they can't assume uniqueness, and so your code becomes 30%
.get(0)by mass.The thing is that JSON parsers generally do return regular hashmaps. Because that's the first parser did and how it was really intended. Just because the specification says the keys don't have to be unique, the parsers tend to silently take the last or the first value for that property and discard the rest.
-
Remi is still correct though, JSON as defined is still pretty WTF-y, with things like forbidding trailing commas and a total lack of comment support.
Why would an inter-process data interchange syntax need comments?
Because the output of that syntax ends up (or can end up) written in a text file. Therefore, irregardless of whether it's intended or designed for human consumption, it will be used by humans, and humans will want to add comments.
Besides, comments is such a common feature of every possible language/format that everyone expects comments to be available. Even some binary file formats for pictures (e.g. PNG) allow for comments! So not having a comment format in a spec is breaking the principle of least surprise.
The main argument against it would be if it's technically hard to implement, and while in the generic case it may be (HTML comments have some weirdness, IIRC?), allowing some simple form of it shouldn't.
-
The main argument against it would be if it's technically hard to implement, and while in the generic case it may be (HTML comments have some weirdness, IIRC?), allowing some simple form of it shouldn't.
The other argument against it is that people will insist on putting semantically-significant information in there that their application relies on in some ad-hoc way.
-
@Watson well as the meme goes, "life, uh, finds a way."
People will likely abuse comments, that's true, but if you don't explicitly allow for comments, people will find a way to abuse the language itself (maybe with unused keys or whatever) to put in comments. And then they will abuse these "comments" in an even worse way because they will think themselves smart by using language features inside their "comments."
Something something about the universe designing greater fools.
-
Did you ask Bard for help, or possibly Midjourney?
Are they usable without creating accounts?
I'm asking out of mild curiosity. I don't see myself using them anyway.
