CLI is faster than GUI myths

Vom: Fri, 11 Nov 2011 10:59:31 +0100

Hi,

Id like to start this thread to address the "CLI is faster than GUI"

myths. I challenge diehard CLI users to add their favorite command

that they think cant be done as efficient in a GUI, and I'll try to

find a equally efficient way to do it the GUI way.

 

My challenge would still be the same as mentioned in the earlier thread:

Take a large circuit with say, 500+ different signals. You got a "bus"

of different signals, say OUT[0..255] and DATA[0..511].

They are aligned in a complex way, so you can't select more than one

signal with one click. Now you want to rip them up (and only them).

I think the most efficient way would be "ripup OUT* DATA*;"

Another challenge, apart from eagle, is this (not really serious):

Receive an 8-bit digit X via UDP port 1000 and then draw a filled black

circle with 50 pixel radius on position 5/15 into 3

imagefiles /tmp/image[X].jpg, /tmp/image[X+1].png

and /tmp/image[X+2].gif overlaying the previous image-content.

Please don't nail me on this one, it's just an extreme example of

an extraordinary special usecase where you have no chance with any GUI

while you can do it extremly easy and quick with one line in a

CLI/shell. (If you know how and don't have to learn everything

first.)

It becomes more obvious when a task must be repeated

oftenly. With a CLI you can just press <cursor-up> to redo (or

copy/paste at least with any CLI). It has been mentioned that you can

also assign a shortcut-key.

Additionaly, eagle does it better than you: If you click-select you

could easily miss a signal/part. If you say "LED*" then it really means

every LED(...)-signal. So please don't see the CLI only as interface

alternative, but also as a general principle of designing (which would

prevent errors in this case). The best CLI is useless if your design

is bad. For example, your naming doesn't make sense or your design is

generally chaotic/unstructred.

A proper GUI would let you select the components you want to change

with either a select window drag (not having to activate the group)

like a powerpoint presentation design. It will also let you add and

remove using ctrl (or shift) selects like you do in a (win)

...or you can use a lasso-tool or "select-by-layer" etc. You could even

have a mixture between GUI and CLI by providing sort of a tree-view of

you whole project, showing all objects (signals, parts etc.) to

perform different actions on (like scene-graphs known from 3D CGI

Software).

filebrowser. Also, a filter selection tool could help you add

component based on name or other parameters.

Yes. A filter would be a small LI inside a select-tool. This could

support wildcards, patterns or even interpret regular-expressions.

Generally, all you can answer to different challenges is inventing

different GUI features that solve that challenge (more or less

efficient).

What you forget is, that someone has to implement that GUI feature

(write code) and a decision must be made on how to implement it (GUI

design).

Excellent GUI design is far from beeing an easy task (obviously).

In fact I have seen stuffed & un-intuitive GUIs that were so

feature-rich trying to cover every possible use-case, that in the end

they were almost unusable - although the underlying software was

excellent (which was practically the only reason why someone decided to

buy the software in the first place).

Apart from the fact that designing a GUI is a never-ending task (since

new features, that need a new kind of GUI interface, are added

constantly) it is often overseen that a CLI is just a formal and

structured representation of the programs' functionality.

The programmer writes one piece of software (the parser) once. He never

has to touch it again. It's finished. (Which is generally a good thing

since no new bugs arise). New features don't need new parser code.

This not only prevents bugs, but enables developers to quickly enhance

functionality by extending the parser.

Say for example the parser can parse something like " ...". After that, you implement wildcards or regular

expressions etcetc.

All those changes affect all possible commands (i.e. the whole

functionality). The reasonable maximum amount of parser-features is

limited, so that the parser-code is finished at some point, no matter

how complex the parser is.

I hope the advantage from the software-designers' & developers' point of

view becomes clear. Additionally it's important to know that, if the

software-design is good for developers the users directly profit from

this in the form of less bugs, quick releases, more new features etc.

But that's all theory. In reality your GUI must be "reasonable complete"

to solve the most common tasks quickly since the majority of (new) users

didn't (yet) learn the "structure" of the program or looked up CLI

commands.

Also, in reality new features always mean new GUI elements (CLI support

or not). You still can run into the risk of an inefficient GUI. That is

what somehow happened to Eagle. Additionally it can happen that the

whole GUI must be completly re-designed at some point, forcing users to

regain already learned knowledge.

I think the whole point of the discussion is, that CLIs and GUIs are

not opposing paradigms. Instead it's just 2 layers sitting ontop of the

functions a software provides.

So I really believe the one doesn't hurt the other but by providing an

