Even if would take your explanation, what kind of mindset would shorten "this lousy excuse for a science" to "science"?

> On the other hand, the entire Heartland anti-AGW fund is smaller than the one bribe, er, "grant" paid to one NASA administrator, and a tiny drop in the bucket compared to the various government pro-AGW propaganda expenditures.

Taking into account the amount of factual results produce, I would say, the Heartland Institute receives a disproportionate amount of money.

Science, it works in the sense, that for example, that it allows us to produce rockets, which got us to the moon.
If the Heartland Institute produces something similar, then I would consider it putting it in the same league as a single NASA administrator.

Renaming is O(filename), usually a single table entry. Deleting is probably more along the lines of O(filesize).
You have to keep track of the free blocks, too.

With the same application mix, an even distribution of load is not a good sign: You have to wake the sleeping CPUs more often, so they can't switch them to a deeper sleep mode, and probably, the scheduler is switching the threads between processors, which means more cache misses.

So, the load graph alone is not a good indicator. Of course, that doesn't make your observation any less valid.

Exactly for that reason, proving is done by deductive reasoning, not by testing.
You are working on a different abstraction level.

For proving, the number of variables or configurations are not a sensible measure of complexity.
There are seemingly simple equations, which haven't been proven for decades or even centuries,
and there are equations with an infinite number of scalars, which can take an infinite number of values,
which are well understood and proven from several different angles and used by undergrad students every day.

The same way it doesn't "take 100 years to" write code, which takes "every possible code path and input" in account,
it doesn't take it to verify it. Discovering an algorithm might take 100 years, but not writing the code.
Those are separate problems and usually one does the first, not the latter. Especially not in the cited case.

Writing correct code is about implementing an algorithm, which already considers "every possible code path and input"
and implementing it correctly. Software verification is purely checking, whether the written code matches the algorithm
is tedious and time-consuming and error prone in itself, but only takes a simple factor more time, which it took to write the code.
Automated verification is a totally different beast, because there is provably no algorithm for it.

To my understanding, that is the quintessence of the Gödel incompleteness theorems:
There are things, which are intractable for automated systems, which aren't for humans.

The size of the "solution space" is mainly important for testing, which seemed to have failed in the cited case.

> Most problems in automatic verification are either undecidable, or intractable.

Who was speaking of automatic verification?

Some things may be over-engineered. But in my experience, more often it is the case, that people rather re-invent the wheel,
than they bother to try to understand, what someone else has done, and how it is supposed to work.
And over time, it will bite. Usually not the one who wrote the code, because that person is gone, but the project in whole.
And no, I don't see a difference in "own code" and foreign libraries, from a "long" term perspective, it is the same.

> I don't see any reason, why the version would have to change in the middle of a file in any case.

It is probably not due to the fact, that the version might change in the middle of the file, but in case, you only have a part of the file.
This makes it more robust, and better suitable for streaming: You can simply start sending from an arbitrary position, and the parser should
be able to recover at some point.

Not really. Event driven programming is more about decoupling caller and callee than responsiveness. So, instead of calling the handler directly by function call it either get
routed through a message loop, or is fired over a delegate. Just try to handle a complex function in such a handler, and look how responsive the GUI remains. It will become dead.
Yes, you can work around it, by loading of the code to OnIdle or Timer event, but that is essentially a poor-man's multi-threading, as now you have to break down
your code in smaller interrupt-able chunks yourself. Hence, the standard approach suggested in API documentation is: Use a worker thread.

Yes, you are right, why doesn't the porn industry get the same subventions as the crop industry.
How dares the executive to set priorities, instead of spreading the money equally amongst men.

Maybe equal protection has nothing to do with it?