Re: gEDA-user: Ben mode feature request

[John Doty <jpd@xxxxxxxxx>]

On Nov 1, 2010, at 2:01 PM, Vanessa Ezekowitz wrote:

> On Mon, 1 Nov 2010 10:05:17 -0600
> John Doty <jpd@xxxxxxxxx> wrote:
> 
>> What you want doesn't matter. What the *job* needs is the thing that
>> matters.
> 
> Suppose the user can't get the job done *at all* without whatever feature is being proposed?  That is the crux of my argument here.

"The key to problem-solving ... is to identify the right primitive operations and to put them at the right place. ... Merely adding features does not make it easier for users to do things — it just makes the manual thicker." -- Brian Kernighan and Rob Pike

So, if the job can't be done, asking for a "feature" is the wrong approach. The first step is to figure out what primitive operation is missing from the toolkit. Sometimes when you ask that question, the answer is "nothing", because merely asking that question focuses your attention on the tools, and you find a way. Other times, the necessary primitive operation is best implemented with a separate tool. Piling everything into a single tool as "features" leads to inflexibility and low productivity. It might be okay for a tool with limited horizons, but it is important to preserve toolkits like gEDA that serve wide horizons with minimal complexity.

> 
> This is not to say that I am not intelligent enough to use a simulator outside of a GUI environment - I defy anyone to make that argument.  Rather, it means I am not necessarily *skilled* enough to use one.  The thing is, I shouldn't need to learn any special skills just to simulate a simple circuit.
> 
>> Indeed. But in fact, I bet if you did a time and motion study you'd find
>> that typing commands is much faster than point and click. Point and click
>> is a seductive time waster *except* for inherently graphical parts of the
>> job.
> 
> For some things, the command line is a little faster, but for some stuff, it doesn't make any sense.  It also depends on how the interface in question is implemented and whether you are a particularly fast and accurate typist.  I, for example, can barely manage 40 words a minute.

I'm slower than that. But unlike button pushes, commands don't have to be retyped much. Any time I find myself doing the same thing repeatedly, I can make an alias, script, or makefile rule. And these approaches can be combined to automate very complex operations triggered by simple commands. But GUI operations generally depend on having a human guide them (by selecting something, filling out a form, etc.), so they are much less friendly to automation.

> 
> In the case of the little script I mentioned, to run it I must open a terminal via a hotkey I already have set up for that purpose, hit ctrl-r and a few keys to find the command, hit Enter, and then supply my password.  All told, it takes about 15 seconds and about 20 keypresses.

Why do you tolerate such barriers?

For one gEDA project, I recently had a simple change request. I hadn't worked on the project in months, but a quick grep for the refdes found the page, five minutes with gschem made the change (GUI *in its place* is great), then typing "make" rebuilt 50 pages of documentation, a 600 part BOM, and the netlist in the customer's requested format. The project's structure is specific to the customer's requirements, but I don't have to remember those details: the makefile remembers them for me. That's ease and productivity. No need to remember some complicated path through incomprehensible menus.

> 
> On a bad day, my own inability to type accurately can inflate those figures significantly.  Hell, just getting past the login prompt can take that long on a particularly bad day.
> 
> On the other hand, I could just set up sudo to allow that script to run without my password, in which case a single click of the mouse would start the backup.  It would undoubtedly save time, and save a lot of typing, but it's also insecure, as far as I'm concerned.
> 
> Any other command line function I do is generally slowed down by the same problems, as are things such as this email.

All you're saying is that you don't use the command line functions effectively. That's OK: work however you want. But then please don't ask that gEDA, an unusually effective toolkit for a different approach than yours, be changed to reflect a less flexible and scalable approach. You want a different tool.

> 
>>> Your implication here is that these tools are and
>>> should be reserved only for experts,
>> 
>> Absolutely not. However, there should exist tools that serve needs of
>> experts. There are lots of tools out there that sacrifice productivity and
>> flexibility for user comfort. 
> 
> Fair enough, but it doesn't have to be that way.  The stupidity of some programmers' design decisions does not imply that *all* programmers make stupid decisions. The existence of a feature does not imply the requirement to *use* that feature, or the requirement to discard whatever feature(s) it is capable of replacing.

Part of Kernighan and Pike's point is that making the manual thicker is by itself a very significant cost whether one uses the poorly conceived feature or not. With GUI, it's actually worse, because finding the right menu item in a fog of unnecessary ones is even more costly than bloated documentation.