alternative to the GUI (be it ULP, Rexx, LUA, CLI, whatever...) a

software can really unleash all its power in even the worst scenarios.

Thusly more users are kept from getting frustrated since, in the worst

scenario, you normally call for support. And it's better to get a

10-page-instruction list that solves the problem than hearing "This

just can't be done."

And now for the sad part:

In theory every software would be fine with a minimal, well designed

GUI not implementing every feature but only the ones, you don't have a

CLI alternative for (like visualization, mouse usage, etc.)

So the GUI code would be finished at some point. Everything else would

be controlled by CLI and the GUI code doesn't need to be touched when

new features are implemented.

This is of course a developers' dream and it pretty much was the way

good software was designed decades ago. But times change I guess the

last CLI widely used by mainstream-users was the Hayes (AT) commandset

for dialup-modems (using a terminal program as GUI frontend).

So back in the days, users had to learn how to use a CLI but nowadays

it's quite uncommon among most users. And since a CLI doesn't have a

very steep learning-curve, lots of users try to avoid it wherever they

can, thus never have the pleasure of advanced CLI features.

This doesn't apply to Eagle alone but to most application-software and

operating systems in general.

many regards

"Daniel Hiepler" <rigid@boogiepalace.hopto.org> wrote in message

news:20111112015835.152a14e2@boogiepalace.nifty.lan...

Vom: Fri, 11 Nov 2011 10:59:31 +0100

 

Hi,

 

>> Id like to start this thread to address the "CLI is faster than GUI"

>> myths. I challenge diehard CLI users to add their favorite command

>> that they think cant be done as efficient in a GUI, and I'll try to

>> find a equally efficient way to do it the GUI way.

>>

>

My challenge would still be the same as mentioned in the earlier thread:

 

Take a large circuit with say, 500+ different signals. You got a "bus"

of different signals, say OUT[0..255] and DATA[0..511].

They are aligned in a complex way, so you can't select more than one

signal with one click. Now you want to rip them up (and only them).

I think the most efficient way would be "ripup OUT* DATA*;"

This would (again) be handeled with a filter selection tool. You would find

it in the menu (also with a hotkey, as most often used menuitems has) and

you enter a regexp to select the nets you want to work on. Then you select

ripup. In theory it will take one hotkey press + enter the "OUT* DATA*"

string, enter key and select the ripup tool in the menu (I dont think a

shortcut to ripup is wanted, because you may want some threshold on

destructive tools).

Another challenge, apart from eagle, is this (not really serious):

 

Receive an 8-bit digit X via UDP port 1000 and then draw a filled black

circle with 50 pixel radius on position 5/15 into 3

imagefiles /tmp/image[X].jpg, /tmp/image[X+1].png

and /tmp/image[X+2].gif overlaying the previous image-content.

I guess you want to do this in a ULP? I can't see how a direct CLI command

could do this (the X+n insertion), but it may be something Ive never had any

use for.

The ULP (same or different language, like TCL) must never be removed, so a

proper GUI is orthogonal to this problem.

I'd also like to see ULP also being able to create new root projects and

have write access to them direct instead of through scripts. I'd also like

to have event triggered ULP's.

I guess also tools like Altium also has a programming language, but its

rather poor documented.

Please don't nail me on this one, it's just an extreme example of

an extraordinary special usecase where you have no chance with any GUI

while you can do it extremly easy and quick with one line in a

CLI/shell. (If you know how and don't have to learn everything

first.)

It becomes more obvious when a task must be repeated

oftenly. With a CLI you can just press <cursor-up> to redo (or

copy/paste at least with any CLI). It has been mentioned that you can

also assign a shortcut-key.

Like what task? If you need to redo your command often like that, you've

done some wrong thinking in the first place..

You may have a small point if you alternate with some other command, and

click up twice, but I challenge you to give me some real examples, and I'll

tell you how it should be done.

Additionaly, eagle does it better than you: If you click-select you

could easily miss a signal/part. If you say "LED*" then it really means

every LED(...)-signal. So please don't see the CLI only as interface

alternative, but also as a general principle of designing (which would

prevent errors in this case). The best CLI is useless if your design

is bad. For example, your naming doesn't make sense or your design is

generally chaotic/unstructred.

I think I lost your point in this paragraph. Please specify if its not

covered with the filter select tool.

>> A proper GUI would let you select the components you want to change

>> with either a select window drag (not having to activate the group)

>> like a powerpoint presentation design. It will also let you add and

>> remove using ctrl (or shift) selects like you do in a (win)

 

...or you can use a lasso-tool or "select-by-layer" etc. You could even

