In 5 years, self-driving cars will be another 5 years away from being available to consumers. In 10 years, self-driving cars will still be another 5 years away from being available to consumers. And so on.

Not better than human drivers. They're still significantly slower, or running on closed courses, or on pre-mapped city streets with a human behind the wheel.

The technology to make computers navigate the real world and its hazards as well (and as fast) as humans is still years off - and may remain that way.

Given enough time to adapt- the whole country could be computer-driver only.

Only if computer drivers get intelligent enough to understand what to do when a deer crosses the highway in the middle of the night. Or when a child's ball comes bouncing into the street. Or when there's a giant pothole in the traffic lane.

Computers are excellent in controlled situations when it knows all the variables. But real life is a messy place full of surprises and unknowns that computers have long been ill-equipped to handle. So like the mythical flying car, I don't expect to see computer driven cars in my lifetime simply because human brains adapt better at handling the unexpected.

The Twin Cities light rail system is entirely above ground.

The trouble is that uploading gigs of data can take hours, depending on one's connection speed. So once Google gets bored with this service and kills it, one will have to spend that time re-uploading it to a less flighty service provider.

You still seem to fail to understand my point that you should not need a special editor to help you correctly understand what the code is doing.

The code is doing exactly what the source code tells it to do. If you're having trouble reading what's in your source code - especially source code from someone else - there's plenty of tools available to make that job easier. If your editor made periods and commas look the same, it'd be hard to write C code and it'd be smart to switch. If your editor makes tabs and spaces look the same, it's hard to write Python code and you'd be smart to switch.

It doesn't require a "super-duper IDE". But by sticking to something sub-optimal, you're making it harder than it needs to be.

Python doesn't care whether you're using tabs or spaces, so long as you use a consistent amount of it to denote blocks. The problem is that some editors don't show you the difference. Nobody complains about semicolon requirements in C code because an editor shows you where all the semicolons are in a given piece of code. I feel whitespace should be just as easy to follow. If someone's indented a block wrong or mixed in some tabs, that should be just as easy to spot - even if you're using a language without any whitespace restrictions at all.

My solution is to use ethan-wspace which automatically highlights tabs in source code (along with lots of other little whitespace problems) and lets me clean them up trivially with the touch of a button and without breaking the file. It not only keeps my Python code functioning, but does wonders for keeping junk whitespaces changes out of source control.

% pep8 file.py

will tell you all the line numbers where someone's mixed tabs and spaces. Or use M-x whitespace-mode (or your editor's equivalent) and clean them up yourself in whatever consistent style you'd prefer.

Python's design has plenty of annoyances, but its whitespace-based syntax is the among least of them.

Six months from now, long after I've moved on to something completely different, am I going to remember a function's return values? The inner workings of a particularly complex algorithm? Or the reasoning while a special case has to be handled differently?

If it's not going to be obvious to myself later on, it's worth adding a concise comment to explain.