> 
> Just because PCB has a schematic import function now, for example, doesn't mean people have to give up using gsch2pcb.  I'm sure some will continue to use it, while others will use the import function instead (and I am quite happy it exists - thanks DJ :-) ).
> 
>> It is a good thing that that the comfort of the
>> majority did not dictate the design of this vehicle.
> 
> The comfort of the majority didn't dictate the design of *your* vehicle, sure, but your analogy is lacking here.  I am reminded at this point of the song, "Hey Little Cobra".  Most of the song of course is not relevant to this discussion, but it raises one concept that wasn't even explored within the song itself:
> 
> The singer owns both a Mustang and a Cadillac, the former being towed behind the latter each time he goes out to race.  Obviously the singer enjoys the comfort of his Caddy, but recognizes that his hopped-up Mustang is the best choice for street racing.
> 
> In the end though, both cars were designed by their OEMs for the same purpose:  to move people and stuff around with some reasonable level of comfort.  The same goes for your Jeep.  Each car in existence has its strengths and weaknesses, whether they be speed, comfort, towing capacity/torque, economy, bragging rights, whatever.

Exactly. That's why there should be multiple designs of cars. One size does not fit all.

> 
> The same can be said of the gEDA suite - it is composed of many tools that are designed for the sole purpose of getting stuff done.  Some parts of that suite provide a comfortable environment (PCB, Gschem), some parts are meant to do one thing and do it very fast (gsch2pcb), and others are workhorses (gnetlist).
> 
> The difference between the car analogy and gEDA though, is that most cars can't easily be switched between the above duties without sacrificing something important.  The same is not true of software, when you have good programmers in control, and I have every reason to believe that is the case with gEDA.

Wrong. It is exactly the same with software. Avoiding unnecessary "features" is, if anything, more important in software design than in the design of physical objects. The cost is less obvious, but it's very present.

> 
>>> Now we have easy to use systems to allow one to design a schematic and
>>> ensure that the board created from it is at least electrically identical,
>>> so far as the copper is concerned anyway.  We just need the equivalent
>>> for circuit simulation.
>> 
>> With gEDA, we already have that for chip design.
> 
> I'm not talking about chip design, and unless I missed something, neither is anyone else in this thread.

But *I* use gEDA for chip design, among other things. That's the power of the simple, flexible toolkit approach. You can use the kit "outside the box".

> 
>> The overloading of pinseq= is also troublesome for simulating slotted
>> components, but fixing this requires no changes to the gEDA core: it's
>> implemented in the spice and spice-sdb back ends.
>> 
>> And one really cool thing here is that a gnetlist back end can generate
>> symbolic equations for a circuit, so you can do things like find the ratio
>> of RC time constants that give critical damping. Again, that's enormously
>> more productive than tweaking a simulation. Where's the "find critical
>> damping condition" button on your favorite GUI app?
> 
> That is a strawman argument; when I was learning electronics 20 years ago, that kind of stuff simply never came up, and I don't deal with such things now either.

But *I* do. That kind of capability is another great time saver. Just because you don't use the flexibility of the kit doesn't mean it isn't valuable to others. That this is outside your personal horizon hardly makes it a strawman. The great and unusual thing about gEDA is that it allows users to move in unconventional but highly productive directions.

> 
> That aside, I have no favorite GUI app, because one has not been written.  QUCS and Xcircuit were merely examples, not points for comparison.  I've used them both before, with limited success, but neither one is useful to me anymore as they aren't compatible with gEDA.
> 
>>> Just because one is doing this on a computer instead of paper does NOT
>>> mean one should be forced to use the command line to do it.
>> 
>> I can't afford to be forced into a low productivity mode of operation.
> 
> Then don't use the hypothetical GUI.  Stick to your scripts.

I don't trust that GUI can be added without damage.

> 
>>> Computers are supposed to make things easier for people, and allow them
>>> to be more productive; that's what they were created for.
>> 
>> Yes. That's exactly why GUI should be limited to jobs that really need it.
>> It's a productivity sink.
> 
> To YOU it is.  To the rest of us who don't think in terms of numbers and scripts and text files but rather in images, the command line is the time sink.

Then please use a different application. Please don't press to damage a rare example of highly productive, scalable software design because it doesn't suit your approach. One size does not fit all.

