teek

Don't forget we're also comparing to HSR. On a train you can go to the toilet anytime you want.

> To attack your specific example, why do you assume the cars will drive around passenger-less, and not merely continually make productive uses of themselves, such as by delivering other packages or acting as deliverymen for physical goods?

Because they won't most of the time? Let's say that during peak rush hour, N people + M packages need to be transported. That means that in order to satisfy peak demand efficiently, we need N+M cars and road capacity. During off-peak hours, lets say that only 20% of the population needs to travel. That means you've got the other 80% of the cars sitting around doing nothing just like they are today. If the average distance to nearby parking is say 2 miles, then we have 80% of the cars just driving empty 2 extra miles to prevent themselves from taking up road capacity (while today we trade off by creating parking lots).

Despite that, I do think there will be some improvement in terms of car use. Namely:

* the average car size will shrink to probably that of a smart car (2 seats, little cargo room) * parking lots will shrink (but not disappear) due to effective stacked parking * vehicle efficiency will increase (human drivers are inherently bad at maintaining fuel/energy efficiency with acceleration/deceleration)

The danger is that this once again will make car use "cheap" and like the article suggests, extends sprawl yet again. So we'll just have another half a century of poor land use just it might be slightly more efficient this time around.

My general rule:

If you are planning on some sort of reuse (API, library, protocol, etc) a test spec is a very good idea if only to hash out practical use of the interface and identify caveats in the interface spec. Once released, the test spec is great for answering the question "did I accidentally break something that used to work?" thus vastly speeding up the bug-fix process for underlying components or widely used components.

If you are writing an end-user app, or a service that will be used non-programmatically (such as a GUI or web app), then a test spec is not required and probably a waste of time as things will likely change too quickly.

If you want music to be stored on the device, you can tell Google Music or Amazon MP3 to keep the copies on the device. This is accessible by long pressing a song or album and then selecting "keep on device". Alternatively in Google Music there's a menu to select multiple songs/albums.

> The Google-supported way is for me to put MP3s in a folder? Really?

That's the 'over the wire' method. I think that's how it should work seeing as how with iOS you need iTunes in order to do it. And then iTunes has a bunch of non-sense about how certain things can/can't be copied because of drm or however iTunes and that particular iDevice feels that day. As for once the files are in the Android file system, the content manager automatically indexes the files so in Google Music or Amazon MP3, the songs are not arranged by file name, but by album, song title, genre, etc.

> I have to do it via slow-ass WiFi and a third-party program like doubletwist? Total disaster.

The problem here is you've been conditioned to think that wifi is slow, and iTunes is superior. It isn't. When I download an album from the "cloud", I don't sit there waiting for it to finish. I get in my car and go, or I walk to wherever I need to be. The device does it wirelessly and because it is wireless, I don't care about sitting there waiting for it to finish. You're stuck in the iTunes mentality where there's a physical cable attached and you do have to sit there and wait.

It works in OSX Lion so your comment is a little misleading.

I do however think the Google transfer app is somewhat annoying as it tends to popup every time I connect my device to my computer.

$(".post").css("background-color","inherit").css("border",0);

In some languages like perl, there's a named parameter form that's becoming more common. If I were to rewrite the example in perl, it would look like this:

  ellipse(x=>60, y=>50, height=>50, width=>100);

Yes, it is more typing, but you don't need fancy auto-complete to give you hints when reading.

There's also nothing from stopping us from making a "training wheels" interface in javascript:

  draw-ellipse({x:60, y:50, height:50, width:100});

  function draw-ellipse(o) {
    ellipse(o.x, o.y, o.height, o.width);
  }

I wouldn't mind a low-height cubicle farm. That is nobody can see each other if everyone is sitting down, if you stand up you can see people without getting on your toes.

I would also arrange the cubicles such that your back is never to the entrance. So you know when someone is walking into your space.