The oOo way (part 2): "I spy with my little eye..."
With over 30 years of experience in computer technology, software, user support, and giving lectures on data processing, I find myself reflecting on why I hadn't embraced the oOo way much earlier, perhaps 30 years ago. Why did it take so long for me to gain a clarity of mind that surpasses any experience in my entire past life?
Attempting to answer these questions provides deep insights into what actually is and why things are the way they are.
Imagine investing years in studying at a university, putting in significant effort in your spare time alongside daily business and family responsibilities to master programming languages like Assembler, C/C++, HTML, JavaScript, Java, Python, only to discover that all of it was a waste of time rooted in deep confusion. This confusion resulted from a lack of understanding of the spoken language and building a world of thoughts on incorrect assumptions, beliefs, and concepts.
The notion of considering a computer system as a processing unit requiring software tools to feed it data for input and get results as output was one reason that clouded my understanding of what was actually happening and its purpose.
One breakthrough in understanding occurred when I delved into how data could be compressed to an extremely small size while other types of data remained large or even exceeded the original size. Which CPU instruction was the key to compression—multiplication, addition, shifting bits, or logical operations? Where did the information come from to create a large file from a small one?
Diving deep into this subject revealed a world full of repetitions, as if the universe and the game of life on Earth aimed to save significant storage space. I began to see a forest in terms of compression rather than enjoying the beauty of the impression. The trees became a small set of "seed" parameters needed to reconstruct all the repetitions, creating an illusion of abundance and uniqueness.
The final revelation, making the idea of oOo result in a useful outcome, was seeing what a computer does as a process of translation — translating from one language to another with the purpose of making a choice possible. It's all about choice and translating the intent behind this choice into another language to make it happen. Shifting from the concept of input -> processing -> output allowed thinking in terms of identifying the language used and to which language it needs translation, opening a new perspective like a shift away from the belief that Earth is the center of everything.
I followed the Loebner Prize competition and the progress of research in human-like bots with the hope of creating a bot capable of winning the competition. What I learned is that a huge amount of memory and storage is what makes AI deliver results, with the clever concept having only a secondary effect. It's not surprising to see that surpassing a certain size threshold of input data results in a sudden jump in usefulness.
From the perspective of reusing existing Open Source tools for custom purposes, it became clear that comments and descriptions in the program code are more important than the main part of the code. There's no need to mark them as something special. This led to the idea of programming using natural spoken language with slight adaptations to give words their correct meaning and context. The "executable" words need to be marked, allowing deliberate texts and sentences with smart chosen markings of some parts to be a program script performing exactly what the sentences describe.
What do I need Open Source for if the learning curve for reuse and customization is so steep that the end result is the same as if the code were closed?
I dedicated three months of full-time work to mastering Emacs and even contributed to it by asking and answering questions and providing patches. However, it was a bottomless pit I could invest any amount of effort into without experiencing an increase in proficiency. In other words, I wasted three months of my life on it, and it wasn't easy to fully withdraw due to "The Sunk Cost Fallacy". Currently, my main text editor is a custom version of Textadept, which I named eoOo and run by typing 'e' at the command line. However, my fascination with Textadept and Lua scripting, enabling customization to rival Emacs while staying slim, has come to an end with the concept of oOo, which will probably result in a completely different approach to text editing one day.
Top comments (1)
In between I am not using Textadept anymore as it turned out that it becomes slow with larger sizes of the edited files (Lua scripting including lexer customization is perfect to shape the user experience, but ... it results in a no more for me acceptable speed bottleneck). The current text editor I am using is Geany and I enjoy its integrated Terminal window running the edited files.