CLI is faster than GUI myths

Morten Leikvoll wrote on Fri, 11 November 2011 04:59

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.

Good idea I think.  This could actually be educational to people on both

sides.

Scenario 1:  Move PCB elements (components, traces, vias, ...) by some

exact, very small amount, say 0.001mm.  I don't think that is even

possible with GUI since the grid won't display.  You could argue then, why

does it matter to move such a small amount, but I like to be accurate

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

>Scenario 1: Move PCB elements (components, traces, vias, ...) by some

exact, very small amount, say 0.001mm. I don't think that is even

possible with GUI since the grid won't display. You could argue then, why

does it matter to move such a small amount, but I like to be accurate

That one is easy. Two alternatives would work in a common gui environment.

1.Right click the element and select properties. At properties win you will

find coords and you can change them (much like today, and I use i a lot). A

relative checkbox could switch to relative coor mode, and would work on

many elements.

2. A relative move action in a menu entry that does it directly on the

selected components. For most gui toolsl all the actions available in

context menus are also found in the main menu.

I think only realistic, practical cases should be taken seriously. Commands/procedures that either are useless or very seldom performed should not be submitted.

Lix

Am 12.11.2011 00:56, schrieb Daniel Hiepler:

I think this is exactly the wrong way, since good software shines most,

when it can solve your very specific and uncommon problem in an

efficient and painless way, better than competing software products.

(It's useless if the software can do a thousand things but can't do

what you want right now. Or need very much effort to do it)

Usually, when I write software or our department has to solve problems,

we take the pareto approach: what are the most common problems?

Once these are addressed, we can move forward to the specific problems.

Of course, it should do that for a maximum amount of different users.

(It's useless if it can solve very specific problems for only 1% of the

userbase)

That's more in the spirit of the pareto approach.

I made good experience with

  - providing standard GUI solutions for the common problems

  - provide examples / a cookbook how to solve the specific problems

    with CLI; even non-programmers manage to adapt these to their tasks

But, over time, more and more tasks are moved from the CLI to the GUI.

I admit that for many of my tasks a good GUI is much more work than

the logic behind.

Also, it's not possible to define a good GUI on paper and then just

implement it. It always requires some iterations. Sometimes it takes

me years to have a good idea for a certain task.

Regards,

Dietmar

Am 12.11.2011 00:56, schrieb Daniel Hiepler:

I think this is exactly the wrong way, since good software shines most,

when it can solve your very specific and uncommon problem in an

efficient and painless way, better than competing software products.

(It's useless if the software can do a thousand things but can't do

what you want right now. Or need very much effort to do it)

Usually, when I write software or our department has to solve problems,

we take the pareto approach: what are the most common problems?

Once these are addressed, we can move forward to the specific problems.

Of course, it should do that for a maximum amount of different users.

(It's useless if it can solve very specific problems for only 1% of the

userbase)

That's more in the spirit of the pareto approach.

I made good experience with

  - providing standard GUI solutions for the common problems

  - provide examples / a cookbook how to solve the specific problems

    with CLI; even non-programmers manage to adapt these to their tasks

But, over time, more and more tasks are moved from the CLI to the GUI.

I admit that for many of my tasks a good GUI is much more work than

the logic behind.

Also, it's not possible to define a good GUI on paper and then just

implement it. It always requires some iterations. Sometimes it takes

me years to have a good idea for a certain task.

Regards,

Dietmar