Near the end: "If mankind had to choose between a warmer or a cooler climate, humans, most other animals and, after adjustment, most plants would be better off with higher temperatures. Not all animals or plants would prosper under these conditions; many are adapted to the current weather and might have difficulty making the transition. Society might wish to help natural systems and various species adapt to warmer temperatures (or cooler, should that occur). Whether the climate will warm is far from certain; that it will change is unquestionable."

Besides, that is a solution for the symptom, not the disease.

Much simpler to solve at the source (whatever actions are directly causing the damage) than the falacy of thinking we understand and have accounted for every possible permutation of events that will cascade after dumping material A into resource B. We don't even know what we don't know but this is the end game and mistakes here don't get do overs.

The next step in your logic is our 'traditional' response at this point: drop in another chemical/process that is supposed to 'fix' whatever mess up we did before. Haven't we learned from that yet, Deepwater Horizon was just the most recent example.

I get the point about unintended consequences with cascading problems (and cascading solutions to the new problems) (https://news.ycombinator.com/item?id=2743879) but the odds of screwing up here are much less than screwing up on AGI, whose work has already significantly started and may be completed first anyway making this whole discussion moot. Geoengineering is risky, but it's not as risky as other things, including inaction, which as the status quo guarantees loss of thousands of lives. Even if the climate change alarmists' greatest fears come true we still easily have 50 years to try things on smaller scales before time is up. Anyway I think it's a lot more feasible for a strong nation to lead a technological solution than to convince all strong nations to curb their development. Call it a plan B if you must, but at some point I expect climate change alarmists are going to say something like "China and Russia and India aren't playing ball hard enough, their emissions are still causing global warming that will end humanity in x years unless they immediately reduce to the levels of the USA and the EU whose combined efforts bought us y years but it's still not enough, so it's time for war to make them."

Types allow the compiler to do a lot of validation before your code is even executed, removing whole classes of bugs before they even have a chance to manifest themselves. You thought that value was an int and divided it by two? It was a string. I'm glad I didn't have to wait until runtime to find out about it, or to write tests to make sure that every single code path to that division results in the value being, in fact, an int.

Types allow developers to trust whatever data they receive without feeling the need to protect against hostile, or less experienced, application programmers passing incorrect data. They allow you to know, with absolute certainty, that what you wrote can only be executed the way you meant it to be executed (whether that's correct or not is another question altogether). A function in a dynamic language is never complete, you never know what data, or shape of data, you will receive. Types buy you that certainty.

Code efficiency is not the point - developer efficiency is. When you can trust your data, you can focus on what your code needs to do - that's usually complicated enough without adding the complexity of not being able to trust a single value.

The main argument against static languages is that, in their struggle to be sound, they end up not being complete - and it's absolutely true: there are perfectly legal programs that you can't write with a static language, but that a dynamic one would run without batting an eyelash. Duck-typing comes to mind, I'm sure there are other examples.

Another argument is that type systems get in the way of what you want to do. There are a few cases where it's true - see the point just above. But in my entirely anecdotal experience, the vast majority of times someone complains the compiler won't let him do what he wants, it's because what he wants to do is not correct. The complaint is not that the compiler is too restrictive - it's that your bugs are shoved in your face much, much more frequently and quickly than they would if you had to wait for runtime. And that's a good thing.

If "Foo" is just dynamic data, perhaps in a map, composed of other data, and it's values all the way down, any of those three points of time are easy ways to look at "Foo" and can generally be faster than reading a JavaDoc page or ctrl+spacing figuring out what you have access to and what it all means and what you want to do with the data and code associated with "Foo". Since you're going to be looking at the thing you want anyway, I find it very uncommon in practice that I accidentally divide a string by 2. Static typing would let me know before I run the thing that I was an idiot (maybe, see next paragraph), but I'll find out almost as quickly when the code I just worked on (either in the REPL, which is very nice, but even from the starting state) actually does what I want -- you do that regardless of static/dynamic typing, right? You don't just write code and never verify it does what you want, trusting that it compiled is good enough? Anyway when I run it, I'll immediately hit a runtime error (which can be handled in Lisp in ways way more flexible than exceptions in other languages) and realize my stupidity. So I don't find that particular situation or class of bugs very compelling.

Nor do the presence of declared types alone guarantee my safety -- I need to know about any conversion rules, too, that may let a String be converted to an int for division purposes, or if there is operator overloading that could be in play. Conversion rules and operator overloading are interesting regardless of the static/dynamic typing situation because too much or too few can lead to annoyances and bugs. Java lets you concatenate ints into strings with "+", Python doesn't, but Python lets you duplicate strings with "*".

What I have run into in both static and dynamic languages is division-by-zero errors, which, unless you go all the way to something like Shen that supports dependent typing, your type system with "int" declarations will not help you with. I've run into errors (in both static and dynamic languages) parsing string contents to extract bits of data. I've run into errors around the timings of async operations. I've run into null pointer exceptions (though much less frequently in dynamic languages, maybe once the Option type is in wider use I can rely on that too but its issue is poisoning the AST). I've run into logic errors where I thought the system should be in state C but instead it transitioned to state E. The bugs that take the longest to diagnose and fix are simply due to not understanding the problem well enough and having an incorrect routine coded, so I have to figure out if it's a logic error or an off-by-one error or simply using the wrong function because it had a suggestive name and I didn't read through the doc all the way. Rich made an interesting point in one of his talks that all bugs have both passed your type checker (if you have one) and your test suite. My point is that I'm not convinced static typing as I'm given in the languages I work in is worth it for any reasons beyond performance because I don't see any other improvements like making me more productive or writing less bugs. I'm not opposed to types and schemas themselves in general, just static typing. I'd rather see pushes towards full dependent typing and systems like TLA+ (which has seen more industry usage than Haskell) and Coq than things like core.typed in Clojure.

The last point I'd raise is that I agree with you developer efficiency is more important than code efficiency. But this has been one of the mainstay arguments from the pro dynamic typing camp for many decades, with static typing advocates conceding that yes the developer will be more productive in a dynamic language but the performance is terrible for anything serious. If you want to argue static typing was actually more efficient all along from a developer perspective than dynamic typing, you have a lot of work to do. I'm not particularly interested in that argument (at least today) but the point still needs to be raised.

With some cleverness, I was able to get C's type checker to let me know when I was accessing data from the wrong thread. This was tremendously useful when moving functionality between threads. If you think type checking doesn't buy you much, it's because you don't know how to use it.

Greater than any technological or Presidential initiative challenge is the challenge of culture and media. Human lives matter a whole lot more now than they did during the Apollo missions, and a disaster resulting in the deaths of astronauts is the worst thing that can happen to NASA. As long as it is subject to public scrutiny and criticism that affects its budget and goals, it will continue in the fashion of the medical industry -- accepting all the consequences of do-nothing neglect instead of doing something that carries the risk of the deaths of a few individuals. In the medical industry, hundreds of deaths some of which could have been averted with not-yet-FDA-approved surgeries or drugs; in the space industry, the always looming threat of an extinction-level asteroid or other existential threats.