The power of plain text and the databases is obsolete
Introduction
I think that all of us who have worked for some time with Emacs or UNIX tools have come to the same conclusion and that is that working with plain text gives us a number of advantages that the use of more complex tools takes away instead of giving us more facilities. I’m thinking of Sacha Chua’s article, for example, but I can assure that almost everyone I know who uses tools like Emacs, Vim and UNIX tools like sed, cut, awk, etc, come to the same conclusion. But I would just like to explain it a little bit more.
The databases is obsolete
This comes from something personal and is that in my company they are going to change my project and although normally it is something that would not bother me the first question of my manager was: do you like databases? I told him no, of course not, and I have been working with them for many years and not just any databases, we are talking about databases of all the airports in my country, but it turns out that some parts of them have been in plain text for a long time and I manage them with Emacs and Elisp.
And why do I say that they are obsolete. Well, let’s take a look at the history of databases in general and then we’ll talk about why it’s so hard for humans to change a habit when we get into it.
If we analyze the history of databases, its appearance and development occurred in the 60’s, although its boom and especially the creation of the relational model, the most famous and nowadays the most used, is from the 70’s. Sometimes not even computer users themselves do not understand the importance of databases.
Sometimes not even the computer users themselves realize how much computing has advanced, but I have to remember that the processors of the 70s, I will not even refer to the mainframes of the 60s, compared to those of today, does not even come close to the difference between an abacus and a calculator of the 80s. The same we can talk about hard disks, in the 60’s they were still cassette tapes the size of a truck wheel and a magnetic hard disk half a meter with the capacity of 1 Megabyte of memory.
We can talk about the fact that databases are now more extensive and complex, but the reality is that they are not, and that the computing power of today’s computers and especially today’s hard disks are millions of times faster today.
In short, the creation of databases, using binary and indexing systems, is perfectly adapted to a time when the computing power of computers and the speed of access to information was very limited, which has the logic of its time and era. The point is that even talking about today’s very massive databases, with millions and millions of records, the fact that this information is in plain text makes it much easier and therefore faster to access. The issue is such that we take refuge in the supposed complexity of today’s databases, but 99% of companies use spreadsheets, which are binary files that are difficult to access and also use scripting languages to manage them, such as Python or Visual Basic, which are much slower than any UNIX tool written in C that iterates over a plain text file.
So much so, that those of us who use Emacs, are also using Elisp in interpreted mode, although we know that we can compile it and on a text editor that is not at all optimized for data processing work and even so, knowing that we could optimize it, it is enough for us.
Conclusions
It is incredible and at the same time normal, how human beings are creatures of habit and how difficult it is for us to leave behind ideas and concepts that are no longer useful to us. That’s why we always choose the same tools and the same solutions for different problems, without stopping to think about anything else. That’s why it bothers me a lot, the typical surveys of, which is the best programming language or which is more appropriate to learn, because the right question would be, which is the most appropriate language or the most appropriate tool for what and not end up in a discussion, as if we were fans of a soccer team.
That’s why I say that in most cases, simple solutions are the most appropriate, although everything must be analyzed.
/gemlog/english/