have a mixture between GUI and CLI by providing sort of a tree-view of

you whole project, showing all objects (signals, parts etc.) to

perform different actions on (like scene-graphs known from 3D CGI

Software).

Yes, lasso-tool is probably the right name for the standard GUI area select

tool. A tree view of components would probably be good. Not sure if a tree

view of nets will, but maybe of classes.

>> filebrowser. Also, a filter selection tool could help you add

>> component based on name or other parameters.

 

Yes. A filter would be a small LI inside a select-tool. This could

support wildcards, patterns or even interpret regular-expressions.

 

>

Generally, all you can answer to different challenges is inventing

different GUI features that solve that challenge (more or less

efficient).

What you forget is, that someone has to implement that GUI feature

(write code) and a decision must be made on how to implement it (GUI

design).

 

Excellent GUI design is far from beeing an easy task (obviously).

In fact I have seen stuffed & un-intuitive GUIs that were so

feature-rich trying to cover every possible use-case, that in the end

they were almost unusable - although the underlying software was

excellent (which was practically the only reason why someone decided to

buy the software in the first place).

It needs some upfront planning for sure, but you get a lot for free if

programmed right. But I do see the cross platform support as a challenge

when using os specific functions to support it.

Apart from the fact that designing a GUI is a never-ending task (since

new features, that need a new kind of GUI interface, are added

constantly) it is often overseen that a CLI is just a formal and

structured representation of the programs' functionality.

If its a never ending task, it has not been properly planned. Even CLI's can

(should!) develop. Ive seen a few examples where current Eagle CLI doesnt do

the job and has to be tweaked with certain SET extensions. Look at some

requesters with several choises, like when trying to merge nets. CLI can't

handle it (although it could with some extensions).

The programmer writes one piece of software (the parser) once. He never

has to touch it again. It's finished. (Which is generally a good thing

since no new bugs arise). New features don't need new parser code.

That is not true. Every parser needs to develop. Now with v6, it has to

support new commands, and there will be cross dependancy wich it needs to

handle.

This not only prevents bugs, but enables developers to quickly enhance

functionality by extending the parser.

Say for example the parser can parse something like "<command>

<argument>".

Then you can extend it to understand list of arguments "<command>

<arg1> <arg2> ...". After that, you implement wildcards or regular

expressions etcetc.

I don't get it. Why is that harder to do on the GUI?

All those changes affect all possible commands (i.e. the whole

functionality). The reasonable maximum amount of parser-features is

limited, so that the parser-code is finished at some point, no matter

how complex the parser is.

The risk does not lie in the parser (or the GUI handler, its part of the

OS). Its in the functions beneath it.

I hope the advantage from the software-designers' & developers' point of

view becomes clear. Additionally it's important to know that, if the

software-design is good for developers the users directly profit from

this in the form of less bugs, quick releases, more new features etc.

I think you are on the wong track.

But that's all theory. In reality your GUI must be "reasonable complete"

to solve the most common tasks quickly since the majority of (new) users

didn't (yet) learn the "structure" of the program or looked up CLI

commands.

Of course a new GUI would have to be complete. Eagle is not that far from it

really.

Also, in reality new features always mean new GUI elements (CLI support

or not). You still can run into the risk of an inefficient GUI. That is

what somehow happened to Eagle. Additionally it can happen that the

whole GUI must be completly re-designed at some point, forcing users to

regain already learned knowledge.

Current GUI is inefficient? I dont think so. It just lacks some functions

and the de-facto standard adoptions.

I think the whole point of the discussion is, that CLIs and GUIs are

not opposing paradigms. Instead it's just 2 layers sitting ontop of the

functions a software provides.

Nobody denied that. Its just that the GUI still has some proprietary issues

and some functions is missing.

So I really believe the one doesn't hurt the other but by providing an

alternative to the GUI (be it ULP, Rexx, LUA, CLI, whatever...) a

software can really unleash all its power in even the worst scenarios.

Thusly more users are kept from getting frustrated since, in the worst

scenario, you normally call for support. And it's better to get a

10-page-instruction list that solves the problem than hearing "This

just can't be done."

Now you're talking programming languages. That is also orthogonal to the

GUI.

And now for the sad part:

In theory every software would be fine with a minimal, well designed

GUI not implementing every feature but only the ones, you don't have a

CLI alternative for (like visualization, mouse usage, etc.)

So the GUI code would be finished at some point. Everything else would

be controlled by CLI and the GUI code doesn't need to be touched when

new features are implemented.

This is of course a developers' dream and it pretty much was the way

