Dear community, some time ago I noticed the article about the
Unix philosophy on Wikipedia. The first sentence is already interesting, as
Ken Thompson is mentioned in connection with the definition of the Unix philosophy: "
The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist, modular software development." The definition sounds like a chance to get some helpful insights, knowledge and tips that a developer can use in everyday life
🙂 So I've read the entire article and would like to recommend it.
One part is about "
Eric Raymond's 17 Unix Rules". Even though the entire article is very interesting, I particularly liked these rules. The following are the rules as listed in Wikipedia:
- Build modular programs
- Write readable programs
- Use composition
- Separate mechanisms from policy
- Write simple programs
- Write small programs
- Write transparent programs
- Write robust programs
- Make data complicated when required, not the program
- Build on potential users' expected knowledge
- Avoid unnecessary output
- Write programs which fail in a way that is easy to diagnose
- Value developer time over machine time
- Write abstract programs that generate code instead of writing code by hand
- Prototype software before polishing it
- Write flexible and open programs
- Make the program and protocols extensible.
While reading, I got the idea that the term "program" can mostly be exchanged for "report", "class" and "interface" - three development objects that we use frequently in ABAP. Number 14 reminds me on SE16 and table maintenance generator
🙂
Overall, a lot is reminiscent of clean code principles (check "
Clean ABAP"). That's why I find it interesting to read: It has an universal validity.
Rule number 9 allows perhaps a connection to rule number 5 of "
Rob Pike's 5 Rules of Programming" (short version
here, more detailed in "
Notes on Programming in C"). It says: "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.".
In my own experience, this is very often the case. When I design a class and consider what data this class processes, the methods I need often emerge. Many methods, including their signature, result from the flow of data.
Nice anecdote by the way: During my studies I had a lecture called "algorithms and data structures". At that time I was not aware of how important the topic of "data structures" in particular would become at some point. Now I work every day in SAP ERP systems with a lot of data, mostly structured data. As for the structure: I'm always surprised and grateful for what other developers have thought in advance. It's a gift if you don't have to reinvent the structures for purchase orders for every project
😉
Ok, that's all for now. Hope you had some fun and a nice starting point for your own research regarding the Unix philosophy.
Best regards, thanks for reading and
please stay healthy
Michael
