On Mon, 1 Nov 2010 10:05:17 -0600 John Doty <j...@noqsi.com> 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. 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. 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. 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. > > 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. 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. 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. > > 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. > 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. 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. > > 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. 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." 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. > > 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. They don't, nor do they necessarily think like me. 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. * I say that if a GUI can help some users get a job done, one should be made available. If some people prefer to stick to the command line, so be it - just ignore the existence of the GUI, or compile it out. * 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. 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. 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. > > 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, 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. 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*. -- "There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves." http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz <vanessaezekow...@gmail.com> _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
