Command Line Interface

There is an ancient computer debate about command-lines versus a GUI (Graphical User Interfaces). There is an ancient computer debate about command-lines versus a GUI (Graphical User Interfaces). One side argues that command line is where the magic happens, and if you don't know it, you don't know computers. And one computers designed that way, there's a small grain of truth. but a lot of bias and things to unpack as well. ℹ️ Info           ~ Aristotle Sabouni Created: 2002-11-29

What is a command line and GUI?

A GUI is a graphical user interface. The user interacts with menus, widgets (controls), and windows to make things happen. Things are displayed from a graphics mode, instead of the older way, which was just displaying everything as characters and text; and so it picked up the 'G' in GUI.

A command line, on the other hand, is not a user interface at all. Users may interact with it, but that's coincidental. What a command line is, is just programming interface or language, where you write little file based computer programs, through a really lame editor, one line at a time. Then those commands get interpreted and executed as you type them.

There's a big difference between those two. In the GUI it tries to do things like present your choices, interpret user behavior, and make the users life easier. The CLI assumes that everyone is a programmer, who will memorize all possible commands, and variants and variables/attributes for each commands, and then run those little programs to make the computer do what they want. This is fine if you're a programmer and think like a programmer, but kinda sucks if you're a user that just wants to USE the computer.

Lower is better

An implied argument is that that lower level is better. Command lines are sometimes underneath or below GUI's. So what is happening is that GUI applications are actually sending commands to the command line, or interacting roughly at that level, so by understanding the command line, you're understanding the root of the problem; thus know more about why things may or may not be happening.

There are a couple problems with this though.

First, not all Operating Systems are designed this way. UNIX and Windows were designed that way; with a CLI underneath a Graphical Interface layer, but the Macintosh was not. UNIX and Windows didn't do this because it was the best way to design a GUI; they did it because it was easier and they had to fix less if they just hacked and bolted stuff onto what they already had.

So assuming that the CLI is fundamentally a lower level, shows naiveté about true design and is just reflecting a bias of the systems that they are familiar with. It doesn't have to be like that; it just happens to be in the platform that they know. You could build a command line and GUI on the same lower level system, or have no CLI at all, and build a higher level scripting engine like Apple tried with AppleScript. There are many ways to solve a problem.

Another issue is that if lower is better, then why stop at the command line? Why should I stop at the stupid silly single line editor and lame command line language (shell script)? Why don't I go lower level and use a better language like Perl, PHP, Python, or Java? And if lower level is better, then use C or PL/M or a lower level language? Or why not lower still, and use assembler language? And why stop there? Why not code in the lower level machine code (binary or hexadecimal representation that the computer understands). And why stop there? Real men code in microcode and use logic analyzers and oscilloscopes; that's were the true understanding of the computer comes into play. Until you understand propagation delay and transistor settle time issues, then you're not a real computer user.

Of course that argument is silly. We built layers on layers on layers, so that most people wouldn't have to know all that stuff. Each layer you climb up is that much easier to learn, and allows for users have to know less and do more with a single action, thus making things easier to learn and faster to use. Arguing that you should know how to use a command line to use a computer, is the exact same as arguing that you should need to know how to manually adjust the timing in your car, and set the air-fuel mixture yourself to adjust for altitude and temperature in your car, before you are a true driver. Silly me, I thought they made cars smarter so I wouldn't have to know that stuff. I also think there's a difference between being a driver and a mechanic; or between a user, and programmer, IT person or solutions creator.

Who are your users

I think the point that many people miss, is who are your users?

If your users are network administrators, then they need to know more than the average user so that they can better diagnose problems, and even write some simple scripts to make the computer do what they want or automate some behaviors.

If your users are software engineers or programmers, then they need to know even more than network administrators on many things, so they can write more sophisticated programs to make the computer do even more.

If your users are actually systems programmers or device driver writers, then they need to write code at an even lower level, and in many ways know even more about some parts of the system.

But if your users are users, then they damn well shouldn't have to know how to write a program to use a computer. Not even simple one-line programs like a command line.

What are you trying to do?

If there is a good interface to a program, then you will never have to get "underneath" the program in order to fix it, to make it do what it isn't doing for you. It is only when a program fails to work in the way that I want it to, that I have to get underneath the simple and cleanly presented GUI (and attributes/configuration options), to get to some ugly text file, or scripted commands to fix whatever is wrong with it.

This means that if I have to go to the command line or shell scripting to make something do what I want, then probably they have already failed to write a good program. Thus they've demonstrated not competence but incompetence. This would be the same as me having to manually set the choke or timing in my car - I don't have to do that any more, because this isn't the 60s, and long ago, designers perfected the automatic choke and so the car does what I want. And for good programs, I don't have to fix or tweak the config files to get it to do what I want.

