Bah. You aren't driving, you're just riding in a box. You don't even need to own it -- you can just rent it for you trip.

We already have that. We call them "cabs".

And they're sometimes useful.

Which may be the way to sell this, more than "it's a car you don't have to drive!". Why bother? The *point* of owning a car is to drive it. Driving is *fun*.

(And if it isn't, please, please, please take the bus, train, or trolley. If you don't enjoy driving, you're not going to be paying attention, which, frankly, makes you part of the problem.)

The problem with driverless cars is not that they're going to be unsafe, but that they're basically useless. We HAVE means of transporting people so that they don't have to pay attention already.

And yet we still own cars. Why? Because they're _fun_. Who's going to drop US$50,000 on a car that they don't get to drive?

I would find Tesla's case a lot more convincing if they had something more than computer logs. Perhaps they should get some of the BBC employees who were there at the track that day to give sworn statements as to their perception of what happened.

(Not that human testimony is all that reliable, but corroboration with some other source would seem necessary.)

At the moment it's a he-said-she-said argument. The BEST approach would be for Tesla to offer a rematch, and to have a couple of Tesla-certified technicians on hand to diagnose any problems, lest some idiot jump to the wrong conclusion on account of some idiot light on the dashboard lighting up at an inopportune time.

After all, that's the scientific method, isn't it? When you have a dispute, run the test again, and verify the results.

Surely nobody objects to the scientific method *here*.

Actually, I by far prefer to have a deployment environment different from my development environment.

Some of the biggest causes of crappy applications (once you eliminate idiot developers and insane management, of course) are the assumptions we bring to the table. When your development environment differs from your deployed environment, you learn to identify and document the hidden dependencies of your application, which sucks in the short run but is a huge win in the long run.

Want to deploy to a RedHat linux box? Develop on a Mac, do the integration/systems testing on a Debian box, and then do the acceptance testing on a RedHat box. You'll expose hidden dependencies early on, and make explicit the assumptions you're making about the environment you expect to be in.

Which just makes the application that much better.

Why is there this assumption that an ISP will give out more than one (or five) IPv6 address(es) per account? (Especially in the US, where charging for SMS messages is acceptable, even though they're effectively zero-cost on the providers.)

Whining about how NAT breaks stuff like FTP misses an important point: FTP and friends are fundamentally broken. People who have invented protocols since the invention of NAT who adopted the FTP model are guilty of being egregiously stupid.

Logging into a firewall / NAT-box to open up a port through to a specific machine is not difficult. The advent of networked games showed us that it's well within the capabilities of non-technical people to properly configure their firewall/NAT systems to accomplish this.

NAT is a fact of life, like DHCP, and it isn't going away. IPv6 won't kill NAT, it won't kill DHCP, and it won't magically make poorly-designed VOIP systems work (better).

There's no particularly good reason for my network to look like more than one computer to anyone outside my network. There are very good reasons for one of my computers to look like several distinct computers within my network.

IPv6 won't change this. All it will do is (a) make me set up DNS for my local network, because it's not practical to try to remember an arbitrary IPv6 address, and (b) make me set up a subnet with a translation proxy, so my network-capable embedded devices and "legacy" computer systems can still use the network. We're still going to have NAT, we're still going to have DHCP, and very likely, we're still going to only have a small number of internet-accessible IP addresses.

We just won't be able to remember them.

Stop imagining them in their underwear.

I work with someone like that. He hits a lot of keys in a very short period of time... but almost half of them are the backspace key, because he almost never hits the key he wants to hit.

It sounds like he's getting a lot of work done. If you look over his shoulder, you might find out he's spent the past five minutes trying to scp his editor's configuration file from one machine to another.

You think C++ is more concise than Java?

It is to laugh.

Perl... now Perl isn't always terribly friendly on a touch-typist. But maybe that's just because I haven't mastered the opposite-hand-shift like I should.

A moderate typing speed suffices. Say, oh, 30wpm, or thereabouts?

If you're not typing at a reasonable speed, you're going to have an incentive to shorten variable and function/method names from something reasonable to something cryptic. You're going to avoid typing documentation, or worse, propose that your cryptic POS code is 'self documenting'. You're going to be an unpleasant partner if you end up pair-programming. All this means you're not only affecting /your/ productivity, but you're now negatively affecting the productivity of others -- all because you're too damn lazy to learn to type.

It's not really about raw speed. Typing should be an unconscious reflex... you want words and symbols to appear on the screen, and they should do so, without you having to think about it. That way you can think about the problem at hand, and not about the act of entering the code to solve the problem.