1 files changed, 160 insertions, 0 deletions
diff --git a/content/weblog/2020-10-11_the-indentation-red-pill/index.md b/content/weblog/2020-10-11_the-indentation-red-pill/index.md
new file mode 100644
index 0000000..d4c2b46
--- /dev/null
+++ b/content/weblog/2020-10-11_the-indentation-red-pill/index.md
@@ -0,0 +1,160 @@
++++
+title = "The indentation Red Pill"
+date = 2020-10-11T13:20:52Z
++++
+
+For the last several years I had been using spaces for indentation. I had
+decided to settle upon that method of indentation without much thought, just
+based on what I observed was the most popular choice. Well, that, and also the
+fact that I was writing mostly Python back then, which greatly influenced my
+decision. Recently however, I decided to switch to using tabs - at least for my
+own projects - and I am going to layout here the reasons why I concluded tabs to
+be The Superior indentation method.
+
+<!-- more -->
+
+I must first mention that the thing that made me question why I used the method
+of indentation that I used was a neat language that I have been recently
+studying - Go. One of the virtues (albeit with its set of downsides) of the Go
+language, is that it is quite opinionated, and one of this areas is code
+formatting, which by definition includes indentation. And the Go way of
+indenting is: tabs.
+
+Now mind you, the way they did it allows you to continue using your preferred
+indentation method while at the same outputting correctly formatted code as per
+the standard with a neat little tool called `gofmt`. But that is another topic
+for another day.
+
+Finding out that tabs is the standard way of writing (or at least publishing)
+code in Go surprised me a little bit. After all, if we judge by the amount of
+projects in public repositories that use spaces, vs those that use tabs for
+indentation, then spaces is the clear winner here. I was still curious, though,
+as to why tabs was chosen as the standard for indentation for Go, and so I began
+a quest to find an answer on the Internet.
+
+Alas, I did not find any concrete answer on the Internet from any of the people
+who worked on or designed the Go language. I did find myself reading a lot of
+arguments for and against each of the indentation methods on the Internet, which
+made me actually evaluate whether my choice of indentation was the better one.
+After all, this is one the of the oldest holy wars among programmers, that might
+even predate the Internet (or at least the Web).
+
+## Spaces
+
+The main arguments for and against that I could think of, and that I gathered
+from other people on the Internet are as follows:
+
+### Pros
+
+* More consistency in how the code is presented in different text editors and
+  environments. Mind you, after some thinking, I no longer believe this to be
+  really a pro, and could be even considered to be a con for reasons I'll
+  mention later in this text.
+* More people and projects use this. Not a very strong argument, considering
+  that it is an _argumentum ad populum_.
+* Because of different settings on different editors, alignment with tabs might
+  look off in some of those environments affecting readability. Now this is the
+  strongest pro that I could think of, however, it applies more _alignment_,
+  rather than _indentation_. More on that later.
+
+### Cons
+
+* Spaces - unless you or your team are masochists using one-space indentation -
+  use more disk space than tabs. If you are using 4 spaces for indentation,
+  arguably the most commonly used amount, then you are using at least 3 more
+  bytes per line than if you were using tabs.
+* Spaces are meant to be used as, surprise, surprise, spaces between words. Tabs
+  are a special character than give precisely the needed context for indentation
+  and tabulation.
+* If you are working with other people, you are basically forcing people to an
+  indentation setting that not only they might not prefer, but could actually
+  hurt their productivity.
+
+## Tabs
+
+Now I'll list the main arguments for and against using tabs. This list mostly
+mirrors the one on spaces, just from another point of view:
+
+### Pros
+
+* Freedom of choice. Using tabs means that anybody working on the same project
+  can choose how they like the code to look on their computers, without actually
+  changing how the code is formatted. This goes against the argument for spaces,
+  that positions spaces as being more consistent. I believe, though, that this
+  argument better holds for reasons I'll mention below.
+* Tabs use up less disk space than spaces do (get it, because they are called
+  spaces, okay, maybe not), as I previously mentioned.
+* Context. Tabs were made for this purpose, all the way back to typewriters[^1],
+  enough said.
+
+### Cons
+
+* They are not displayed consistently. Once more, this argument doesn't really
+  hold water for reasons I'll mention later.
+* Most people and projects use spaces for indentation, which means tabs are not
+  the preferable indentation method. Once more, _argumentum ad populum_.
+* Alignment might look off in different settings, but once again, alignment is
+  not indentation, and this can be worked.
+
+## Head-to-head
+
+It might appear at first that the arguments for and against each of the
+specified methods of indentation are pretty much tied. However, as I have
+already been mentioning, the arguments for tabs ending up being more compelling
+than the arguments for spaces. Let's consider the following:
+
+* __Consistency__ - The pro-spaces people seem to suggest that imposing a set
+  number of spaces as the standard for indentation achieves consistency in the
+  code base. This, in my opinion, is very misleading, since the only consistency
+  that you are achieving is how the code looks on the machine of everybody on
+  the team, thus imposing the tastes of a person or group of people to everybody
+  else, without actually improving productivity, potentially even negatively
+  affecting productivity for some people. Take into account, that what might be
+  readable for you (e.g., 4 spaces), might not be readable for other people,
+  which might include visually impaired people. Ah, but some people here will be
+  quick to point out that some editors, or code hosting solutions will just
+  refuse to display tabs in a consistent or proper way. To which I reply, why
+  use such incompetent software, when literally most modern text editors and
+  IDEs have the ability to configure the amount of spaces a tab takes up on the
+  screen?
+* __Alignment__ - Once more, alignment is not indentation, although it does have
+  to do with it. I do have to agree, however, that spaces are in most cases
+  better suited for alignment, since what was aligned to look good at a tab
+  width of, say, 4, might not look good at a tab width setting of 8. But, who
+  said that you can't use spaces for alignment, while using tabs for
+  indentation? Most competent text editors and IDEs should offer a setting for
+  'smart tabs'.
+* __Most projects/people use spaces__ - As already mentioned, this is a
+  fallacious argument. Just because most people do or believe something, that
+  doesn't make it right or correct. It is worth mentioning though, that it is
+  easier to collaborate with people when there are some standard practices in
+  place. That said, this does not mean that you shouldn't used a better set of
+  practices in your own projects, while also using some other standards while
+  collaborating on others, especially taking into that most competent text
+  editors are capable of using the indentation in use for said projects, instead
+  of the user-set indentation. Not to mention that many languages nowadays
+  provide tooling for formatting the code to the agreed standards.
+
+## Conclusion
+
+After thinking about it for awhile, I came to the conclusion that tabs are
+indeed objectively superior to spaces mostly because of freedom, more
+specifically the freedom to choose the indentation spacing that is most friendly
+to your eyes. 
+
+Imposing a defined number of spaces on indentation, seems akin to me to
+mandating that people in a team use a specific color scheme for their editors,
+just because someone believes that "colorA on colorB is more readable than
+colorC on colorD, and besides, there should be consistency on the codebase".
+
+So I decided that from this day forth, I will be using tabs in all of my
+personal projects, and those projects in which I have a say. Yes, even when
+programming in languages that suggest otherwise (I'm looking at you, Rust).
+
+That said, I do respect the choices made by other people, and since I have a
+non-retarded text editor (i.e., vim) that can automatically change the
+indentation style based on what is already being used on a per-file basis, I can
+actually continue to contribute code to projects where those choices might
+differ from mine.
+
+[^1]: [Tabulating mechanism for type-writing machines.](https://patents.google.com/patent/US908221)