Skip to Content
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:

  1. Build modular programs
  2. Write readable programs
  3. Use composition
  4. Separate mechanisms from policy
  5. Write simple programs
  6. Write small programs
  7. Write transparent programs
  8. Write robust programs
  9. Make data complicated when required, not the program
  10. Build on potential users’ expected knowledge
  11. Avoid unnecessary output
  12. Write programs which fail in a way that is easy to diagnose
  13. Value developer time over machine time
  14. Write abstract programs that generate code instead of writing code by hand
  15. Prototype software before polishing it
  16. Write flexible and open programs
  17. 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.

8 Comments
You must be Logged on to comment or reply to a post.
  • 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:

    • Do one thing and do it well
    • I love UNIX, there are so many standards to choose from

    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.