[amcgregor]

But not disk, flash, or RAM. And network transfers are not always compressed, say, if synchronizing with a WebDAV back-end with naive client software. (The vast majority of iOS WebDAV implementations suck badly in this regard.)

[scott_w]

I don't think disk, flash or RAM are huge concerns for anything but huge files, to be honest.

Client-server communication software can improve over time, or be replaced by better software. Picking a style based on technical limitations that will be superseded anyway is surely what you're arguing against?

As a more general point, using spaces instead of tabs can still be handled easily by IDEs. It's possible to recognise that something is supposed to be an "indent", and then space it according to what your preferences are. Whether any current IDEs do that, I don't know.

[amcgregor]

Disk, flash, or RAM are concerns any time you have many copies of the files. One large file or millions of small ones, it adds up either way!

I picked tab-based indentation because of the flexibility it gives me and anyone else reading the code. Savings elsewhere are icing on the cake.

IDEs can automate bad behaviour as well as good, and yet spaces remain intra-word separators and tabs remain the character designed for indentation and alignment.