Bash is ubiquitous and stable, making bash scripts incredibly portable.
All of the other languages you bring up are great for authoring code, but have a non-zero amount of friction when running code in the wild. Python may be omnipresent, but you can rarely count on a specific version or the presence of specific libraries. Go requires compiling platform-specific binaries. Even JVM- or JS-based software requires installing a separate toolchain first.
If you want to write some code (e.g., a launcher, installer, utility code, etc...) that is almost certainly going to run on any computing device created in the last several decades, bash is your language.
From a practical standpoint for most database systems, sort of? One might say that there's a functional dependency from the 'time' to the 'precipitation' attribute, and providing that information to the optimizer might affect its decisions... but at the level of data storage and query evaluation runtimes, there's not a huge difference.
From a data modeling and query optimization perspective, however, there's some value in distinguishing attributes uniquely related to identity (e.g., keys, or group-by attributes) and attributes that we're only interested in computing statistics over. This makes it easier to automatically create e.g., data cubes or similar indexes, and many useful statistics can be modeled using a nice mathematical structure like a ring or semiring [1], who's properties (commutativity, associativity, distributivity) are very helpful when optimizing queries.
Classical Datalog, in particular, is entirely based on the former type of attribute; value (dependent) attributes always need to be hacked in, in some way.
The big difference I see at a skim is that, in classical datalog, facts are only allowed to contain domain attributes, and not value attributes. E.g., you can express binary facts like Raining(12:00) (it's raining at 12:00), but not Rain(12:00) = 5 in (At 12:00, 5 inches of rain had accumulated).
Value attributes make it much easier to express most forms of aggregation (sum, min, max), so you'll find very similar patterns in practical datalog variants e.g., RelationalAI's Rel [1], DBToaster's AGCA [2], etc...
Apart from that, and a syntax that seems to resemble map-style collection programming a bit more than datalog, yeah, this basically looks like datalog.
TFA's point is that the model is horrible for creators: a revenue sharing model is only viable as long as the number of creators being shared is comparatively small. $5, $10, $20 from a few hundred or thousand viewers is a decent haul when compared to a few fractional pennies per view.
It makes sense that creators focus their efforts on cultivating personal relationships with a small, but loyal base. You're not their target demographic.
Differing skillsets? Managing people doesn't have to mean more responsibility. Some people are good at doing, others are good at the bureaucracy game and buffering for the doers. Both are critical, and in a good org, both have different, but not necessarily differing scales of responsibility.
Things are bad enough already, even with pre-LLM technology. "I'm sorry sir, your 8-year old son can't board this plane because the system says he's a terrorist" [1].
NYC, and Manhattan specifically, is one of the rare places in the country where having a car is almost virtually unnecessary. In downtown, cars are already playthings of the rich: Just parking the car during peak hours can run you hundreds dollars of per month.
The core of NYC has walkable infrastructure and an amazing public transportation infrastructure (at least compared to much of the rest of the country). For those commuting in from suburbs, park-and-rides are already a far more cost-efficient option.
The researchers behind the project have since moved on, but the idea of a db underpinning a game engine came up over a decade ago in Walker White's work at Cornell. Unsurprisingly, there's a whole lot of ways in which expertise from the db community can be commoditized to allow game devs to focus on the game, rather than hand optimizing code. For example, query optimizers can make it easier to scale up complex agent behaviors [0]. The project also spawned some interesting work on checkpointing, distributed replication, and computation over uncertain state.
As the peer comment points out, functional data structures force you to be deliberate about where/when state changes take place. In particular, they force you to be cognizant of which version of a data structure a particular piece of code is referencing.
Immutable structures can help significantly in reducing race conditions in parallel code, as it is impossible for one thread to modify part of a data structure while another thread is accessing it. Each thread sees a consistent 'version' of the data structure until the code explicitly replaces it with a new version.
Immutability can also help with memory optimizations: A node of one data structure can be safely re-used in another data structure. For example, if you need to retain older versions of a tree, you can share common nodes (this is how GIT encodes version changes).
This is the canonical guide to reasoning about amortized runtimes. The exponentially growing ArrayBuffer (O(1) amortized append) is the classical data structure used to teach amortized runtimes, but the O(1) amortized functional queue Okasaki presents here gives a much better intuition for what amortized runtimes are all about.
Even open book exams can be gamed. There are whole industries set up around enabling in-exam communication (e.g. concealed subvocal mics/headphones) and outsourcing schoolwork.
It is definitely possible to design assessments on which cheating is difficult. For example, oral examinations or personalized per-student projects or exams. The problem is that this style of personalized assessment fundamentally does not scale past a few dozen students in a classroom.
You want a classroom that small, it's going to cost you. Just instructor salaries for would run each student 10-30k per year, and that's before paying for infrastructure (classrooms, tech, offices) and (admittedly not always useful) administration.
You are describing a different class of attacks. If the company owns the device, they should be free to (try to) lock it down all they want. OP is about Apple locking down devices that someone else ostensibly owns.
I'm not convinced that they need to. What threat model are you considering? In this case, the privilege that the user is granting the new hardware is the authority to unlock the phone.
Since the phone has to already be unlocked for this privilege to be granted, it can't be used to bypass authentication.
The hardware is already installed by this point, so if it's 'spying' it can do that. The user's choice has no impact on the hardware's ability to record and/or deliver information.
At best, the replacement hardware would be able to unlock the phone for the attacker at some later time. However, the cost of getting this customized unlocking device into the phone seems high given that the attacker needs physical access to the device to embed the hardware in the first place, and then again at a later time to get into the device.
There are simple ways to allow hardware changes without losing security. One straightforward idea: Once the phone is unlocked (e.g. by pin code) allow the user to authorize the new hardware.
This is effectively what Apple does already. The usual difficulties with asking users to make security choices don't really apply here: Physical changes to the hardware are requires, so security fatigue isn't as big a deal. Maybe you get some protection from wrench attacks by not having the authority to pair new internal hardware, but that seems like a very specialized use case...