Personal Insights
something to learn from the Unix philosophy
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
P.S.: Check our new “Virtual Wishing Well for Blogging“.
P.S.S.: Not tired of reading blogs? Read about this blog by Andreas Schaller.
I love the UNIX philosophy, I went on UNIX training in the 90’s, one of those rare courses where the insight was more valuable than the technical skills it taught. Those insights helped shape my career ever since. I am often reminded of two quotes from it because they have been consistently relevant:
The second one is easily applied to many softwares today, and is what drives the modular architecture.
It’s also why I use Mac as my favoured OS, it has a simple UI but a powerful Linux-like console underneath (MacOS is derived from BSD-UNIX).
Is the second one "I love UNIX"? 🙂 The first one fits to another discussion I had today: Can one be a developing consultant or a consulting developer. I think it's worth another blog on my part ... 😉
No, that was the full quote. It was a reference to all the different flavours that were vogue at the time (SCO, XENIX, HP-UX, BSD, just to name a few), a bit like Linux distros today.
The amazing thing is that such vastly different systems were basically all the same, and my "AHA!" moment was on realising that it was all because of the clean architecture and modularisation, every component had its job to do and every component was simple enough to understand, but all of them together are a formidably complex and powerful OS. All still very much applicable software in general today.
I think both consult-developer combos are valid and possible, but it's probably a bit too nuanced for the average 10-50 developer organisation. That's my 2p on it 🙂
Thanks Michael, another thought-provoking post. I really like these articles which give colour, shade and context to what we’re doing. I remember doing a 2-week course on data-driven design as a young programmer… 2 weeks - wow!
Cheers
Ged
P.S. this reminds me that I was going to blog on KISS and what paradigms and messages motivate us to make things better.
Now that you typed a comment about writing a blog on KISS, you should do it!  It sounds interesting.  I love that philosophy. It's too hard to maintain programs without it.
That's the point: We are doing a lot every day. It's sometimes hard and sometimes easy to ignore or see the colors, shades and context.
I would be very happy to read a blog on the KISS principle. I spend a lot of time every day making things as simple as possible. Over the years, complex solutions have proven to be error-prone and difficult to maintain for me. However, it's really hard to make things as simple as possible. Sometimes I can't see the forest for the trees...
Interesting. Those rules apply to all languages. When I think about data, I start to think about CDS views.  I like that we can get to the underlying tables.  But the views themselves, bring together the data in a meaningful way. I can go look for purchase contracts and get several views. I can dig deeper in those views to put together more.  I guess my point here, is that taking a step back, it is all about the data and how it is put together. This is even more important as we go looking for other classes, views, APIs...  Whatever.  So we are doing it without even really thinking about the rule.
Just my early Monday morning thoughts.
Hi Michael,
Pretty nice article. The Unix principles can not only be applied to ABAP environment but to the most programming languages IMHO.
Regarding point 14 I think about generative ABAP and subroutine pools: https://itpfed.com/abap-dynamic-programming-part-5/
(Even if I used it only once in the past…)
One of the cleanest OSs ever was IBM's VM/CP/CMS (Cambridge Monitor System). It like Unix came out of the same MIT project in the mid 1960s. Unlike Unix it was better for humans IMO since it had all the functions w/o the nerdy gobbly gook abbreviations, eg. grep etc. Most people who used listservers never knew that was from the IBM/VM OS.
Back in the early 1980s my then company ran virtual machines of IBM PC/DOS, six IBM Mainframe DOS/VSs, four IBM/MVSs, three Unixes (SCO, BSD and Amdahl variant), two Unix clones called "XMS" and two IBM/VMs guest operating systems all under one VM (Virtual Machine) operating system and all ran with subsecond response times. The mainframe it ran under was barely working and the guests ran faster as guests than they did on bare hardware. By the end of the 1990s one could run multiple thousands of VMs on one box, but that does not sell much hardware.
IBM/VM (Virtual Machine) is a forgotten OS that propped up Bitnet, back in the day. It was later ported since the code was open source and that port is now known as VMWARE. All the code was open source up until the 1980s when IBM was allowed to make new additions no longer open source. There was a user group (VMSHARE) that fixed/expanded the open soure code similar to what is done in GitHub today. IBM used it internally into the 2000s until the cigarette salesman (Gerstner) canned it. I think that it is now firmware known as Z/OS or something and maybe IBM still use it today for some applications.
"Cloud computing", open source, user communities, and sadly worldwide pandemics - forward into the past!
Stay safe and healthy.