Submitted by “There are several possible reasons why you might choose to use the command line interface as your desktop environment. For one thing, it uses less electricity, so you could maximize battery life on your laptop computer. Secondly, it forces you to think about your operating system and directory structure in a totally different way than a GUI does; this could greatly enhance your understanding of GNU/Linux and cause you to be more creative in your technological problem solving. And thirdly, everyone will think you’re a supreme computer genius for ditching X11 for the CLI. People passing by your desk will think you’re some kind of computer god. Who doesn’t want that?”
I only use X for this reason: my eyes. I don’t like pure black background, it really hurts my eyes after a while. However, I use fluxbox, and I only use GUI versions of programs when there is no terminal alternative. I basically live in my terminals… thank God for urxvt, emacs, gcc and fasm!
just change the background colors of your terminal 🙂
Wow, that’s rather ironic — I tend to use fullscreen text sessions at home because I find that an 80×33 screen with green or cyan on black is a lot easier on my eyes than anything in the GUI.
That’s why I tend to use text clients for mail and USENET, and why I also use Links a lot for web surfing instead of a GUI browser.
Our eyes must be different. 😉
Same here. I use the terminal on my NeXT a lot and its black and white, but not overly bright. My eyes actually feel better while using it then when in XP or what not on my PC…
Why should it be me who understands the OS, and not the other way around?
Using an inferior interface in order to maximize your efficiency in that particular (and largely obsolete nowadays) environment seems like circular logic to me.
Yes, command line is inferior to 2D GUI. As a concept. Your experience is likely different, but that is because the currently available GUI environments are sub-optimal, due to the “desktop”-paradigm that forces you to use the computer like you would use an actual desktop. Imagine typing shell commands in natural language. That’s the current state of 2D GUIs.
Don’t get me wrong, I’m not advocating a desktop environment designed on the computer’s terms, I’m advocating a desktop environment that takes into consideration the input methods we have available, and gets rid of the crippled desktop paradigm.
Anyway, my initial point was this: Using the terminal for your desktop is just stupid. Unless you think it’s cool to seek out extra tedious ways to get your work done, of course. The battery time saved is spent doing meta-work.
– Simon
pfft, it is not ‘inferior’. You can get MORE done with a single command in a cli that would take several clicks or more in a 2d gui. You just don’t prefer it too a GUI. Don’t call something you don’t prefer inferior. They both have their ups and down.
And please refrain from making comments such as “Using the terminal for your desktop is just stupid.” It’s just asking for a flame fest.
Did you not read his post? He said “as a concept.” It’s completely provable that GUIs have more potential than CLIs because they have more capabilities; if GUIs can completely subsume the features of CLIs and can keep going, then a GUI has a hypothetical maximum efficiency level at or higher than CLI.
I understand exactly where you are coming from. The GUI does speed up some things, but it is also a hinderance in others. It really boils down to what one needs as well as one’s skill at the command line. I think that server administrators would be more apt to like a CLI only environment over the average user since most of their time is spent SSHing into a box anyways.
Anyways, I think that someone should point out a few programs in which this author has left out. links browser is great with framebuffers and allows one to see the images on webpages as well as image files on one’s computer. fbxine for movies isn’t bad.
Also, for those who want a cli like environment without getting rid of X, try ratpoison. It is kinda like “screen” for X. The main windows are an xterm or other term of your choice. You can then open such programs as firefox or thunderbird in alternate windows.
if you like ratpoison, (which I’ve also tried), might I suggest trying wmii as well. I was looking for a window manager to use at work (were I mainly live in a bunch of open xterms) that could _easily_ be navigatable via keyboard shortcuts. wmii is, plus has a lot of really handy features built into as well that make work that much more efficient. I tried ion as well, but couldn’t quite get into it (wmii starts with a short tutorial too, so perhaps that’s one reason I could pick it up easier than ion)
anyhow, here you go http://wmii.de/
the funny thing about ion, ratpoison and wmii is that they are most often shown of running multiple CLI windows…
the funny thing about ion, ratpoison and wmii is that they are most often shown of running multiple CLI windows…
If you’ve ever used any of these window managers, the reason is obvious. The listed window managers work far better with terminals than traditional wms do and the terms work better with these wms. Gui apps tend to want to be a certain size, which doesn’t work as well when you’re stretching/squashing them.
Moreover, these apps are designed and used by people who use X primarily to run a bunch of xterms.
It’s amazing what you can do just in a text environment. You mention fbxine, which I had never heard of, but there is also cacaxine and aaxine which are interesting text movie players. You really need to see it to believe it…
Interesting players, yes, but do you really want to watch your pr0n in ASCII?
Because you’re smarter than the computer, not the other way around.
Why shouldn’t your band saw know you instead of you knowing your band saw? Because you can’t cut off its fingers, it cuts off yours
.
Allow me to disagree. Graphic user interfaces are not expressive , period! The moment designers begin to understand this fundamental limitation is the moment they begin to design better interfaces.
Believe it or not, the shell terminal still provides the most expressive popular interface to date. To label it as primitive is as ignorant as it is arrogant. A graphic user interface is just a higher level language that computer literate users use to interact with a system.
By its very nature, it is should be designed to be limiting and simple! The next level of expressiveness is the shell terminal. Its design should not be as limiting as a graphic user interface, but equally should not be as complex as the most expressive interface, a real programming language.
Designers who try to make GUI’s expressive have already done great damage to the industry. Your average graphic user interface application is overwhelming, bloated and complex, and needlessly so too. An ideal application should combine the simplicity of the intended purpose of the graphic user interface and the expressiveness of shell-like commands to provide an experience that caters to both normal and advanced users.
But alas! Designers who share your postulations think the shell terminal is dated, so they proceed to design the monstrousity that plague many our graphic user applications today, retardedly complex GUIs that demand time and resources to master.
What we need is more tools that bridge the shell terminal to the desktop environments and vice-versa. What we need is better designed command line applications. Yes, many of them are horrendous! bzr is an example of a well designed command line tool. What we don’t need to is try to make the GUI expressive, because by doing so, you make it slow, bloated, and unweildy.
Edited 2006-03-17 00:28
That doesn’t make any sense… Read my above post.
Yours don’t make sense either.
I think the fundamental problem here is that nobody can agree on what a GUI is.
It’s a high level language. An interface to a computer system. But some people want to make it expressive, and therein lies the problem.
Let me elaborate, then. GUIs and CLIs are both general concepts. What you’re trying to do is use two implementations of said interfaces to prove that one is better than the other; this is like saying electric cars are faster than cars running on gas by comparing a brand new electric car with a model T Ford. The only way to compare those two concepts is in theoretical terms, unlike what you did. A GUI has more potential to be more efficient to use than a CLI because it has all the possible input and output mechanisms of a CLI and more. To get truly technical, using a mouse requires far less cognitive load than typing in commands from memory, and is much better suited to most tasks; unlike CLIs, however, a GUI has the possibility to use both the mouse and keyboard.
Note: GUI = 2d “graphical” UI with mouse and keyboard. Yes, curses apps technically count as a GUI under this definition, but curses apps aren’t really completely CLI.
That still does not nullify the fact that GUIs are not designed to be expressive! Clicking and pointing is limiting! Expressiveness is defined by the ability to do more with little. This is where GUIs fall apart and will always do so. And I’m not saying GUIs are better or worse. All I’m saying is that they should never be designed with the intention of being expressive. This is an issue of expressiveness versus staticness. GUIs should be simple and static. The shell terminal is there to provide expressiveness for those times where the GUI will be too limiting.
Edited 2006-03-17 03:59
You still don’t get what I originally proposed.
The current GUIs that we have around are, indeed, very limiting. However, the potential of a 2-dimensional interface, as opposed to a 1-dimensional interface (the CLI), is huge. And it isn’t just a question of the mouse vs. the keyboard, it’s a question of representing various data simultaneously, interacting with several processes at one time.
We all KNOW that current standards in 2D GUIs don’t at all take advantage of these great new possibilities. Here are some of the reasons:
– The desktop paradigm, which forces a limiting set of principles on a GUI in order for humans to relate it to things they already know.
– The control paradigm, the same (and by control I mean widget, windows, etc.).
– The idea of a program as an either running or non-running process that you execute, inherited from the CLI, but in the 2D environment it’s limiting since you can only use a program if it’s running (and not, say, redirect input from somewhere else at have it execute accordingly). It’s being done with file associations, but that’s a consequence of the desktop paradigm.
Of course, this is purely speculative, since nobody has ever implemented anything that didn’t do the above.
– Simon
Edited 2006-03-17 09:22
Let me add:
– The current restrictions of input devices. The movement of all our muscles taken together amounts to a big stream of data which is totally under-utilized by today’s input devices.
Oh yeah?
How would you take an image and crop it to a certain size without knowing those dimensions before-hand (meaning, you crop it based on what you see)?
Case closed. bytecoder pretty much nailed it on the head. You’re comparing implementations, not concepts.
Your analogy is misplaced. And it has nothing to do with expressiveness of interfaces, in this case GUI vs CLI (shell environments).
What analogy? There is no analogy.
You say pointing and clicking is limiting but say little to back it up. Being able to visually define what part of an image to cut out certainly is expressive, and I’m sorry if GUI is too complicated for you.
Back what up? Isn’t it obvious already. Pattern matching, iterative constructs, conditional decision making, batching and sequencing of multiple instructions, IPC, automation… These are facilities a shell environment gives you for free! GUIs suck at all these!
Being able to visually define what is inside an image has absolutely nothing to do with expressive interfaces. You want to crop a file. So what? Go ahead and crop it. That does not make your interface expressive.
Edited 2006-03-18 01:34
Holy cow, you are thick. If you’re going to keep framing the argument the way you are, there’s no point.
If you can’t counter an argument constructively just quit responding as opposed to spamming my email with worthless comments.
Funny, I was thinking the same thing.
If desktops were like Squeak http://www.squeak.org then you could just open up a workspace shell, write a little script to interact with EVERYTHING in the environment or string together little widgets and write little scripts behind them.
> Allow me to disagree. Graphic user interfaces are not
> expressive , period!
All humans except the blind interface visually with nature all the time. The amount of data received is simply gigantic (think of uncompressed eye-quality streaming video), and to my knowledge it is greater than for any other of our senses. The human visual system is one of the fastest information processors on earth. How is this not expressive? A similar argument applies to sound and to input methods, although the amount of data is not *that* big.
If the CLI is more powerful than the GUI, then what do you think is the reason humans don’t control their eyes and muscles through a imagined command line inside their mind?
The problem isn’t using a GUI for getting information from the computer to the person–it’s the other way around. A mouse is a very limited input device in comparison to a keyboard–though it certainly has its place.
If the CLI is more powerful than the GUI, then what do you think is the reason humans don’t control their eyes and muscles through a imagined command line inside their mind?
You can’t seriously be arguing our brains control eyes and muscles through a point-and-click interface?
> The problem isn’t using a GUI for getting information
> from the computer to the person–it’s the other way
> around. A mouse is a very limited input device in
> comparison to a keyboard–though it certainly has its
> place.
I agree to this, and it’s probably one of the major reason why today’s GUIs suck. Yes, we badly need better input devices.
Anyway, input handling can only be graphical to a certain extent (i.e. interact with graphical objects by feeding data in a nongrpahical way), since muscles aren’t graphical in nature. Whether you call a “muscle-oriented” input device part of a GUI is open to definition (but then, mice aren’t that graphical either).
> You can’t seriously be arguing our brains control eyes
> and muscles through a point-and-click interface?
Certainly not, but GUI means “graphical user interface”, not “point-and-click interface”.
The human senses can process gigantic amount of information. So what? This has nothing to do with the expressiveness of interfaces. An expressive interface allows users to communicate with the given system in a succinct, creative and flexible manner. This is a far cry from what GUIs permit. Things like iterative constructs, conditional decision making, inter process communication/piping, pattern matching, among several other techniques are things an expressive interface gives users for free that make GUIs look like childs play. Can we just stop pretending the GUI is meant to be any other thing than a higher level interface for common tasks and nothing more? When using an expressive interface, you are limited only by your imagination, not by widgets.
Edit: Well actually some GUIs provide what is usually called a “macro” system that allow you to perform/record repetitive operations, but this is still a far cry from the kind of contructs available in a shell environment.
Edited 2006-03-17 11:26
> Things like iterative constructs, conditional decision
> making, inter process communication/piping, pattern
> matching, […]
There is a simple word for all of this: programming. However, I see no reason why a program cannot be entered graphically.
I won’t necessary call it programming, because that entails a lot more. But the ability to batch sequence of commands in a rather casual manner and to control their flow or even perform basic pattern matching makes a shell environment a lot more expressive than a GUI. People insinuating shell environments are dated are misguided. And trying to turn a GUI into an expressive system is equally unwarranted.
> I won’t necessary call it programming, because that
> entails a lot more. But the ability to batch sequence
> of commands in a rather casual manner and to control
> their flow or even perform basic pattern matching makes
> a shell environment a lot more expressive than a GUI.
What exactly *is* your definition of programming then? Mine is: giving the computer (the description of) more than one command at a time, to make it work independent of me. This certainly includes command batches (more than one command) and patterns (a tool to have the computer make decisions for a batch of items, to decide which items match).
This kind of programming does give the CLI more power than the GUI, but it’s also a weakness. First, you have to extend the command interpreter to a full-blown scripting engine (look at bash, for example) to allow programming. It could be a better user interface without that burden (i.e. the programming part affects decisions about the user interface). Second, the scripting engine must be a good user interface. It could implement a better programming language without that burden.
My definition of programming is irrelevant. What matters is that we agree GUIs are not as expressive as shell environments. And in my opinion, there’s little reason to make them so.
> My definition of programming is irrelevant. What matters is that we agree
> GUIs are not as expressive as shell environments.
As you probably see, I don’t agree to this. I have shown you why. That’s all I can do.
I find it hard to believe that some people find pointing and clicking on widgets more expressive than programmable environments such as the shell terminal. I guess we just have to agree to disagree.
Graphic user interfaces are not expressive , period!
I do understand what you are getting at, but it is simply incorrect to state that GUI are not expressive interfaces. Were they not expressive at all, they couldn’t be used to anything whatsoever.
GUIs are indeed expressive; they’re just constrained by a rather impoverished language. For the most part, a standard WIMP type GUI can be said to consist of nouns (devices, files, etc..) and verbs (actions, programs, etc…). A “language” consisting of only nouns and verbs is capable of being used to express simple declaratives (eg., “open x with y” or “print x”). What GUIs can’t express, or rather what they can’t express very well, is the logical vocabulary required to express conditionals (eg., if x, then y).
What we don’t need to is try to make the GUI expressive, because by doing so, you make it slow, bloated, and unweildy.
All things in moderation.
Let’s say I’ve got a folder with hundreds of files of different types and I want resize the image files so that they are suitable for publishing on the web. This is, of course, very easily done with a CLI. But what if I only want to resize some of the images and those images I wish to resize cannot be identified by their respective filenames? That’s not so easily done with a CLI. On the other hand, I can navigate to the folder in Konqueror, filter the view by filetype (or with a regex from the filter text box), and then rely on the preview thumbnail funtionality of Konqueror to identify exactly which images I wish to resize, which can be accomplished by selecting them and then right clicking and selecting from the “Actions” sub-menu.
Generally speaking, I think there’s a lot of potential for hybrid CLI/GUI interfaces such as we are beginning to be see implemented in, for instance, Apple’s Spotlight, Beagle, or what’s been hinted at concerning KDE’s upcoming Tenor project.
I agree with the conclusion of your comment. And I already mentioned earlier that good applications brigde both GUI and shell-like commands to cater for the needs of users. However, this only happens when designers acknowledge the limitations of the GUI. Many people on here seem to believe the GUI is an evolutionary step from the CLI. It isn’t! They both serve entirely different purposes. The GUI is primarily a convenience interface (that should be) designed with the intention of limiting expressiveness. And I’m talking about real world pratical applications here, not sci-fi futuristic mumbo-jumbo.
Let me put it this way, pointing and clicking on widgets will always be less expressive than speaking or writing directly to a system. In my mind, GUIs should be designed to veil the complexities of the system from users. For users who can deal with the complexity a shell-like system can be exposed. My qualm is with some people who seem to think GUIs are going to evolve to be as expressive as shell-like environments. That’s just a pipe dream. The GUIs that try to do that today are complex, cumbersome and unweildy.
Many people on here seem to believe the GUI is an evolutionary step from the CLI.
It is. However, it’s also a complement to it. They are not mutually exclusive.
You are partly right. In some cases, command line is more expressive. However, that you can’t seem to understand that sometimes a GUI is not only expressive, but more expressive is.. well.. confusing.
No, GUIs are not expressive. I have yet to see a GUI that allows me to carry out the following expression:
Iterate through all the directories in this folder, and while you are it resize all the PNG files that are more than 5MB large to 400×300, only if the PNG file has meek in its name, after which pause for 30 seconds, email me to tell me everything went fine, then upload the images to a server pausing for 5 seconds between uploads.
That is “expression.” How many buttons will I have to click to accomplish that in any GUI?
Edited 2006-03-18 02:09
Ok, you picka specific example of expressiveness and say GUI is not expressive at all because it can’t do that as easily as CLI.
Wow, well done champ.
You are daft! I could give more and more examples of where a GUI falls short, but I’d be wasting my time.
And I gave you an example where CLI falls short. What’s the point? See my other comments about complementing each other.
No you didn’t. You gave me an example of a user cropping an image. That’s like me giving you an example of a user editing a text file.
Iterate through all the directories in this folder, and while you are it resize all the PNG files that are more than 5MB large to 400×300, only if the PNG file has meek in its name, after which pause for 30 seconds, email me to tell me everything went fine, then upload the images to a server pausing for 5 seconds between uploads.
Use a gui equivalent of ‘find’ (not hard to do), select all, right click and choose chain apply->resize image->upload, then enter in the required config information for the boxes that pop up for the resize and upload actions. I see no practicality in your 30 second delay, so I omitted it.
“””Use a gui equivalent of ‘find’ (not hard to do),”””
That would be?
“””select all right click and choose chain apply->resize image->upload,then enter in the required config information for the boxes that pop up for the resize and upload actions.”””
What app are you talking about here? Your file manager? The GIMP? PhotoShop? Your ftp client?
“””then enter in the required config information for the boxes that pop up for the resize and upload actions.”””
How many applications would I have to launch to achieve this. How many buttons would I have to click? And how is this expressive?
“””Use a gui equivalent of ‘find’ (not hard to do),”””
That would be?
Aside from the fact that this is purely hypothetical, there’s always gnome-search-tool.
What app are you talking about here? Your file manager? The GIMP? PhotoShop? Your ftp client?
In a well designed system this would be the search function of the file manager, although that’s not really pertinent to the main purpose.
And how is this expressive?
I don’t know, I was merely answering your question.
> No, GUIs are not expressive. I have yet to see a GUI
> that allows me to carry out the following expression:
Well then, carry out the following on a CLI:
In a folder with lots of pictures, select those pictures showing the scenery of (insert your favorite holiday place here), and tag them “scenery of ***”. The pictures are of course not yet tagged, or identifyable by file name or other metadata in any way.
In a GUI, I’d look at thumbnails, quickly selecting all that show what I want (look twice if there are other scenery pics in the same folder).
That task is not a measure of expressiveness. No interface can automatically do the work a human is supposed to do. I can’t expect the CLI to start randomly editing text files, or tagging images based on human aesthetics or subjective judgements, or analyzing the musical notes of the audio files that please me in my music library. It’s absurd to expect that from any interface CLI or not. The criteria given have to be exact, factual, measurable and objective for any programmable environment to function properly.
> That task is not a measure of expressiveness. No
> interface can automatically do the work a human is
> supposed to do.
I never said that the interface should do the work. It should only assist me when doing work. In the tagging example, the GUI assists me very well by showing thumbnails and allowing me to select them with a single click. The real work, i.e. looking at the pictures and deciding *which* to select, is always left to me. How does a CLI assist me in that example?
You don’t need a CLI to tag pictures. That’s what a restrictive, rigid and static interface like a GUI is useful for. CLIs become useful when you need to solve problems in an expressive manner e.g:
“Give me all the pictures I tagged yesterday that are 2MB
large, convert them to JPEG and place them in
/photos/jpeg”
Or you need to perform the same operation repeatedly over a large amount of data. Or you need to batch commands together. With a CLI you are not restricted by widgets, you are restricted by your imagination. I don’t know why anyone would want to tag pictures in a CLI, especially since Image editing is usually handle by specialized applications.
Edited 2006-03-18 17:05
That’s not expressive! You are limited by what the CLI wants you to do!
No, that’s what I want to do. The CLI allows me to do that, the GUI limits me from doing it.
The CLI limits me from doing a lot of things I want to.
I think you’re starting to get it now. Good
Right, it’s not great for “clicking” and “pointing”, I’d give you that.
It’s good for hitting keys.
That’s about it.
> Give me all the pictures I tagged yesterday that are
> 2MB large, convert them to JPEG and place them in
> /photos/jpeg”
I could imagine this even in today’s restricted point-and-click interfaces, not to mention the yet undiscovered possibilities:
history -> yesterday -> show by action -> tagging -> select target files
select subset -> by size -> at least [2 ] MB
convert -> JPEG
(go to /photos/jpeg)
paste
The only nontrivial feature needed here is that history, but you need that anyway if you want to select by modification date (same for CLIs).
Yes, you can do that with a GUI, but don’t cry when your users say your app is bloated, complex and unweildy. The overhead of constructing such a GUI infrastructure far outweighs its benefits, because GUIs should not be designed for that sort of stuff.
That’s called ‘search’
Besides that, I already proposed a method that does just this, yet he still seems to ignore that… I think you’re wasting your time; he’s obviously not the sharpest knife in the cupboard. Hell, he won’t even admit when he’s wrong.
For someone who mocks blunt knives, can “search” convert PNG files to JPEG?
It can in the same way ‘find’ can convert PNG files to JPEG–through an external tool.
Yeah, but CLIs support IPC more transparently than GUIs do. We could even argue find, mv, cp are external tools, but the CLI seamlessly veils this disparity. In a GUI I’d have to launch a seperate tool to convert all those images which further breaks workflow and tarnishes expressiveness. Sure GUIs have tried to do the COM/OLE thingy. In my opinion, it has largely been a failure at least compared to the efficiency with which a shell environment implements and executes IPCs. KDE is the closest GUI that has reached a level of IPC that I think is respectable. But even in KDE, the IPC still feels shell-like, so much so that dcop and kparts can be used directly from the CLI. It’s almost as if the GUI IPC is a wrapper around the CLI IPC.
On the CLI you also have to “launch” an external program. I believe what you were trying to say is open up another window and manually re-enter the files to modify. That’s not how it has to be done, and when I actually showed you how I did it, I used an “actions” submenu that automatically gives the program the correct data–all you have to do is take 2 seconds to enter in some configuration data at the dialog box.
Crap forget that example, let me give a simple example that I just used yesterday. The expression is as follows:
Convert all the spaces in file names in this folder to underscores.
Go do that with your “expressive” GUI.
CLI is better suited for that.
>>CLI is better suited for that.
Yes, that’s because it is “expressive.” It allows me to communicate with the system in a manner that is not “limiting” or “restrictive” by things like “widgets.” Do you understand what expressiveness means now?
oh no, you provided an example where CLI is better and suddenly you are completely right? Please.
You you understand what the word “expressive” means? Do you understand that CLI is limiting too?
No, the CLI is not limiting with regards to expressiveness. In fact, if you have been following this thread, my argument is that the CLI is actually more expressive than the GUI, that is if the GUI is expressive at all.
From a technical point of view, most GUIs are callbacks to a “restricted” set of commands often constructed by a programmer. You can’t sequence the commands, you can’t perform conditional operations on these commands, sometimes you can’t even repeat these commands, unless you click again, among many other limitations.
GUIs leave you at the beckon and call of the GUI designer, which is a good thing in my opinion, but at the expense of expressiveness. Most people have no need for expressive interfaces, but to argue the CLI is dated because we now have GUIs is silly and ignorant.
Once again, you seem to have missed the point. You can’t use concrete examples as definite proof that one abstract concept is better (“more expressive”) than another abstract concept. There is nothing intrinsic in said concepts that would lead to the conclusion that one is more expressive than the other, and even if there was, the only way to prove it would be to do so on theoretical terms. If you don’t get it, fine, that’s not my problem, just don’t keep repeating the same tired idea over and over again that has been proven wrong!
>>>Once again, you seem to have missed the point.
Which is?
>>>You can’t use concrete examples as definite proof >>>that one abstract concept is better (“more >>>expressive”) than another abstract concept.
If concepts can’t be proven, they are worthless.
>>>There is nothing intrinsic in said concepts that
>>>would lead to the conclusion that one is more
>>>expressive than the other, and even if there was,
>>>the only way to prove it would be to do so on
>>>theoretical terms.
Are you farking kidding me? I call BS that statement. First of all, what concepts are you talking about? I’m talking about expressive interfaces. Interfaces that allow users to control the flow of instructions they pass to a system in an extremely casual and flexible manner.
We are talking GUI versus programmable environment. No these aren’t concepts or theories. This how people use either environments today. There’s nothing to prove. What? You want me to proof to you that a programmable environment such as the CLI is more expressive than a GUI. I already gave 2 very basic examples above that prove the expressiveness of shell environments. You just can’t do that with a GUI without jumping through hoops.
>>>If you don’t get it, fine, that’s not my problem,
Yes, I don’t get it, and you are not convincing either.
>>>just don’t keep repeating the same tired idea over
>>>and over again that has been proven wrong!
What have I been proven wrong about? That a programmable environment is more flexible and thus more expressive than a GUI?
If concepts can’t be proven, they are worthless.
Please read my entire post before responding:
the only way to prove it would be to do so on
theoretical terms.
Are you farking kidding me? I call BS that statement. First of all, what concepts are you talking about? I’m talking about expressive interfaces. Interfaces that allow users to control the flow of instructions they pass to a system in an extremely casual and flexible manner.
We are talking GUI versus programmable environment. No these aren’t concepts or theories. This how people use either environments today. There’s nothing to prove. What? You want me to proof to you that a programmable environment such as the CLI is more expressive than a GUI. I already gave 2 very basic examples above that prove the expressiveness of shell environments. You just can’t do that with a GUI without jumping through hoops.
*sigh* Think about it this way. A GUI is simply a 2 dimensional interface using a mouse/keyboard. A CLI is a 1 dimensional interface using a mouse/keyboard. Assuming more than that is assuming too much.
>>>*sigh* Think about it this way. A GUI is simply a 2
>>>dimensional interface using a mouse/keyboard. A CLI
>>>is a 1 dimensional interface using a mouse/keyboard.
>>>Assuming more than that is assuming too much.
I don’t see how the dimension of the interfaces relate to the issue at hand. I could also add that most console games have GUIs with 3 dimensional interfaces using a controller. But this does not bring anything to the table, other than stating the obvious.
A GUI has more to work with, therefore it has more potential. You obviously don’t get it, so bye. I hope you’re not so dense in other areas of your life…
>>>A GUI has more to work with
Such as?
There is no difference between running a shell in an xterm on X11 and running one on the virtual consoles other than what video mode the graphics card is set to. Obviously, the X11 server has a lot better output flexability.
If you don’t want the desktop environment, don’t run one. There is nothing that requires one to run Gnome or KDE on X11. I would suggest that you look into one of the tiling window mangers such as Ion.
If you have poor eye sight, the fonts on an xterm are easy enough to enlarge: e.g. xterm -fa luxi-40 😛 In fact, this is going to be a hell of a lot better resolution wise than you’re ever going to get using a VESA text mode.
Edited 2006-03-17 00:07
A little bit of both is quite comfortable.
i would love to do this on my vaio. if only gpm would work with the touchscreen. I have tried recompiling gpm with the evdev patches but it doesn’t seem to work.
It entirely depends on who you are and what you want to do, surely? What makes you happy? I don’t want to learn all of vim so I use kate, and because I’ve got to know it well I am quite content the stuff I do on it. When I need to change a config file, I will use vim, though, because the changes are usually small and simple.
In the same way, some folks will really like amarok and find its gui a lot easier than typing commands into some CL player. Or, pulling files from different places into k3b to burn a disk. What a hassle typing all that out when you can just click and drag.
Some folks don’t want to think about the underlying structure of their OS at all, they just want to use it. That’s fine too. It doesn’t mean they are dim, only that they don’t accord using a computer nearly such a high prirotiy as the next person.
Overall, using only the command line seems to be inflicting rather pointless limits on yourself. That is fine if the stuff you do is well suited to a command line mode and you are satisfied. But it is pretty mad when the stuff is not, like web-surfing, DTP of the Scribus kind or editing photographs.
Someone said to me, “Yeah *nix beats Windows hands down unless I want to write a paper, surf the web, or play a video game…”. Well, the point was well taken.
1) Writing a paper – sure, Word rocks and revolutionized all aspects of paper pushing. I don’t expect Nancy in HR to learn LaTex or Bob in accounting to learn Gnuplot to show his latest sales forecasts. Simply put, “GUI”s have brought computing to the masses. HOWEVER, most hardcore users wouldn’t consider editing /etc/rc.conf with AbiWord an option. For them vi is the only way to go. Same for Dr. Paul writing his Turing Award winning paper in LaTex. These CLI tools take a user to a much higher level of “computer saavy”.
2) Surf the web – if you are even reading this, then you know that the web is not an MS only experience. Its rich content, however is best viewed via a GUI browser. Pretty pictures, nice colors, etc are much nicer than staring at Lynx. HOWEVER, for most hard core CLI’ers, the web experience only starts with a web browers. For most, it is about ssh’ing, irc’ing, nmap’ing, etc.
3) Games – well, for most GUIs are required. Infact, you need MS or a console for most serious games. HOWEVER, many would swear that the old text based games are much more satisfying intellectually, etc. I can’t speak much about this, though, bc the last game I played was Wolf 3d. Nowadays it is all *BSD, vi, and Perl
.
As far as GUIs being more expressive or powerful than CLI, I must laugh at the notion. By definition, a GUI is a monolithic monstrosity that defines a small subset of what you are able to do on your computer. After 20 years, MS is finally admitting this by putting some effort into their own CLI interface. Why? Because a GUI simply can not give you the flexibility and power that the ability to string commands together at the CLI gives you. I am willing to bet all the tea in china that a CLI saavy user can be more efficient and productive in most tasks than the quickest double clicker in the West. There are some applications that lend themselves to GUIS, as discussed above. But really taking advantage of your computer’s capabilities requires the flexibility, neigh the virtually unlimited solution space that CLI provides a user.
In conclusion, there is one GUI application that is at most as powerful as any CLI environment – that app is a terminal editor like xterm, aterm, and the like. The point is that in order for a gui to be as effective as a terminal, it must be a terminal too
.
1) So your “hardcore users” group are mostly using old, primitive tools because they think it makes them superior?
2) Makes no sense. Oh, those “hard core” people aren’t “hard core” enough to know that those aren’t web tools.
3) So you prefer old games so you could feel smart, therefore the terminal is superior to the GUI?
By definition, a GUI is a monolithic monstrosity that defines a small subset of what you are able to do on your computer.
Using text mode, you are using an even smaller subset of your computer. And “monolithic monstrosity” WTF?
After 20 years, MS is finally admitting this by putting some effort into their own CLI interface. Why?
No, Microsoft is admitting no such thing. A CLI is a very good complement to the GUI. Automation is much easier.
Because a GUI simply can not give you the flexibility and power that the ability to string commands together at the CLI gives you.
No, you don’t have to type commands and this is what makes a GUI superior to 99% of us humans. And more powerful.
I am willing to bet all the tea in china that a CLI saavy user can be more efficient and productive in most tasks than the quickest double clicker in the West.
So productivity should have gone down drastically from the days of text-only terminals to nowadays GUI tools? A whole f–klot of people wouldn’t even be using a computer if it only had green letters and black background.
I don’t think I could find a single thing in your post that made sense.
I have some objectons:
“Simply put, “GUI”s have brought computing to the masses. HOWEVER, most hardcore users wouldn’t consider editing /etc/rc.conf with AbiWord an option.”
It’s not about being hardcore or newbie, publishing a paper is an entirely different thing than editing a conf file.
I would rather use an hex editor than Abiword to edit a conf (or to patch an executable) since I’ll definitely need perfect control on single bits I edit, not the ease of managing a publication!
Publishing a paper with an *extremely hardcore* hex editor would not be cool, it would be fool… likewise trying to open an executable and patch a byte at a certain offset with Word…
“By definition, a GUI is a monolithic monstrosity that defines a small subset of what you are able to do on your computer.”
The CLI too (well, ok, it’s definitely lighter).
An interface is simply a program that try to give tools to the user to control (pass parameters, inspect state) other programs.
“Because a GUI simply can not give you the flexibility and power that the ability to string commands together at the CLI gives you.”
It’s simply not true.
Programs communicate, with the user (or more properly, with the interface) and to each other, in a plethora of ways, not only trough strings of parameters; the interface is only the mean that informations are entered by the user or are told to the user, the communication layer is an entirely different thing!
By the way, for some communications, i.e. when you need to pass binary data, it would be crazy to use strings (intyernally in the program, an externally to coomunicate).
In the sense of passing parameters to programs, a GUI (also non *x) program is able to mangle parameter string in the same way as a CLI program does (and from the programmer’s point of wiew, the code to use to get those parameters is the very same).
In the sense of giving meaningful output, a GUI program may access the very same communication layer options af a CLI program, including opening a CLI session if the proper libraries are present (practically always), and nothing prevent the CLI to do th same, including starting a GUI session if proper libraries are present.
However, in my experience CLI use tend to give a cleaner approach to authomatization.
In synthesis, GUI and CLI are two very different hinstruments and with today’s computing power they should be used from the average Joe without discarding any advantage of each of the two options.
I can understand that you could save power because the background of a VT is black, most CLI apps require far fewer cycles to execute, and there are generally fewer processes running at a given time. But really, how much power savings does this amount to?
If you RTFA, you’ll find out. As a matter of fact, it’s the first link in the article. Actually the second sentence in the piece — you don’t even have to read very far.
Wow, hi, I’m a human being. No need for the tone. I read the article. I didn’t know it was a link. The link is the same color as the text under Konqueror. Sorry. How about you flame me? I think I’ve earned it.
Hmm, on top of that, the linked article is longer and more detailed than necessary to answer the question I asked.
People passing by your desk will think you’re some kind of computer god.
I certainly won’t be one of those people.
Allow me to elaborate – from the article:
“Leaving the GUI doesn’t necessarily mean that you’ll be leaving your mouse behind, too. It’s certainly an option to ditch the mouse, but copying and pasting blocks of text is much easier with one.
[…]
To copy and paste text, right-click a word to select it, or click and drag to select lines of text. Once you have everything selected, move the text cursor (not the mouse cursor!) to the place where you would like the block to be pasted, then move the mouse cursor to the same place and click both the right and left mouse buttons at the same time.”
???
The right tool for each job. The terminal some times, the GUI others. Both usually.
Edited 2006-03-17 04:13
what would be interesting would be to run a CLI window inside a GUI where the CLI had the brains that when a GUI app was launched from the CLI the CLI would then be freed up to be used again.
allso, the CLI windows should have a hotkey so that it could be brought to front instantly…
another interesting bit would be if one was able to send CLI commands to existing GUI windows. that way one could say stuff like:
firefox tab new http://osnews.com
and get firefox to open osnews in a new tab
hell, lets not forget that since the days of quake 1, a console have been a fixture in all first person shooters…
with good command conpletion (complete with option completion) things get realy interesting
Edited 2006-03-17 04:42
“…what would be interesting would be to run a CLI window inside a GUI where the CLI had the brains that when a GUI app was launched from the CLI the CLI would then be freed up to be used again…”
firefox &
leafpad &
xchat &
worker &
something.likethis &
…Not what you meant?
im fully aware of the & and what it does.
thing is that it should happen automaticaly, rather then be forced by a special character at the end of the command…
ie, the CLI should detect that it have a GUI app on its hands and just send it to the background at ones…
What if I don’t want it in the background? I prefer to tell my computer what I mean rather than have it guess. Maybe that’s just me…
“…allso, the CLI windows should have a hotkey so that it could be brought to front instantly…”
Sorry, forgot to also mention something called “yeahconsole”. You mentioned Quake 1, so you’ll probably understand right away what yeahconsole is. You press Ctrl+Alt+Y (or some other combo, you can set it iirc) and the terminal drops down similar to pressing ~ in Quake.
Neat stuff.
sounds promising.
but last time i checked, osnews now allows for editing of comments
on Amiga:
GUI app was launched from the CLI the CLI would then be freed up to be used again
run <program>
another interesting bit would be if one was able to send CLI commands to existing GUI windows.
ARexx
On *nix you might use FVWM windowmanager and FvwmConsole CLI:
http://www.osnews.com/story.php?news_id=9772&page=2
http://www.fvwm.org/documentation/manpages/unstable/FvwmConsole.php
i have been looking at that fvwm. reminds me a lot of lightstep for windows
ie, the CLI should detect that it have a GUI app on its hands and just send it to the background at ones…
That’s a pretty good idea, but I can see some pretty big “issues” with autodetecting a GUI.
I’m definitely not a theoretical CS genius, but knowing whether an app is a GUI would seem to be very similar to the halting problem. How can you tell if it ever calls the window creation function? What about scripts? What if it depends on the command line arguments? What if it uses a random number to determine if it opens a window? What if it only opens a window when it’s the first instance running, and otherwise acts as a log viewer? They’re made up examples, but it’s not hard to think of situations where it’d be a real issue.
An alternative would be a database of commands/programs that open windows in /etc or something, but that has issues too. “firefox” opens a window, but “firefox –version” doesn’t.
Adding ” &” on the end of the command is 1000x easier than solving all those problems. It’s 2 characters, and if it’s that much of an issue, you can always put alias whatever=”whatever &” in your startup scripts
thats why it would work best in combo with say the ability to take arguments after the fact (my firefox new tab example)…
all in all your problems are mostly one of communication, not between the app and the cli, but between the cli and the gui manager (alltho it can allso be between the app and the cli).
its all the same prosess, so if ever a window is drawn based on a started prosess, the gui manager tells the cli that it happens and the cli puts the prosess into the background.
alternativly the app tells the cli that it wants to run in the background. this signal can be sendt whenever a window is created…
well there is allso the ctrl+z combo, that will send any console hogging prosess to the background. problem is that it allso tells the prosess to suspend operation iirc.
but i was not realy looking at it from a unix standpoint but from a concept standpoint. as in something buildt from scratch to have this ability…
im starting to see the problems of X11, its basicly living its own life. still, i have allways loved the idea of the GUI being a prosess running on top of the kernel rather then being part of it like we see in windows. it allows so much flexibility…
Once you suspend a task with Ctrl-z, you can tell it to resume execution in the background with the ‘bg’ command. The equivalent ‘fg’ command resumes execution in the foreground.
You can also tell bg and fg to act on a particular job–e.g., ‘fg %1’ would bring job 1 to the foreground.
im aware of said commands, problem is that not everything enjoys being suspended with the ctrl-z…
The only reason run X, is to have more terminals at once
(without screen and diffrent ttys)
> The only reason run X, is to have more terminals at
> once
(without screen and diffrent ttys)
splitvt
Or some TUI windowmanager like Twin maybe:
http://linuz.sns.it/~max/twin/
From your twin link:
Twin is a text-mode windowing environment: it draws and manages text windows on a text-mode display, like X11 does for graphical windows. It has a built-in window manager and terminal emulator, and can be used as server for remote clients in the same style as X11. It can display on Linux console, on X11 and inside itself.
This reminds me of Quarterdeck Desqview, which was a text-mode window manager that was very popular before Windows became stable enough to use.
Back in about ’90 I could simultaneously compile software in one window while downloading something in another while having absolutely no delay to my text editor (PCWrite) in a third window on a 20MHz 386. All three windows were DOS shells of course.
It was some years before PCs became fast enough for any GUI to compete with Desqview.
Hum, we should remember that there is no magic under the CLI, as ther is no magic under GUI.
People thinking that CLI gives a “privileged” view on what is going on into the system should remember that programs can do hundreds things without prompting anyting to stdout or stderr, and can be told to do things in many ways without leaving tracks on the CLI history.
CLI is not like having a sort of magic switch panel that tell to the enlighteneed every single bit that the system is processing… if you need that level of control of all parameters executed and all computation results about what is running on your system you should carefully debug the programs with proper tools, needing programming know-how and of course needing specific knowledge of what the program is doing and what kind of behaviour you are about to track!
CLI is just another program that is running trying to tell to the user useful things about what’s going on in the system and trying to provide him/her handy tools to interact with the other programs in the ways the programmers of the CLI and of the other programs allowed.
In other words, CLI is a metaphore as GUI is, each other with many advantages and many disvantages, since they are simply different.
The prejudice that CLI gives a “superior” control is probably due to the fact that novice now start with GUI and after gathering some basic experience usually end up forcing GUI in doing things that would be done better from CLI and after many frustrating results often switch to the “magic” CLI.
My opinion, (I started and grew up with CLI and actually use boot CLI and GUI system), is that CLI give a cleaner approach to (simple) authomation, while GUI simply give more powerful mataphores of resource structure and of what’s running on the system.
Probably boot GUI and CLI are not suited at best for modern computing paradigms where the PC is led to be a media center, as shown by newer media-center oriented interfaces that even if being actually called GUI really purpouse a radically different approach to files (“contents”) and programs.
The prejudice that CLI gives a “superior” control is probably due to the fact that novice now start with GUI and after gathering some basic experience usually end up forcing GUI in doing things that would be done better from CLI and after many frustrating results often switch to the “magic” CLI.
Ehh, I started on the DOS CLI. I however find WIMP to give me more control than *nix CLI due to discoverability and me being noob once more when it comes to *NIX CLI’s.
I just like to use my computer with minimum hassle. I don’t care if someone thinks I’m a computer god.
Show me a video window playing my movie, while I talk on IRC, along with two MSN windows and my e-mail, and I may consider a terminal as an alternative to the OS X GUI for my usage patterns.
What a silly article. I actually laughed when I read about “power savings”.
To me it’s simple,
Server + Freebsd = use CLI only. Boots very fast and you can configure everything the way you want just by editing some configuration files. And most of the times you use a ssh client to connect to your server which has excellent CLI support.
Desktop PC = Use a gui. You want to browse the web in full color + images right? (or is someone browsing this site right now in lynx?) You want to be able to play movies on your pc right? Those things simply need a gui to work properly.
Soon after the Matrix came out, I would set my terminal background to green text on a black background, and start compiling a kernel whilst looking intently and the screen watching lines unintelligible by me go by. You would be amazed how many people though I knew what was actually going on.
But I have found numerous time that CLI is usually very useful, even though my knowledge of bash et al is limited.
Case in point. I am yet to find a more useful ftp client than ncftp on any platform.
My favourite tool on a network would be a toss up between wget and gnu screen. in fact, together, these made quite a formidable combination. Can you say integrated download manager.
Cli can be very useful, but you do have to learn. but mostly, I have discovered you only need to learn enough to begin using it, and the rest will come rather naturally.
Yes, I agree the CLI can make you more productive, but only in some cases. And when is that?
1. That’s only when you do not need true graphics. I.e. when programming, scripting or doing some other file manipulation like copying them around etc. I mean what about web browsing, watching a movie or photo-editting. I guarantee you that it’ll be very tough (ok watching a movie can be done in the framebuffer, but what about editting one?).
2. OR if there’s no first class GUI app available. I believe a GUI does not inherently make you less productive. I actually believe that it has a higher potential than the CLI. It’s just that most GUI apps are geared toward less knowledgable users. And that is the reason most GUI apps are less powerful than their CLI counterparts. Not because of the GUI itself, but because of the focus of most GUI apps.
Maybe some of you should take a course in causal logic 🙂
I would like to disagree.
It is not easy to psuedo-program a GUI. In fact, trying to create a GUI that does that is not efficient. Hence, in Excel, if you want to script something, it means writing some VBA.
This does not mean there are no instances where a GUI is better than using CLI. The CLI interface lends itself well to certain tasks or methods. For instance, scripting. It is hard to scipt GUIs and hard to create scriptable GUIs.
I do not need a gui to resize image files for instance, or to encode audio files. I can do that from CLI. For instance. If I want to edit pictures or movies, then that is another story altogether.
There are GUIs that are only geared to knowledgable users. Try using avidemux to create a VCD compliant video stream. It is much faster to use the command line though, and this also makes the process scriptable.
A GUI lends itself well to ‘dynamic’ control. Where you want to change parameters on the fly, play and pause a video, crop an area from an image.
When you want to download an iso from an ftp site, wget is no frills simplicity.
GUIs are good for limited functionality. You start adding a lot of functionality, GUIs become too busy. Can you imagine a GUI which does what the rpm/rpmbuild program on Linux does. In many cases, people end up giving you a pseudo-commandline in a GUI app to enable you to do qwhat you can do with the commandline.
Yakuake perfectly fits my needs:-)
When I was learning to use NetBSD in 2002, I installed a console only system, to force myself to learn the command line. I loved the command line but I quickly found the dimensional limitation of the console (80×33) annoying, so I installed X but run it without a window manager.
Everything was set up and laid out via ~.xinitrc. You can see an old screenshot of it here (not safe for work):
http://static.flickr.com/38/87430482_d1dd52246e_o.jpg
I still love the command line today, even though I now use Mac OS X.
I’m not sure that copy/paste some text and viewing graphics covers my need. Is there a sequel?
…with Mystilleef here. A gui by design restricts you to ‘express’ what the designer thought you would need to ‘express’. CLI does not give you such limitations.
I gave an example of the rpm program on many Linux distributions. Together with other command line apps, you can construct the most imaginitive of expressions to tell the computer what to do. You can tell the computer to search for and find every rpm file you downloaded in the past week, and update the rpms on your system as long as the there is a previous rpm installed. In a GUI, someone basically has to have imagined you would need to do that for you to be able to do it.
> A gui by design restricts you to ‘express’ what the
> designer thought you would need to ‘express’. CLI does
> not give you such limitations.
A CLI is also limited by what the designer thought you want to express, very much the same way a GUI is. Some things are simple to express in a CLI: those that the designer thought will be frequently used. Others were considered less important by the designer and thus need you to go through several loops to complete. Same for GUIs: You *can* do everything with both a CLI and a GUI, so the discussion can only be whether the frequently used features are easy to express.