Disagree. Anything that can be done with terminal can be done with a GUI, you just need to be good at UX. Most programmers I know are pretty bad at UX, and program for themselves, not the user.
Edit, just to clarify (because I know some of you will feel personally attacked): I’m not saying a GUI may be better, or more efficient than a CLI, I’m just saying that it can be done. And as an example, see 3D shaders in modern programs, that need no code at all and are purely visual. That was unthinkable some years ago.
That’s just not true. Not without lots of hand waving.
In my terminal I can, and pretty much hourly do, combine many programs in chains of input and output to perform specific tasks and get information I need. And that’s how these programs are designed to be used. The programmer builds it to do specific things and then the user can combine the program with others in novel and nearly endless ways.
With a GUI, sometimes that’s possible between two programs if you can copy/paste between them but it’s much less reusable and a lot more tedious. But usually it’s just not possible because they’re designed for specific user personas and not as general purpose tools that may be part of a script.
Well, seeing the progression of 3D programs and how a lot of complex operations are nowadays done in a visual way, I guess we won’t agree on this one, I guess.
But I affirm in my conviction that anything can be made with a GUI. It may be difficult to reach a suitable GUI, with a lot of back and forth, and probably a lot of user feedback, but with a good methodology and a good understanding of UX, it can be done.
Generally I would agree that anything can be made with a GUI with enough investment. But the point where diminishing returns don’t give enough return on GUI investment are reached much sooner than a scriptable shell environment where a power user can extend it in ways that would only make sense for that power user or a very small number of users.
Oh! I’m in no way discussing the viability or economy of it. Of course in a lot of cases, creating a batch process, for example, may be the better choice. And I would also say that in some cases, using a CLI may be way more efficient that creating a GUI for something.
My statement is just that it can be done. Nothing more.
And in some cases, it’s not even that hard, it’s just that maybe people are used to do things using terminal. Or there may be other reasons. Who knows? But I would like for programmers to, at least, consider the option in some cases. You may be surprised at the things that can be achieved with a good GUI, and how it helps less tech-savvy users.
To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so don’t often do the work to keep things interoperable. That and the use cases from users on phones don’t frequently involve cross app functionality. But the ability is powerful for apps to say “my app needs a user photo” or one of my faves “my app needs a pgp provider (for the password store app)” and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
Are you talking about sending the output of one process to the input of another?
I think the shaders I’ve mentioned are a great example of that: you do something in a block, then send the result to the input of another block.
Sorry if it’s not what you mean, but my point is that, with some effort, you can create a visual representation of even the most abstract concepts. Physicists do this constantly. If we can make a visual representations of 4D, for example, what prevents us from doing the same for programming logic? Or for commands?
Agreed. But that’s not my point. My point is that it can be done.
And in some cases, even if it’s less than ideal, and is way more cumbersome than using a CLI, you are helping non-tech-savvy people do things they couldn’t do any other way.
Put those two statements together and the logical conclusion is that Linux users simply want everybody to be tech-savvy (although I’d use a different term: computer-literate). What’s wrong with that?
Not everyone has the same interests. All car people would love everyone to be car people. All bikers would like everyone to ride bikes. The difference is that you pretty much need to be interested in computers to run Linux.
It’s not about having the same interests; it’s about the fact that the single distinguishing factor between a computer and any other mere machine is its ability to be programmed, and you therefore don’t really know how to use a computer unless you can create novel workflows to solve your own novel problems. If you can’t script, you aren’t literate in the 21st century.
All car people would love everyone to be car people. All bikers would like everyone to ride bikes.
It’s funny you should use those particular examples, (and not just because they also happen to be things I’m particularly passionate about).
In particular:
If you live somewhere that’s built wrong (i.e. is car-dependent) and you can’t drive, you’re homebound. It’s not about being a “car person;” it’s about the skill being necessary to function.
Conversely, places that aren’t built wrong are precisely those that facilitate cycling as a matter of design and policy. It’s not about what “bikers would like;” it’s about what empirically works best for a functioning city.
Nobody capable of defining an algorithm in a visual flowchart like that isn’t also capable of doing it in a CLI (or at least, in text in general – writing a script). It’s thinking through what you want to happen that’s the hard part; expressing it in the UI is trivial in comparison.
Some people have problems remembering commands, for example. And it’s easier for them if they can see it.
Yes, you can teach a kid to program (with some effort), but there’s a reason why Scratch presents logic units with shapes and colors and a GUI.
There are many reasons why a visual representation may be easier to grasp than just resorting to memory and remembering abstract concepts.
I mean, do you remember everything that you write? You’ve never had to visit Stack Overflow to remember how to do something, because you forgot the exact syntax of an operation? Now, how about if I put things visually in front of you? What would be easier?
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don’t need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there’s no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I’m not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
'Course, there’s a reason those things basically never catch on, which is that they don’t actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it
But I’m not talking about programming languages, I’m talking about CLI programs, or system commands.
And I’m not telling a GUI would be better, or more efficient, I’m just saying that it can be done (something you are saying too about programming languages).
That’s the point: a GUI can replace a CLI. Is it better? Sometimes it is, sometimes it isn’t. Is it possible? Absolutely.
I would assert that basically every shell I’m aware of is also a programming/scripting langauge, able to handle things like loops and branches. This is possible to do in a GUI but it’s kind of telling no one has achieved this in a desktop environment to any significant degree, including in the Linux space.
“Iterate over all of the files in this folder, if it’s a video file of any format, create a folder with the same name as the video file in ~/Videos and move the file there.” I’m unaware of an OS desktop environment that can do even that level of automation with default GUI tools. It’s like 5 lines of Bash including “done;” at the end. You can probably do it in PowerShell, but I bet Windows power users would rather use AutoHotKey for this.
You really can’t imagine doing that with a GUI?
Here you have something to give you an idea (sorry it’s in Spanish, but I guess you can get an idea of how it may work):
Here I’m selecting a specific type of files (PDFs, but I can select several different types, as I’m organising by file type), after which I did a right click, and selected a contextual action that shows a popup to do a following action. In this case it’s renaming, but it could easily be a “Move to…” that could include a check option of “Create a folder for each file”.
I mean, it was actually pretty fast too. It’s not that difficult.
It wouldn’t make sense to add clutter to a GUI that benefits a tiny fraction of users a tiny fraction of the time while making the experience worse for everyone else.
I can imagine making a GUI that does it. But most aren’t able to. “That could include a check option of…” yeah it doesn’t though, is my point. GUIs are for doing things manually.
That’s your opinion, and I disagree with it. It takes a lot of abstract thinking to synthesize an action in a visual way, like an icon.
Designers are good at lateral thinking, and founding visual ways of representing abstract concepts (and you can’t represent something visually if you don’t understand it first).
You can have your GUI do anything a terminal can I guess, but you’d need a few million buttons on that gui where the programmer has anticipated each and every combination of CLI command that you are going to use, encoded that to a button or menu, included text entry boxes for each variable and have bundled every program, application and dependency that has ever existed. Totally possible.
Disagree. Anything that can be done with terminal can be done with a GUI, you just need to be good at UX. Most programmers I know are pretty bad at UX, and program for themselves, not the user.
Edit, just to clarify (because I know some of you will feel personally attacked): I’m not saying a GUI may be better, or more efficient than a CLI, I’m just saying that it can be done. And as an example, see 3D shaders in modern programs, that need no code at all and are purely visual. That was unthinkable some years ago.
That’s just not true. Not without lots of hand waving.
In my terminal I can, and pretty much hourly do, combine many programs in chains of input and output to perform specific tasks and get information I need. And that’s how these programs are designed to be used. The programmer builds it to do specific things and then the user can combine the program with others in novel and nearly endless ways.
With a GUI, sometimes that’s possible between two programs if you can copy/paste between them but it’s much less reusable and a lot more tedious. But usually it’s just not possible because they’re designed for specific user personas and not as general purpose tools that may be part of a script.
Well, seeing the progression of 3D programs and how a lot of complex operations are nowadays done in a visual way, I guess we won’t agree on this one, I guess.
But I affirm in my conviction that anything can be made with a GUI. It may be difficult to reach a suitable GUI, with a lot of back and forth, and probably a lot of user feedback, but with a good methodology and a good understanding of UX, it can be done.
Sad we can’t agree. Cheers.
Generally I would agree that anything can be made with a GUI with enough investment. But the point where diminishing returns don’t give enough return on GUI investment are reached much sooner than a scriptable shell environment where a power user can extend it in ways that would only make sense for that power user or a very small number of users.
Oh! I’m in no way discussing the viability or economy of it. Of course in a lot of cases, creating a batch process, for example, may be the better choice. And I would also say that in some cases, using a CLI may be way more efficient that creating a GUI for something.
My statement is just that it can be done. Nothing more.
And in some cases, it’s not even that hard, it’s just that maybe people are used to do things using terminal. Or there may be other reasons. Who knows? But I would like for programmers to, at least, consider the option in some cases. You may be surprised at the things that can be achieved with a good GUI, and how it helps less tech-savvy users.
How would you implement piping in GUI?
Could you show us an example program with a GUI you created for this?
To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so don’t often do the work to keep things interoperable. That and the use cases from users on phones don’t frequently involve cross app functionality. But the ability is powerful for apps to say “my app needs a user photo” or one of my faves “my app needs a pgp provider (for the password store app)” and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
Are you talking about sending the output of one process to the input of another?
I think the shaders I’ve mentioned are a great example of that: you do something in a block, then send the result to the input of another block.
Sorry if it’s not what you mean, but my point is that, with some effort, you can create a visual representation of even the most abstract concepts. Physicists do this constantly. If we can make a visual representations of 4D, for example, what prevents us from doing the same for programming logic? Or for commands?
Yeah, and doing this would take significantly longer to use every time than typing up a chain of commands in a terminal.
Agreed. But that’s not my point. My point is that it can be done.
And in some cases, even if it’s less than ideal, and is way more cumbersome than using a CLI, you are helping non-tech-savvy people do things they couldn’t do any other way.
Linux users: Non tech savvy people? Yuck
Also Linux users: Everyone should be running Linux instead of Windows!
Put those two statements together and the logical conclusion is that Linux users simply want everybody to be tech-savvy (although I’d use a different term: computer-literate). What’s wrong with that?
Not everyone has the same interests. All car people would love everyone to be car people. All bikers would like everyone to ride bikes. The difference is that you pretty much need to be interested in computers to run Linux.
It’s not about having the same interests; it’s about the fact that the single distinguishing factor between a computer and any other mere machine is its ability to be programmed, and you therefore don’t really know how to use a computer unless you can create novel workflows to solve your own novel problems. If you can’t script, you aren’t literate in the 21st century.
It’s funny you should use those particular examples, (and not just because they also happen to be things I’m particularly passionate about).
In particular:
If you live somewhere that’s built wrong (i.e. is car-dependent) and you can’t drive, you’re homebound. It’s not about being a “car person;” it’s about the skill being necessary to function.
Conversely, places that aren’t built wrong are precisely those that facilitate cycling as a matter of design and policy. It’s not about what “bikers would like;” it’s about what empirically works best for a functioning city.
Nobody capable of defining an algorithm in a visual flowchart like that isn’t also capable of doing it in a CLI (or at least, in text in general – writing a script). It’s thinking through what you want to happen that’s the hard part; expressing it in the UI is trivial in comparison.
Some people have problems remembering commands, for example. And it’s easier for them if they can see it.
Yes, you can teach a kid to program (with some effort), but there’s a reason why Scratch presents logic units with shapes and colors and a GUI.
There are many reasons why a visual representation may be easier to grasp than just resorting to memory and remembering abstract concepts.
I mean, do you remember everything that you write? You’ve never had to visit Stack Overflow to remember how to do something, because you forgot the exact syntax of an operation? Now, how about if I put things visually in front of you? What would be easier?
I’ve probably spent more time looking up how to access specific functions in a GUI than for CLI.
Wow, you created this program for creating shaders visually? That’s impressive! You mind sharing the source code?
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don’t need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there’s no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I’m not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
https://en.wikipedia.org/wiki/Automator_(macOS), or in general, https://en.wikipedia.org/wiki/Visual_programming_language
'Course, there’s a reason those things basically never catch on, which is that they don’t actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it
They tried to replace programming languages with drag-and-drop toolkits too. It can be done, but sometimes there’s a reason we don’t do it.
But I’m not talking about programming languages, I’m talking about CLI programs, or system commands.
And I’m not telling a GUI would be better, or more efficient, I’m just saying that it can be done (something you are saying too about programming languages).
That’s the point: a GUI can replace a CLI. Is it better? Sometimes it is, sometimes it isn’t. Is it possible? Absolutely.
I would assert that basically every shell I’m aware of is also a programming/scripting langauge, able to handle things like loops and branches. This is possible to do in a GUI but it’s kind of telling no one has achieved this in a desktop environment to any significant degree, including in the Linux space.
“Iterate over all of the files in this folder, if it’s a video file of any format, create a folder with the same name as the video file in ~/Videos and move the file there.” I’m unaware of an OS desktop environment that can do even that level of automation with default GUI tools. It’s like 5 lines of Bash including “done;” at the end. You can probably do it in PowerShell, but I bet Windows power users would rather use AutoHotKey for this.
You really can’t imagine doing that with a GUI? Here you have something to give you an idea (sorry it’s in Spanish, but I guess you can get an idea of how it may work):
Here I’m selecting a specific type of files (PDFs, but I can select several different types, as I’m organising by file type), after which I did a right click, and selected a contextual action that shows a popup to do a following action. In this case it’s renaming, but it could easily be a “Move to…” that could include a check option of “Create a folder for each file”. I mean, it was actually pretty fast too. It’s not that difficult.
It wouldn’t make sense to add clutter to a GUI that benefits a tiny fraction of users a tiny fraction of the time while making the experience worse for everyone else.
I can imagine making a GUI that does it. But most aren’t able to. “That could include a check option of…” yeah it doesn’t though, is my point. GUIs are for doing things manually.
Most programmers are bad at UX but not nearly as bad as GUI designers are at understanding abstraction.
Most programmers are bad at both lol.
That’s your opinion, and I disagree with it. It takes a lot of abstract thinking to synthesize an action in a visual way, like an icon.
Designers are good at lateral thinking, and founding visual ways of representing abstract concepts (and you can’t represent something visually if you don’t understand it first).
You can have your GUI do anything a terminal can I guess, but you’d need a few million buttons on that gui where the programmer has anticipated each and every combination of CLI command that you are going to use, encoded that to a button or menu, included text entry boxes for each variable and have bundled every program, application and dependency that has ever existed. Totally possible.
So true!!!