> 
> An analogy:  If I've never been to your part of town, don't just tell me your address, give me some idea what to look for near it:  " Near the corner of X and Y, there's a roundabout there with a big tree.  Look for the brick house with the ramp just south of that."

Ugh. Narrative directions like that are very difficult to follow. Especially if you don't know me, and therefore don't understand what my eyes pick out of a scene. A map is much better.

> 
> I can't even begin to count the number of hours I have wasted at the command line with other software over the years, trying to figure stuff out, when a simple GUI, or even dialog or ncurses, would have made things an order of magnitude clearer, even when the man pages and --help information associated with those programs would seem to be fairly clear already.
> 
> Poor programming can make a command line utility perform poorly, and good programming can make a GUI perform beautifully.

I've never seen an integrated GUI design environment that scaled well in the sense of enabling a small team to do a big job.

> 
>>> If introducing a computer to a user's workflow doesn't improve his or
>>> her productivity, then either the computer is simply the wrong tool
>>> altogether, or the person responsible for the software therein is the one
>>> who is at fault.
>> 
>> But in your argument, you confuse comfort with productivity. For
>> productivity, command line is *better* except for drawing. Drawing is only
>> a small part of EDA.
> 
> Again, you assume everyone things like you do.

Absolutely not. I know I'm in a minority. But I am incredibly grateful that Ales created a toolkit that serves the needs of people like me. Do you really want to be associated with the tyranny of the majority? Shouldn't free software include great tools that serve minorities?
 
>  They don't, nor do they necessarily think like me.

Indeed. One size does not fit all. Plainly, gEDA's toolkit approach does not suit you.

>  From this discussion, from previous arguments I've seen you have with others, and from my own experiences in computing and IT over multiple OS's in the last ~25 years:
> 
> * You desire the bare minimum of GUI tools.  If something can be done from the command line, a GUI is not warranted and should not be bothered with.

That's the efficient, flexible, scalable approach.

> 
> * I say that if a GUI can help some users get a job done, one should be made available.

But that's not the approach that has made gEDA successful. Plainly, you want something that is not gEDA.

>  If some people prefer to stick to the command line, so be it - just ignore the existence of the GUI, or compile it out.

Flab cannot be ignored.

> 
> * The commercial software world leans heavily toward GUIs, avoiding the command line unless it can't be helped. The command line is "scary" or "confusing" or any of a hundred other negative phrases.

Indeed. That's why gEDA is so special. Freed of the needs of the sales department, Ales has been able to create something better for the computer literate user than any commercial product.

> 
> Productivity should be a concern, of course, but not at the cost of ease of use.  
> When you start making stuff difficult to use, or just fail to make it reasonably easy when it is possible to do so, productivity goes *down*, not up.

gEDA is very easy to use if use its power. It's only difficult if you fight against the toolkit paradigm.

>  Therefore, I stand firm on my claim that the best route is to add a GUI where it may be helpful, as long as the command line workflow remains undisturbed.

Real life doesn't work that way. Making the manual thicker is always costly. Design changes to serve GUI invariably damage scriptability. GUI atop unmodified command line scriptability only works well if the GUI has very few features.

> 
>>> The existence of a GUI does not have to preclude the use of equivalent
>>> command-line utilities.
>> 
>> Putting a GUI on non-graphical functions *almost always* torques the design
>> away from effective scripting. You can claim this isn't necessarily so, but
>> actual software designers aren't usually smart enough to avoid this trap.
> 
> And here we come to the crux of this argument.  While you actually validated what I said earlier in this message, that the viability of a GUI depends on how it is implemented,

Indeed. Except that actual software developers are not omniscient gods, so they cannot implement complex GUI without damage to scriptability. I know Ales never intended gEDA to be used in the ways that I use it, but by keeping the GUI minimal and the scripting capability maximal, he made it possible to use gEDA far outside the usual limits.

> what you forget to consider every time the idea of enhancements to the quite comes is that not everyone uses the scripting features you are so fond of.

That's not a good excuse for damaging the toolkit. If you don't like the toolkit paradigm, you would be better advised to choose a different tool. One size does not fit all.

> 
> What most people would use gEDA for, if they aren't already doing so, is the same thing I use it for - to make circuit boards with components designed and supplied by *someone else*.

I do that too. gEDA is good for a *lot* of different things.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user