Since RFC 4627 (the original):

> An object is an unordered collection of zero or more name/value pairs, [...]

Further, since RFC 7159:

> JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.

Both are in the current version (RFC 8259).

OTOH, I find the "but the order is not supposed to be guaranteed!" debate REALLY stupid when it comes to software where it's clear that at some point, a human will have to look at the content and correlate it with another system.

There's nothing more evil than re-shuffling JSON just for the fun of it and making everyone who has to look at the result miserable. Yes, I'm talking about you, ELK devs.

Edit: (And/or whoever wrote the underlying Java/Go libs they use for JSON that don't allow developers to patch ordering in. I remember reading GitHub issues about this.)

Less than 1% of the hash maps I use have ever needed order.

The underlying data structures between both are different. Ordered hash maps use more memory, are slower, and are more complicated.

Knowing CS fundamentals, using an ordered hash map should be a deliberate choice like renting a box truck when you need to move a lot of stuff. Don’t just drive a box truck everywhere because you might pick up a couch from a thrift store one day.

All well and true if all you have to do is process the data programmatically.

And yet, as I said, if the same thinking gets applied to e.g. a store of JSON documents (like ELK), chances are good the thing will ruin the UX for countless people who have to deal with the result. Note that you need exactly no hash maps to store the JSON as it is text.

To expand your analogy: …and yet roads are built so that you can drive your regular car or a box car over them, depending on your use case. You make the choice. A JSON library that doesn't afford such choices (and isn't hyper focused on performance) isn't a good one in my book.

Edit: As a sidenote: Or do you mean a freight train wagon? Then replace "road" with "rails" and "car" with "draisine" :)

Well that one at least has appreciable parallels :)

Letting an LLM loose on a real system without containing it in a sandbox sounds about as predictably disastrous as letting a glorified chess program run all ENCOM operations…

If she has little experience with video games, Journey and Gris might be good candidates.

For a more "technical" argument how gameplay mechanics can be a unique way to deliver an emotion to the player (arguably a major part in the role of art): Brothers: A Tale of two Sons. You'd have to make sure that she finishes it, though (estimate: ~3h).

Two trippy games that defy categorization (but won't be good examples for someone not willing to learn mechanics/logic in depth): Thumper and Cocoon.

Never heard of any of these. Checked them out and they all look great. Hard to decide but I think I will include one of yours. Thanks a ton!

Going into it blind; Journey is a special treat.

If she is a fan of detective stories, then you wish to look into L.A. Noire or Shadows of Doubt.

Ori and the Blind Forest

Jusant or Tiny Glade have a distinct look.

Edit: Not art but for two player games, try Lovers in a Dangerous Spacetime, Untitled Goose Game, or Trine.

> whether you write them down or not.

Note that "types have been written down" != "the program was written with static typing". See, for example, what's doable with clojure.spec.

While loose, "from the hip" code (w.r.t. typing) often correlates with the use of dynamically typed languages, we shouldn't make the mistake of assuming a total causality there.

(Also, I still find the number of people willing to put e.g. `object` parameters in their public C# APIs concerningly high. Not that one has to deal with such APIs all the time, but they're not exactly eradicated, either.)

Dynamic, strongly typed code is a quadrant that has confused a substantial number of conversations about how to handle typing.

I love this song, but it wouldn't be nearly as perfect without the slight hint of irony ("efficiently dangerous") and the SEGFAULT at the end. Things I feel "Write in C" is dearly missing.

That's just cousin Itt on a scuba trip ;)

Jira, Confluence, MS Teams.

Slow, disorganized, delaying every navigation, screwing up things as simple as copy+paste and other basic functions (Teams: muting/unmuting with a headset in voice calls, Jira: apparently, simple text templates in tickets are impossible (wtf?)), are impossible to search through successfully,… the list seems endless.

This.

I just learned this recently. Intuitively, I had assumed that I could .gitignore a file and have it not show up in `git status`, even after staging it with `git add -f` and committing it this way.

Turns out: That's not how it works. Instead, the .gitignore entries simply don't count for any already tracked files.

(Yes, I know about `git update-index --assume-unchanged` but that has its own set of drawbacks…)

Note: If you're going to use an SBC _only_ for wake up signals, you might want to look into alternatives for the RPi such as the Radxa RockPi S [1]. My home server, for example, runs continuously at 7W, which beats many RPi models. Of course, a Pi to wake things doesn't need that much power and could be an older model, but even then, you'd still be burning "empty Watts".

Of course, the RockPi doesn't give you any KVM like functionality, though.

[1]: https://wiki.radxa.com/RockpiS

Apparently RPi Zero idles at 0.4 W: https://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-p...

Yea, technically an esp32 board with ethernet would work for this job. They're typically limited to 10mbit, but if you have 10mbit/s of broadcast traffic you can afford something better.

> […] rather than things that have lots of examples.

Well, one glaring issue with the assumption of the quality of LLM output being mostly dependent on a large volume of examples online would be Sturgeon's law.