>How do we know that the ruling/governing class is not abusing these monitoring systems and exempting themselves from monitoring?
Ah, so except for THE ENTIRE FUCKING PROBLEM, this is fine.
>And if some people are allowed to harass and stalk others based on some attribute (race, religion, nationality, etc.) because they are in a monitoring position (while others are not) then that would be unfair as well.
Yes, we wouldn't want racial profiling in our Orwellian hellscape. That would truly put it over the edge.
I did a lot of automation at my last job, which was closer to engineering in the classical sense than engineering in the software sense. The automation mostly amounted to web scraping and interacting with local systems, with a generous amount of logic in between. The largest roadblock wasn't the scraping or the logic, it was the inbuilt assumption of the local programs that there would be an ape with a mouse and keyboard driving the interaction. Outputs that could have been text needed to be copied to and read from the clipboard, or exported as a spreadsheet. Inputs that could have been text were only accepted in spreadsheet form. Pixels needed to be read from the screen to tell when one step was complete and the next could begin. Mouse clicks and keystrokes sent to and fro when it all could have been a series of commands. I cannot count how many written processes and procedures existed could have been a bash simple bash script.
I'm not arguing that these programs should not have a GUI, for that was the simplest way to use them, but the lack of command line functionality places a hard limit on the productivity of an organization, and ensures that the only progress on that front comes at the expensive of exceedingly limited developer time.
"But nobody knows how to use a terminal anymore," I hear you say. Well of course they don't, nobody under 35 without a background in programming has ever had cause to use one. We made everything so simple that nobody ever has to learn anything. That isn't to say that people cannot learn, just they have been robbed of the natural opportunity to do so. Otherwise intelligent people never progress beyond the manual step-by-step interaction that passes for "using a computer" today.
A computer is a tool in much the same way that the a machine shop is a tool: it is a tool that can build other tools. The role of software developers should not just be to build simple tools that can do one task in isolation, it should be to build tools that less technical people can use to build the tools they find themselves in need of. GUI-only programs are simply not fit for that purpose because they lack composability of simpler terminal-based programs.
The problem of offices is not when we spend time in them but rather that we spend time in them at all. What a banal hell it is we have consented to endure compared to the comforts of our homes or of any space actually designed for the wellness of human beings or even focused work.
If your key is a hash of the code and its dependencies, for a given toolchain and target, then any change to the code, its dependencies, the toolchain or target will result in a new key unique to that configuration. Though I am not familiar with these distributed caching systems so I could be overlooking something.
I hadn't heard of ATS before, and I think that I mistook your using it as an example of "more isn't always better" and thought you were suggesting it as an actual alternative.
I'm looking for the next thing I want to learn, and have been leaning towards logic programming and theorem provers, so you inadvertently piqued my interest.
Rust's real superpower is its tooling. Cargo handles package management, building, testing, documentation, and publishing. The compiler's errors explain what went wrong and where it happened. Installing the toolchain with rustup is quick and painless, even on Windows. I can't know that it's best in class, but it's certainly the best I've used.
I can see another language having a more expressive type system, I've come up against the limitations of Rust's type system more than once, but the tradeoff isn't worth it if I have to go 20 years back in time in terms of tooling.
That C++ already has many implementations of sparse sets seems to be a point in favor of sparse sets rather than a point against Rust, especially given that C++ doesn't need them the same way Rust does.
When I say they prioritize social stability, I mean that they won't stop producing cars regardless of how little economic sense it makes because they need to keep people employed to stave of massive civil unrest. And global competitiveness counts for little when the countries they want to export to implement anti-dumping policies to protect their own industries from government-subsidized Chinese exports.
We must be working from different definitions of efficient.
Yes, the CCP can say jump and expect their corporations to do so, but when everyone in a modern economy jumps at the same time, massive oversupply is the result. More market-based economies are also prone to similar overproduction when everyone gets caught up in the same mania (see AI datacenters), but investors will eventually stop lighting their money on fire when it becomes clear that the returns aren't there. Chinese companies, on the other hand, will just keep jumping until the CCP decides that they are done jumping.
Our feedback loop is geared towards only doing things that provide a return on investment. Their feedback loop has things like social stability and global competitiveness as competing goals to actually doing productive work.
Yes, they are able to accomplish a tremendous amount when they set their minds to it, but doing a tremendous amount more of something than there is actual demand is waste, the opposite of efficiency.
I came across this guy's channel the other day and it was an immediate subscribe.