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.

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.

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.

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.

Hard sectored or soft sectored?

It would be best to decide up front before putting in the order for 80 million disks.

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).

See: Obamacare.

Yeah, that would be better handled by outfits like AIG and Lehman Brothers.

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!

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.

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.

It's for the same reason that the murder rate inside Disney World is very low.

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.

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 .... return statements. If you put each case in a function you still have the following problems:
- 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.

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".

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.