Now sure, the geeks feel cool when they can make that program do what normal users can't; but there's a different between feeling cool and being productive and making money, or getting work done, or in having a high quality product.

Perfect world

In a perfect world, we'd have nice clean API's (Application Programming Interfaces) written and documented that would be used by GUI's and CLI's. Command lines wouldn't be little lame one-line tools, they'd instead be written on top of the GUI to allow for menus, syntax coloring, full screen editing (not single line), multiple command lines (programs) to each be running in their own window, and to interact with each other at a much better level than just text piping (instead true object encoding), and so on. CLI's wouldn't even be CLI's; there would be a set of complex plug-in's that would allow people to expand and extend programs that goes way beyond scripting events - but even event scripting and data encoding would be much better. We'd have all events passed though a common event methodology, and data would be encoded in it's native form which would be a lot richer than just text. (You could send the output of one object as a picture, or sound, it would be a picture or sound, and not just a stream of garbage). And so on.

Apple came closer than anyone else to doing this perfect world thing. They tried most of these things with AppleScript; with various degrees of success. And Microsoft tried to borrow it with VBA (Visual Basic for Applications, COM, ActiveX and some other borrowed technologies/ideas). But both have not really fully succeeded. Apple had a better design in theory, but fell short on implementation. Some of Microsoft's technologies had better implementation, but lame designs. And in the end, neither has quite succeeded to the level they could have. And UNIX variants were definitely 1960's designed CLI's, with 30 years of cruft added on top, one grad project at a time, without anyone actually fixing underlying architectural problems or compromises.

Also in this non-prefect world, we have to live with what has come before. People don't like to learn anything new, so they just parrot and stick with older and more primitive solutions, rather than true growth. So we've artificially increased the cost of change. Thus rather than getting best case solutions, we stick with mediocre or "good enough". But that is the world we live in. And UNIX is older, and has the most legacy, and seems to have a user base that is the most resistant to change. So while UNIXes piping and scripting are often lame and outdated compared to what we could do (if we first wiped out the bias and assumptions behind those implementations), in practice it works pretty easy and is in fact good enough; and probably better than any alternatives to date.

---

👁️ See also

• Anti-aliasing - What is Anti-Aliasing? It is using color to increase the percieved resolution on a display.
• Basics of BASIC - People ask me, "How do I get started programming?" Ther are a lot of choices, but BASIC is a pretty simple start.
• Big or Little Endian - What is Endian? How do you like your eggs (or counting systems)? Big or little end up?
• Command Line Interface - There is an ancient computer debate about command-lines versus a GUI (Graphical User Interfaces).
• Databases - What is a database? What are the kinds of databases? Why do you care?
• Digitized Sound - Digitized Sound: understanding samples, rates and digital audio is really pretty simple.
• Enterprise Tools - Enterprise, Opensource or Commercial tools, which is better and why? Of course the answer is, "it depends".
• FUD - FUD means "Fear, Uncertainty and Doubt", it was used by big companies to scare users away from small companies.
• Forward Compatibility - People talk about "Backwards" compatibility, but Forward Compatibility is often more important.
• Free Features - A free feature in software, is like a free lunch: and in case you don't know, there's no such thing as a free lunch.
• Hiring Programmers - Many Human Resources and Managers, don't know how to hire or utilize programmers; proven by their job reqs.
• History of Visual Basic - The History of Visual Basic is a bit of a history of early computers and Microsoft...
• How does compression work? - How does software Compression work? How do you make something smaller?
• MHz or GHz - MHz or GHz, what does it mean? It's just clock speed - but that doesn't mean what some people think.
• RISC or CISC - During the 80s and 90s there was a Computer Chip design war about RISC or CISC.
• Raster Images - What exactly does raster versus vector images mean? Here's the very basics of pictures or rasterized images.
• Software Consultants - I worked over a decade as a consultant, and used and managed them for a couple decades more.
• Software Development Life Cycle - There's a lot of variants of a Software Development Life Cycle.
• Synthesized Sound - Synthesized Sound is just making waves... sound waves.
• UNIX - UNIX is the old war-bird of Operating Systems -- which is ironic as it isn't an OS any more -- but more on that later.
• What is MP3? - What is MP3? It's just a compressed file format used for sound (that came from MPEG's version 3).
• What is a WebApp? - What is a Web Application, and how does it vary from a traditional website?
• Why is software so buggy? - Why are programs so buggy? They're not bugs, they're undocumented features... sorry, that's an old programmer joke.

🔗 More

Tech Technology: Organizations, Reviews, People

UNIX UNIX is the old war-bird of Operating Systems -- which is ironic as it isn't an OS any more -- but more on that later.

Programming Computer Programming Articles.

Tags: Tech  UNIX  Programming