The oOo Way (Part 3): "Why using programming languages for programming is a bad idea?"
Let's delve directly into the essence of what this article aims to discuss:
A slight lifting of the veil of complexity surrounding programming languages can be achieved by a straightforward observation. It appears that all programming languages are hindered by their developers not fully grasping the distinction between incorporating keyboard shortcuts for efficiency in typing and providing a translator that converts instructions, expressed as typed text, into machine code executed by the CPU to bring about a change in the computer hardware state.
You can read more about this here:
"LLMs are not the only ones who sometimes don't understand what we want to say. Communicating poorly is a great limitation, and many programmers communicate very poorly despite being very capable in their specific field."
Understanding this phenomenon, it seems that "thinking like a CPU" is both the cause and effect of the described issue programming languages are affected by.
For additional insights, refer to this article about Linux OS creator Linus Torvalds' endeavor to shift his mindset for a better understanding of the impact of language style on human communication.
By the way: I appreciate the following aspect about LLMs:
LLMs (Large Language Models) are not resentful, whether verbally insulted or responding to questions that indicate a lack of understanding.
In this context, it's worth noting that perceiving the lack of empathy or emotions in LLMs as evidence that being human has an advantage over AI (Artificial Intelligence) is challenged by personal experience. Deep spiritual paths can lead to a state where verbal insults do not affect one. The key difference is that a wise, enlightened human might choose to disengage from a conversation with an unwise individual.
Now, returning to the explanation of why using programming languages for programming might be a flawed idea:
The current landscape of programming languages influences mainstream mindsets, creating a belief that the existing state of affairs has a well-hidden justification yet to be revealed due to a lack of knowledge. As you accumulate enough knowledge in this area, the Sunk Cost Fallacy and the effects of psychic inertia may hinder you from objectively identifying where the path went wrong and why.
What I observe is that programming language developers impose their created shortcuts on users, necessitating learning before using their creations.
The widespread practice of separating code/comments from documentation is so deeply ingrained that questioning it is rare, potentially constraining you from considering alternative ways to deliver software that effectively influences the state of computer hardware.
This is where the oOo way comes into play.
Starting to be aware of the above will open for you the path to separation of keyboard shortcuts you can individually adapt to your own needs using for example espanso in order to arrive at code resembling natural language sentences you made the oOo system capable to translate to an executable in first place.
The oOo way is to make it possible to merge code, comments and documentation into one single text document which can be then used for both purposes: as an executable and as documentation.
Top comments (0)