BlogArchive

It only took 3 weeks, but here's the Halloween setup write up and accompanying pics.  It was a fun year. Kids got scared. Parents thought it was cool. Beer was drunk. I had a ball.

You can look at other write ups too.

On October 11th I was at Ohio Linuxfest with my friends from NOOSS. We were there with our webcasting and recording equipment. While there we met some interesting people and recorded interviews with them. So, here they are:

Dual Core - Nerd core rappers.

Moose and Peter Salus - Moose of OpenAFS and Peter Salus the technology historian.

Roland Hess - Roland Hess on Blender.

Every time we, my(hopefully not so) small circle of friends, start down the discussion of tabs vs spaces one guy pastes in JWZ's "Tabs versus Spaces" article. Naturally, I always go read it again to see how it applies to the current incarnation of the discussion. The problem was I could never fully wrap my head around it. I think I finally figured out why.

I'll attempt to summarize his article here. He makes these three points on the 3 different definitions involved in a "Tabs vs. Spaces" argument:

1. When reading code, and when they're done writing new code, they care about how many screen columns by which the code tends to indent when a new scope (or sexpr, or whatever) opens.
2. When there is some random file on disk that contains ASCII byte #9, the TAB character, they care about how their software reacts to that byte, display-wise.
3. When writing code, they care about what happens when they press the TAB key on their keyboard.

He then goes on to explain points #2 and #3 and how different editors process the characters and the key and then says:

So, the real religious war here is point #1.

Points #2 and #3 are technical issues about interoperability.

Ok. So far I completely agree and fully understand what he is saying. Indeed, how the code is indented is absolutely a religious issue. But, here's the paragraph where my brain kept blowing up:

My opinion is that the best way to solve the technical issues is to mandate that the ASCII #9 TAB character never appear in disk files: program your editor to expand TABs to an appropriate number of spaces before writing the lines to disk. That simplifies matters greatly, by separating the technical issues of #2 and #3 from the religious issue of #1.

It finally occurred to me why. Because the reality of this situation is not that you're separating the religion from the tech, but rather, you're forcing your religion on others!

Ok. What do I mean by that? Well, lets say that I am one who believes that there should be 4 screen columns between changes in code scope (ie. indenting a new block). Now, say I follow JWZ's advice and untabify. Then you load up the code, except you believe there should be 2 screen columns for a block indent. Now, I have just completely forced my belief of 4 columns for indent on one who believes in 2.

So you see that instead of separating the religious issue, you're forcing it.

To help this, I make a modest proposal of my own. That is, we define TAB characters (in whatever encoding you happen to be using) at the beginning of a line (that is, following a newline character) to be always defined as "perform a single level of indent". If we all follow this definition then and we all listen to JWZ's advice on the fact that issues #2 and #3 become technical issue that are solved via editor configuration, then we have truly removed the religious issues involved in Tabs vs. Spaces. Everyone can set their editor to display the TAB character at the beginning of the line to show the proper number of columns as required by their deity and everyone can make their TAB plastic keyboard bump behave so as to write the tabs at the beginning of the line.

And finally, all coders exist in utopia.. .