This article really grinds my gears. The author tries to discount the use of command line interfaces by saying it is an obsolete interface-technology (mostly reserved for developers and advanced system administrators).
Pontificating that modern Unices (like Mac OS X and Linux) suffer at exactly the same areas of complexity because of their Unix-heritage. Well, I call bullshit...
- Linux does not have a Unix-heritage, because it does not contain any UNIX®-code.
- Computer complexity is really a catch-22 scenario; every time you modify something low-level, something may break on a lower level. Keeping this complexity usable at varying levels is a master-class balancing-act, and not to be taken lightly.
Yes, the
Unix-philosophy states that every program should:
do one job, and:
do it well. And to some extent, Linux has done just that. BUT, since we're operating in a so-called "open-source community", where
everyone has the right to shout out concerns, fixes and feature-improvements, the so-called "
bloating" of CLI-programs are a direct result of this fundamental right to speech, re-use and community involvement. Which in itself is beneficial to everyone using the software.
The reason why lower-level programs use much the same functionality as was used in the original
UNIX®, is because the programming language in question (C) has few alternative methods of performing low-level calls to the hardware, and thus is forced to do certain things in specific ways. Having these low-level functions available at any time for whichever program needs them is fundamental to a POSIX-system. And re-using these functions to build / extend programs is the way it's always been done
I can agree with his point about re-creating and duplicating core-functions in a program if the program already facilitates the components needed to do a specific task, it's unnecessary. But I can see the other side of this matter as well, from a developer-viewpoint. If you spent a lot of time (multiple iterations) developing and extending an already-implemented function, (just) to get specific results presented in a specific manner, wouldn't you want to include it in the program so you wouldn't have to re-implement it further down the line if ever needed again? And does it really affect normal users what kind of extra filters and/or flags a program accepts from the command-line? Not really...
Back in the day (70s and 80s), this was the only way of specifying arguments to programs in a sequential fashion, and to some extent still is. Hardware works on the principals of sequential data-flow and execution, and unless we do something drastic to the hardware-platform we are all using, this is the way it will continue to be used in low-level terms (
C+asm) until we do.
Until we see newer and better ideas concerning the data-bus / CPU inter-connection, we will not be able to implement any innovative interface-functionality on a low level.
My point is this: CLI is not meant for
normal users. It is not intended to
simplify computing, rather, it was intended for developmental and operational purposes, created by the very same type of people who use it on a daily basis.
If you want ease-of-use and simplicity, use Apple or Microsoft, and supplement that usage by providing user-feedback to them for new features / functions and fixes. Don't just crap on the alternative(s) because "it doesn't conform to my unique idea of what
user-friendliness is". Linux was never made to be user-friendly. Derivatives were made to suit that scenario, so use them, instead of slagging on about the lacking user-friendliness and simplicity of the OS itself.
To quote one of the best sayings I have ever read:
"
Unix is very simple, it just needs a genious to understand it's simplicity"
--Dennis M. Ritchie
Posts
