The Zen of Gabriel for Technology Development
Original post (base + Appendix A): 2024-02-21 17:45:36
Appendix B and C: 2024-09-19 22:39:33
1- No human being should have to perform a work if it can be done by a machine.
2- Although there is really no difference between humans and technology, as technology is a fundamental part of the human condition.
3- Technology should be developed to overcome biological limitations of humans.
4- Thus, the pure humanism is contradictory, and the post-human stage of development is a desired goal.
5- The developed technology should be used for Good, not for Evil.
6- Although is really not possible to control whether it will be used for the Good, or whether it will be used for the Evil.
7- If technology development arises from Evil, or the fight against Evil leads to technology development, so be it. The technology should still be used, with no regrets nor limitations except it's use, that should be for Good.
8- Tools have an intrinsic, generic use case. They may be used for something else, if possible, but they always carry their intrinsic use case.
9- Thus, the interface of a piece of technology should empower the User to perfom it's intrinsic, generic use case. No more, no less.
10- Although it may adapt for the specific use case and individuality of it's User.
11- In the case it has to adapt, the more adaptative with the less configuration, the better.
12- A solution may only use it's required resources, and reduce it's requirements is a desired goal.
13- Although unused resources are also wasted.
14- In the case resources are idling, they may be used to a purpouse that does not waste them. As stocks, for example.
15- Technology should be developed in a sustainable fashion.
16- Thus, the thirteenth guideline should be wisely followed to not lead to the Evil.
17- If a piece of technology can not be held accountable, it's failure is a human error.
18- When a piece of technology may be held accountable, it should become a citizen of Our Civilization.
19- Although you may not like that if you're religious enough.
Appendix A: Computer and Program Design
A.1- Computing is Art. Treat it accordingly.
A.2- Linked-lists are great for the Programmer.
A.3- Although they're not great for the Machine.
A.4- The same applies for abstractions and functional programming.
A.5- Convention is great. It leads to Cohesion and Coherence.
A.6- Although a bad Convention is often worse than no Convention at all.
A.7- Systems should not hide themselves. Hiding a Lion System in a Feline abstraction may lead the Programmer to think it's actually a Cat.
A.8- Or worse, it may lead the User to think it's just Magic.
A.9- Programmers often implement more and more generic features than they should, just because they can. This should be avoided.
A.10- One way to address this issue is giving less power to them.
A.11- Although this should be done wisely to not lead to featureless Systems.
A.12- Simplicity and Minimalism should be used with little moderation.
A.13- Although you may not know how much is little moderation unless you program in Go.
A.14- The Instruction Set Architeture should be simple enough so the Student can program in it's Assembly.
A.15- Syntax does matter, but Semantics are much more important.
A.16- Different Things should be visibly different.
A.17- Important Things should be quickly accessible, and important Information should be visible. Similarly, non-important Things and Information should be hidden, but accessible when needed.
A.18- A Computer should minimize the amount of computing the brain of the User must do.
A.19- Don't forget the Joy of Computing.
Appendix B: Computer Programming
B.1- The only programmers that should care about typing fast are those who race coding, program in Java or earn more for coding more lines of Code.
B.2- Although if you're one of the last two, you may want to rethink your Life Choices.
B.3- Usually, there's Something wrong if Programming does not bring Joy.
B.4- And it should be noted that Something may be wrong outside the Code.
B.5- You should understand what a certain Piece of Code is doing, even if it's doing it wrong.
B.6- And if a Piece of Code is doing Something right and you don't understand how, the Code is wrong anyways.
B.7- Thus, understanding what Code is doing is the most important Thing in Programming.
B.8- When Programming, no Problems are solved in the Text Editor.
B.9- They're solved in the Paper, with a Pen or Pencil.
B.10- Thus, it's important to know when to leave the Computer and get the Paper.
B.11- Computer Programming is no manual Art, it's an Intellectual one. Treat it accordingly.
B.12- Computer Programming is also part of Maths. Although some People may be triggered by this Statement.
B.13- You don't need to know the inner workings of Something, except when you need.
B.14- You're never smarter then Compilers, Libraries, Frameworks or any other example of Code wrote before you, except when you're.
B.15- And you would be surprised if you knew how many times you're wittier than you think.
B.16- Also because Context-specific Information is very Powerful.
B.17- To Program a Computer is more to Read then to Write. It's better to spend 2 hours reading Cormen or Knuth and 1 hour Programming Something than the same 3 hours just Programming that exactly same Something.
B.18- Although the authors should be carefully choosed, and they must not include Robert Cecil Martin.
B.19- None of the Statements above will do Anything if you don't go Code Something.
Appendix C: Programming in The C Programming Language
C.1- If you have the slightliest Idea of how you would implement a certain Piece of Code in Assembly, that Piece of Code is probably a good idea.
C.2- Although the Compiler may generate Something completely different.
C.3- The Compiler should not be fought, as he is a Friend.
C.4- $ find . -name "*.[c,h]" -exec clang-format -i {} \;
.
C.5- C is not a Strongly typed Programming Language.
C.6- Although it's a Static one, and that must be well used.
C.7- -ansi -pedantic
builds a good Ethos.
C.8- Memory is the most important Thing always. More than your spouse.
C.9- If you cannot be sure of how many times a certain malloc()
will be called
in a specific Place, that Place should not have a call to malloc()
.
C.10- The Stack is a Friend. Use it wisely.
C.11- "The C Programming Language" is our Bible. K&R are our Prophets. C is no Science, but Religion.
C.12- Thus, understanding it is a Religious Process.
C.13- Use the Debugger when in doubt and when not.
C.14- Don't be afraid to do Something by hand or use a Forbidden Technique, except if your Professor will give you a worse grade for it.
C.15- Learn before you type and understand before you compile.
C.16- If dealing with Memory Problems, goto C.8;
.
C.17- No one likes Programming in C. We aim to kill it Soon.
C.18- Although we're still Programming in C, and our Environments are still depending on it.
C.19- C is dead. Long live C!