good software was designed decades ago. But times change I guess the

last CLI widely used by mainstream-users was the Hayes (AT) commandset

for dialup-modems (using a terminal program as GUI frontend).

So back in the days, users had to learn how to use a CLI but nowadays

it's quite uncommon among most users. And since a CLI doesn't have a

very steep learning-curve, lots of users try to avoid it wherever they

can, thus never have the pleasure of advanced CLI features.

 

This doesn't apply to Eagle alone but to most application-software and

operating systems in general.

All your thought was a bit disordered, I hope the reply is satisfactory.

Please post one thought at a time

"Daniel Hiepler" <rigid@boogiepalace.hopto.org> wrote in message

news:20111112015835.152a14e2@boogiepalace.nifty.lan...

Vom: Fri, 11 Nov 2011 10:59:31 +0100

 

Hi,

 

>> Id like to start this thread to address the "CLI is faster than GUI"

>> myths. I challenge diehard CLI users to add their favorite command

>> that they think cant be done as efficient in a GUI, and I'll try to

>> find a equally efficient way to do it the GUI way.

>>

>

My challenge would still be the same as mentioned in the earlier thread:

 

Take a large circuit with say, 500+ different signals. You got a "bus"

of different signals, say OUT[0..255] and DATA[0..511].

They are aligned in a complex way, so you can't select more than one

signal with one click. Now you want to rip them up (and only them).

I think the most efficient way would be "ripup OUT* DATA*;"

This would (again) be handeled with a filter selection tool. You would find

it in the menu (also with a hotkey, as most often used menuitems has) and

you enter a regexp to select the nets you want to work on. Then you select

ripup. In theory it will take one hotkey press + enter the "OUT* DATA*"

string, enter key and select the ripup tool in the menu (I dont think a

shortcut to ripup is wanted, because you may want some threshold on

destructive tools).

Another challenge, apart from eagle, is this (not really serious):

 

Receive an 8-bit digit X via UDP port 1000 and then draw a filled black

circle with 50 pixel radius on position 5/15 into 3

imagefiles /tmp/image[X].jpg, /tmp/image[X+1].png

and /tmp/image[X+2].gif overlaying the previous image-content.

I guess you want to do this in a ULP? I can't see how a direct CLI command

could do this (the X+n insertion), but it may be something Ive never had any

use for.

The ULP (same or different language, like TCL) must never be removed, so a

proper GUI is orthogonal to this problem.

I'd also like to see ULP also being able to create new root projects and

have write access to them direct instead of through scripts. I'd also like

to have event triggered ULP's.

I guess also tools like Altium also has a programming language, but its

rather poor documented.

Please don't nail me on this one, it's just an extreme example of

an extraordinary special usecase where you have no chance with any GUI

while you can do it extremly easy and quick with one line in a

CLI/shell. (If you know how and don't have to learn everything

first.)

It becomes more obvious when a task must be repeated

oftenly. With a CLI you can just press <cursor-up> to redo (or

copy/paste at least with any CLI). It has been mentioned that you can

also assign a shortcut-key.

Like what task? If you need to redo your command often like that, you've

done some wrong thinking in the first place..

You may have a small point if you alternate with some other command, and

click up twice, but I challenge you to give me some real examples, and I'll

tell you how it should be done.

Additionaly, eagle does it better than you: If you click-select you

could easily miss a signal/part. If you say "LED*" then it really means

every LED(...)-signal. So please don't see the CLI only as interface

alternative, but also as a general principle of designing (which would

prevent errors in this case). The best CLI is useless if your design

is bad. For example, your naming doesn't make sense or your design is

generally chaotic/unstructred.

I think I lost your point in this paragraph. Please specify if its not

covered with the filter select tool.

>> A proper GUI would let you select the components you want to change

>> with either a select window drag (not having to activate the group)

>> like a powerpoint presentation design. It will also let you add and

>> remove using ctrl (or shift) selects like you do in a (win)

 

...or you can use a lasso-tool or "select-by-layer" etc. You could even

have a mixture between GUI and CLI by providing sort of a tree-view of

you whole project, showing all objects (signals, parts etc.) to

perform different actions on (like scene-graphs known from 3D CGI

Software).

Yes, lasso-tool is probably the right name for the standard GUI area select

tool. A tree view of components would probably be good. Not sure if a tree

view of nets will, but maybe of classes.

>> filebrowser. Also, a filter selection tool could help you add

>> component based on name or other parameters.

 

Yes. A filter would be a small LI inside a select-tool. This could

support wildcards, patterns or even interpret regular-expressions.

 

