DOTADIW. Wait… If you don’t know what ‘DOTADIW’ means, you have virtually no context to move forward. You might guess it’s a acronym. You might Google it. Otherwise, full stop.
DOTADIW means “do one thing and do it well.” Google it, and you’ll see it referred to as the “Unix philosophy.” Once you’re well familiar with how one thing is done well, you’re golden. You’re an expert at that one thing, and DOTADIW is for you, for one thing.
When doing one thing well, there is no interest in doing other things well, nor interest in how other things are done. No interest in compromise on doing something very well so that its more like other things. Hence, one thing “done well” is very much unlike other things “done well”, and being an expert at one thing does not help much with other things.
This is the world of Linux executables: arcane command line flags which summarize (often to the point of belying) how things work. This is the truth of regular expressions, of object relational mapping, and of domain specific languages. Once you learned the abstraction – you’ve freed yourself from the implementation details.
However, examining the details is often how one learns. Knowledge of regular expressions does not significantly aid object relational mapping. With Linux, a thorough understanding of “make” does not help with “sed” and “awk.” Hence we see many language specific implementations of common tasks. Java and Python developers seldom run and parse “ls” to get a directory listing – it’s simply easier to learn their language’s native implementation. The difficulty of mastering the details of simple commands (DSLs if you will) exceeds the difficulty of re-implementing them under the warm blanket of familiarity.
This is, of course, because simple commands often hide immense complexities. An abstraction may help you or hurt you (consider the variety of regular expressions purporting to parse phone numbers, or ORM’s label as the “Vietnam of Computer Science”). [In truth, there is no guarantee of positive ends, only of summary action.] Hence, the hiding of complexity – particularly as it pertains to learning domain specific languages – should not be considered a virtue.
This argument / claim above applies to “Linux proficiency”: familiarity with a proven, ragtag assemblage of GNU applications that must be mastered individually and not as a group. There is little familiarity upon which new commands become easier to master (beyond knowledge of basic shell features).
… and I simply find that interesting.