The OP implicitly raises the question of why does "productivity" exist. I've been giving that some thought lately, and the hypothesis I arrived at was that of diminishing suffering.
Many types of performance optimization work, including "programmer productivity" are really the engineer's getaway from having to contend with the ambiguity of the problem domain, the politics, the vagueness, the risk of failure and other kinds of suffering.
Alas, solving a problem coming from the world requires confronting the world - a couple of examples are the tedium of mentally working through a user workflow, getting somebody else to cooperate by articulating and proposing a joint strategy and more.
I do not believe in pain for pain's sake, but good delivery has an inherent quality of athleticism, and one cannot be an athlete without accepting that training for the track means proficiency at managing pain - and at the track rather than elsewhere.
I wonder what is the contextualization of the OP's preference of the "Palantir as a data/power broker" narrative to that of "Palantir as a highly profitable staffing agency".
Re the "Manhattan project in 1944" argument - I am very cautious about the "modulo engineering scaling" carve-out -- unlike the uranium manufacturing pipeline of World War 2, that involved massively scaling up a known process, on the face of it there's no uncontroversial process/architecture to scale up in this case.
On the face of it, even relatively "point-target" goals of this kind could take many decades if at all; GaN for blue diodes come in mind as an example of a field that was stuck for a generation -- until it wasn't.
> I am very cautious about the "modulo engineering scaling" carve-out
As OP said elsewhere[0, 1]:
> Once you understand quantum fault-tolerance, asking “so when are you going to factor 35 with Shor’s algorithm?” becomes sort of like asking the Manhattan Project physicists in 1943, “so when are you going to produce at least a small nuclear explosion?”
In other words (IIUC): Some problems (here: scaling fault tolerance) seem to be easier than others.
Is the question at hand about balancing local building authorization with the government's intent to encourage a specific kind of national infrastructure businesses?
This seems to be supported by this quote:
> Putting arbitrary deadlines on state, local, and Tribal governments to start and finish complicated permit reviews...
I'm not an American but I am alarmed at the recent tendency for bad-faith rule making. However - the above sounds in reasonably good faith - is that indeed the case or am I missing some angle?
No big business in the US acts in good faith so the fact they are cheering this on tells me to be suspect. My read of this is they want to juice returns / timelines by avoiding bureaucracy and the city / local residents will deal with the inevitable mess.
From my perspective depending on where they want to develop it might be trivial to add something time consuming to a proposal such as eminent domain or easement reviews that will run out the shot clock and drown out reasonable questions by local governments. Local governance often is complicated by local (town), regional (county), and state level roles. Additionally depending on the area not all of these roles are even staffed by people working on it full-time.
There's correlation all right, but is there causation?
A lot of folks I know regard mechanical watches as a type of jewelry, a high value item that's not intended for the everyday.
I concur that that popularity of mechanical watches is on the rise, but having a cool mechanical piece on in the evening does not preclude having a digital watch at all other times.
I find merit with the core point as well the delivery.
I wish it was more commonly accepted that choosing not to act is effectively a stand against one's own value system in favor of the value systems of those who do act.
I think Python's centrality is a consequence of its original purpose as a language intended for instruction.
Yeah, some of its design decisions required immense cost and time to overcome to make for viable production solutions. However as it turns out, however suboptimal it is a language, this is quite made up by the presence of a huge workforce that's decently qualified to wield it.
Python original purpose was as a scripting language for Amoeba. Yes, it was strongly influenced by ABC, an introduction programming language which van Rossum helped implement, but that was a different language.
""I was working in the Amoeba distributed operating system group at CWI. We needed a better way to do system administration than by writing either C programs or Bourne shell scripts, since Amoeba had its own system call interface which wasn't easily accessible from the Bourne shell. My experience with error handling in Amoeba made me acutely aware of the importance of exceptions as a programming language feature.
It occurred to me that a scripting language with a syntax like ABC but with access to the Amoeba system calls would fill the need."""
To the extent a random person's evidence on the Internet amounts to proof:
From people at Facebook circa 2018, I know that end user privacy was addressed at multiple checkpoints -- onboarding, the UI of all systems that could theoretically access PII, war stories about senior people being fired due to them marginally misunderstanding the policy, etc.
Note that these friends did not belong to WhatsApp, which was at that time a rather separate suborg.
Many types of performance optimization work, including "programmer productivity" are really the engineer's getaway from having to contend with the ambiguity of the problem domain, the politics, the vagueness, the risk of failure and other kinds of suffering.
Alas, solving a problem coming from the world requires confronting the world - a couple of examples are the tedium of mentally working through a user workflow, getting somebody else to cooperate by articulating and proposing a joint strategy and more.
I do not believe in pain for pain's sake, but good delivery has an inherent quality of athleticism, and one cannot be an athlete without accepting that training for the track means proficiency at managing pain - and at the track rather than elsewhere.