Please keep reading past just the first five words of my original post and then try again.
A. Probably not. I'll bet that cave men burned coal or bitumen when they could find it.
B. Hydro power is not "green" at all. Most dams are small ecological disasters.
I said grubbing it and burning it.
If you were trying to make any kind of demonstration of reading comprehension, that wasn't it.
Make all the apples-to-monster-trucks comparisons you want
And you can make all the false choice assertions you want. It doesn't mean that we can't work to pull ourselves out of the dark ages and stop burning dirt and spewing its byproducts into the air.
if you, personally, aren't limiting your own electricity use, not only are you not serious about the environment, you don't have a leg to stand on when it comes to telling other people how they should be getting their power.
I have been limiting my use. So it looks like I'm justified in telling you that you ought to be working towards getting a better source of power, not just spouting off about the status quo being inevitable.
If you want to volunteer to go back to the dark ages yourself, go right ahead.
Grubbing dirt out of the ground and burning it is a "dark ages" thing.
On the bright side, my math indicates that 8e13 paper chads would take up about 20 thousand cubic meters of space. That would probably be enough free fuel to heat your home for a lifetime.
Neither, 8" floppies would be the way to go.
Hard sectored or soft sectored?
It would be best to decide up front before putting in the order for 80 million disks.
Just think how much you could save for yourself if you could keep 67% of your Federal income tax - and all your SSI/FICA payments - over the course of working 35-40 years... And that savings would survive to your estate/inheritors, not just disappear like SSI does, once you die.
Only if one of the financial crises that happens every couple of decades doesn't wipe you out.
The main problems are:
A: Most people don't save money without being forced.
B: Most people don't know how to invest.
C: Even if you know how to invest, you can still lose your shirt.
D: Irrespective of the above intractable problems, saving money and investments means nothing more than shifting bit patterns on some hard drives. It doesn't in any way solve the problem of supporting an millions of idle and ailing retirees over ever-expanding lifetimes. Any saved "assets" will get devalued in the markets to reflect that reality.
So your scenario does not do anything at all to address the problem of what to do with retirees in the real world, other than let a good fraction of them die in a gutter.
If the government is going to force me to spend money, I'd just as soon have them handle it directly, instead of making me hand it over to be skimmed by profiteering middlemen. (Who will probably eventually need to be bailed out with taxpayer money anyway).
For retirement, the government has a needed roll in setting standards for "safety net" investment choices, and in insuring people actually do save, but they don't need to handle the money.
Yeah, that would be better handled by outfits like AIG and Lehman Brothers.
Charity is great, and we should all be compassionate, and again the government has a needed role in setting standards, but they don't need to handle the money.
Just imagine how much junk mail it would take to raise enough charity funds to replace every government assistance program. The USPS would be profitable again after only a few days!
Here's one refactoring for the situation you describe, that results in more even benefits than just removing the gotos/returns:
By adding extra useless variables, as I originally pointed out. And introducing a sea of "&&"s. I guess at least it looks more like a bowl of pretzels than a dish of spaghetti.
Whilst they result in execution stopping at a line in the middle of a block, they do so using an explicit built into the language block structure, that defines exactly which section of code may do so.
In a language like C++, unless there's a "try" block within the function, they are exactly the same as a "return" as far as that function is concerned, and can be invoked from the same places. I don't see why you think that that's acceptable if return isn't.
If you look at the FAQs for the Go language, the designers explain why they think exceptions suck in general, and why they largely replaced them with multiple return values. So not everyone shares your enthusiasm for exceptions, which are really just a kind of "return" statement on steroids.
Then explain the lack of similar quantities of malware for iOS between 2007 and 2012?
It's for the same reason that the murder rate inside Disney World is very low.
1. "nested brackets" (blocks) are by definition not spaghetti.
I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.
Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.
Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if
- If you do it the obvious way, you still need a deeply nested if-then chain. You haven't solved the problem.
- If you put each check within a function and daisy-chain them, you get creepy action-at-a-distance. It's not clear to the reader that you made a whole bunch of functions that should only be called from one place, and that they must be daisy chained.
I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.
You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox), then plenty of people would argue with it in 2014.
The main problem with early exits is using them in C. But C is such an unsafe language in general, that's really the least of your worries. Other languages provide nice features like automatic destructors and "with" statements that make early exits perfectly reasonable.
Yeah, force people to write a big pile of nested bracket spaghetti and manually back their way out of every case. Make them introduce a bunch of otherwise useless flag variables and extra conditional statements to keep track of it all.
The best part of it all: When all that extra obfuscation causes bugs, it would be harder to pin the root cause on a simplistic generalization like "goto === bad".
Bucket sort to keep each individual stack small enough for the following insertion sort.
I think that's what people generally do: Bucket sort anything more than a couple dozen items, and insertion sort anything less.
I've tried various other sorting algorithms on decks of cards just for educational purposes. I've found them to be mostly very hard for humans to perform. I think that's probably because what's usually kept in a computer's stack is not evident in the layout of items, so all that info must be juggled in your head. I think that I remember heapsort being especially hard to keep track of, and that quicksort was no picnic, either.