To give a data point, in 2021-era C++ it's approximately 3 years with a very large part of it being done by a single person (https://github.com/SerenityOS/serenity). How long would that take with python ?
That almost sounds like confusing goals with ways to me. Unless those very specific ways are your goal for some reason, if you were to "build a decent and snappy GUI operating system from scratch", you probably wouldn't end up with those things in it. You'd end up with something more similar to Oberon, Smalltalk, or VPRI's system (was it Frank or something like that?).
But I thought it was supposed to be "decent and snappy"? This requirement seems to ruin it quite a bit since 80% or so of your snappiness goes away.
I am talking about implementing a web browser. Writing a program that can load www.example.com and displays it, in at most a few milliseconds. Of course loading a bloated website will be bloated but that's because websites use a turing-complete language - if my web page has <script>while(true);</script> of course things won't go fast, but it doesn't matter, what matters is that we write an engine that is able to execute that "while(true)" and burns those CPU cycles as fast as possible (because then a "normal" website won't be much slower than the theoretical best it can do).
It's a (semi)well-defined problem: how fast can you do network requests, how fast can you parse the DOM, can you fetch content such as images concurrently, how fast can you execute JS, which is all benchmarkable. It does not matter than it's going to be slow when loading www.facebook.com ; what matters is that it isn't slower than it should be.
That's like writing a generic sort function: you care about the performance of the sort algorithm ; of course if people use a sorting predicate which does filesystem access for them it won't be fast but it is also utterly irrelevant to measuring how fast your sort is.
(These days no OS is going to succeed with end users if it doesn’t have a browser).
Why would that be interesting? They'd exist and consume the same amount of energy regardless of what they worked on...
But that said, the overhead of the engineers energy consumption is overhead that probably turns to nothing over the life of a successful project.
I really don't understand. They'd just work somewhere else and consume energy, housing and food. There'd be literally no difference.
I conceded, this is a convincing point.
To flush out the argument though, it was coming from the perspective of the system consisting of the firm+employees delivering a project rather than the system of the entire earth. I don't think the smaller scope overcomes the overall point, but you could perhaps see where there might be some merit to the distinction. It is just that that distinction doesn't really matter.
Theoretically, if you have fewer employees required to complete a project, then that project might use less energy. And if this holds true across the industry, then those non-employees _could_ be doing something more green. But equally they could doing something worse. And in practice for software, they would just be working on a different project or shipping more features or whatever, so it doesn't change the steady-state, even if a distinct project is delivered with lower energy cost. Even if all projects are more human-energy-efficient.
If two different implementations use the same amount of compute, but one took 10 times longer to design and ship, then it is a less efficient solution, no?
Those people (and their energy usage) could have been working towards solving some other problem or doing something else worthwhile.