>

Generally, all you can answer to different challenges is inventing

different GUI features that solve that challenge (more or less

efficient).

What you forget is, that someone has to implement that GUI feature

(write code) and a decision must be made on how to implement it (GUI

design).

 

Excellent GUI design is far from beeing an easy task (obviously).

In fact I have seen stuffed & un-intuitive GUIs that were so

feature-rich trying to cover every possible use-case, that in the end

they were almost unusable - although the underlying software was

excellent (which was practically the only reason why someone decided to

buy the software in the first place).

It needs some upfront planning for sure, but you get a lot for free if

programmed right. But I do see the cross platform support as a challenge

when using os specific functions to support it.

Apart from the fact that designing a GUI is a never-ending task (since

new features, that need a new kind of GUI interface, are added

constantly) it is often overseen that a CLI is just a formal and

structured representation of the programs' functionality.

If its a never ending task, it has not been properly planned. Even CLI's can

(should!) develop. Ive seen a few examples where current Eagle CLI doesnt do

the job and has to be tweaked with certain SET extensions. Look at some

requesters with several choises, like when trying to merge nets. CLI can't

handle it (although it could with some extensions).

The programmer writes one piece of software (the parser) once. He never

has to touch it again. It's finished. (Which is generally a good thing

since no new bugs arise). New features don't need new parser code.

That is not true. Every parser needs to develop. Now with v6, it has to

support new commands, and there will be cross dependancy wich it needs to

handle.

This not only prevents bugs, but enables developers to quickly enhance

functionality by extending the parser.

Say for example the parser can parse something like "<command>

<argument>".

Then you can extend it to understand list of arguments "<command>

<arg1> <arg2> ...". After that, you implement wildcards or regular

expressions etcetc.

I don't get it. Why is that harder to do on the GUI?

All those changes affect all possible commands (i.e. the whole

functionality). The reasonable maximum amount of parser-features is

limited, so that the parser-code is finished at some point, no matter

how complex the parser is.

The risk does not lie in the parser (or the GUI handler, its part of the

OS). Its in the functions beneath it.

I hope the advantage from the software-designers' & developers' point of

view becomes clear. Additionally it's important to know that, if the

software-design is good for developers the users directly profit from

this in the form of less bugs, quick releases, more new features etc.

I think you are on the wong track.

But that's all theory. In reality your GUI must be "reasonable complete"

to solve the most common tasks quickly since the majority of (new) users

didn't (yet) learn the "structure" of the program or looked up CLI

commands.

Of course a new GUI would have to be complete. Eagle is not that far from it

really.

Also, in reality new features always mean new GUI elements (CLI support

or not). You still can run into the risk of an inefficient GUI. That is

what somehow happened to Eagle. Additionally it can happen that the

whole GUI must be completly re-designed at some point, forcing users to

regain already learned knowledge.

Current GUI is inefficient? I dont think so. It just lacks some functions

and the de-facto standard adoptions.

I think the whole point of the discussion is, that CLIs and GUIs are

not opposing paradigms. Instead it's just 2 layers sitting ontop of the

functions a software provides.

Nobody denied that. Its just that the GUI still has some proprietary issues

and some functions is missing.

So I really believe the one doesn't hurt the other but by providing an

alternative to the GUI (be it ULP, Rexx, LUA, CLI, whatever...) a

software can really unleash all its power in even the worst scenarios.

Thusly more users are kept from getting frustrated since, in the worst

scenario, you normally call for support. And it's better to get a

10-page-instruction list that solves the problem than hearing "This

just can't be done."

Now you're talking programming languages. That is also orthogonal to the

GUI.

And now for the sad part:

In theory every software would be fine with a minimal, well designed

GUI not implementing every feature but only the ones, you don't have a

CLI alternative for (like visualization, mouse usage, etc.)

So the GUI code would be finished at some point. Everything else would

be controlled by CLI and the GUI code doesn't need to be touched when

new features are implemented.

This is of course a developers' dream and it pretty much was the way

good software was designed decades ago. But times change I guess the

last CLI widely used by mainstream-users was the Hayes (AT) commandset

for dialup-modems (using a terminal program as GUI frontend).

So back in the days, users had to learn how to use a CLI but nowadays

it's quite uncommon among most users. And since a CLI doesn't have a

very steep learning-curve, lots of users try to avoid it wherever they

can, thus never have the pleasure of advanced CLI features.

 

This doesn't apply to Eagle alone but to most application-software and

operating systems in general.

All your thought was a bit disordered, I hope the reply is satisfactory.

Please post one thought at a time