On May 6, 2010, at 9:56 PM, Windell H. Oskay wrote: > > On May 6, 2010, at 6:07 PM, John Doty wrote: >> >> Nobody else has really thought about the magnitude of the problem. I >> challenge you to make a list. > > You are changing the subject, yet again. This is about you, John.
No, it is about polluting good engineering with sloppiness. > > >> I encourage people to contribute to gedasymbols. Where is your contribution? > > Changing the subject, yet again. As a non-contributer, you ask for changes whose consequences you do not understand. > > I have already acknowledged your contribution. I wouldn't in a million > years expect you to acknowledge mine. Why not? I acknowledge others' contributions. > > > > >>> Again, you're arguing against a position that nobody is arguing for. >> >> Not true. > > Really? Exactly *who* is arguing that we should have a built-in symbol for > every possible use? It's a *consequence* of your position. If you travel the road to Hell, you'll wind up in Hell, even if you're not arguing that Hell is where you want to go. > It's clear enough that the only person arguing that is YOU, and you're only > putting it out there to argue against it. Another classic straw man. No it is not. A basic principle of software engineering is that when you hide imperfection behind an interface, you amplify the effect of that imperfection. > > >> If the database behind the GUI tool is inadequate, the GUI gets in the way. >> Users will have to get used to reaching around it anyway. That will drive >> away everyone who thinks it should actually work, while the few remaining >> will drop back to the workable flow, and the cute GUI feature will have only >> driven people away. > > You're making assumptions upon assumptions so that you can insult the result > as unworkable. Not helpful. I'm sorry that you find pointing out the chasm between your intensions and the likely consequences of them unhelpful. > > Perhaps my memory is limited, but the only "workable flow" that I can recall > you acknowledging is your own. Which flow? I have a different one for each project. Again, good engineering allows the ends to dictate the means. The genius of gEDA is that its flexibility supports this. > Everything else that all of us do is just a "cute toy" to you-- we get it. > (Some of us use those "cute toys" to make a living, you know.) > > Here's my opinion, which I don't require anyone to share: gEDA is > fundamentally a graphics suite-- Graphics is the easy part of the job. The fun part. The clerical stuff is the part everybody wishes would go away (it won't). But the clerical part is also more friendly to automation *if* we can keep it in the text world where computers (especially with Unix-derived utilities) are more capable. > for creating graphical data like schematics and circuitry --and it's actually > okay for a graphics suite to have a GUI. For graphical tasks, it's essential. But the design mistake is to use cute graphics for essentially textual tasks. EDA involves both kinds of tasks, so a good toolkit will have both kinds of tools. Unfortunately, too many users have become conditioned to integrated graphical tools, where use of GUI for clerical tasks numbs the mind (because GUI *is* fun) to the time wasted. The most extreme examples of this I've seen are apparently intelligent programmers who spend huge amounts of time hunting for bugs by single-stepping through code in fancy GUI IDE's, when a few asserts and printfs would quickly isolate the problem. Another problem is that GUI *sells*, so for commercial software it has driven out textual interfaces even in the cases where they are better. Integration also sells, and tightens the grip of the producer on the consumer, so toolkits are out of fashion. Fortunately, in free software, we can resist these pressures. We should. > And I would definitely *encourage* our community to be able to discuss > things like this, out in the open, without all the bashing. I'm sorry your thin skin has forced you to bash me. This is about EDA, not about personality. > > > >> This problem is already present in the component selection dialog in gschem. >> A *true* advance in gEDA would be to have this lead the user directly into >> the necessary customization, instead of promoting the illusion that this >> step isn't necessary. > > Sounds like there's a hint of a possibly useful idea in there. Would you > consider maybe someday contributing *constructively* to the dialog? Of course. Didn't I just yesterday praise Edward's work, and offer a solution to one of his problems? Didn't I suggest plug-ins to gnetlist as a another possible approach? But my notion of a "database" is different from yours (and actually achievable): a project-specific mapping of schematic symbols to physical components. > How about making suggestions about ways to do that, or steering the > conversation that way, rather than just shooting down everything that comes > by, whether or not you agree with it? If you think I do that, you haven't been paying attention. And if you really understand the Pike and Kernighan paper, you'll be able to fairly accurately predict what I'll support and what I'll oppose. > > > >> Ah, but it does have to be perfect. Otherwise there will be lots of whining >> about what a piece of crap gEDA is. People won't be able to find their >> favorite component. People will design boards, fabricate them, and be >> shocked when pin numbers turn out to be wrong. > > Nice red herring. Whether or not the symbols are *wrong* is totally > irrelevant to the existence of a database. No it is not. Engineering is about *consequences*. > You know perfectly well that goofs in pin numbers could happen in an > otherwise ideally perfect database or without one at all, even now at > gedasymbols.org. (I've been bitten by such things in other EDA systems; I > know the pain.) Yes, but remember that hiding imperfection behind an interface amplifies its effect. > > Besides, people already complain about what a piece of crap gEDA is-- in > large part because it doesn't have ways for people to find their favorite > component. Yep. So don't feed that impossible expectation. > So...if *that* is our biggest worry, we've got *nothing* to lose. 1. It's not *my* biggest worry. My biggest worry is that adding features to tools makes them less flexible, and that will impact the ability of gEDA's toolkit approach to automate the processes as much as possible. 2. Yes, we have something to lose: we can easily make the problem worse. Hiding imperfection behind an interface amplifies its effect. > > > >> You have no comprehension of how far "every likely use" goes. gEDA isn't >> just a toy for hobbyists. > > > Do you really feel like you're making valid argument by insulting me? That came out wrong, and I apologize again (already did last night). I was not looking down at hobbyists, but at at the idea that cute tools are better than effective toolkits for hobby purposes. > You don't know my background, nor what I comprehend. > > The only one referring to gEDA as a toy is you, and that's not helpful either. Engineering is about consequences. A consequence of your plan is that gEDA becomes more toy-like, regardless of how you wish to describe it. > > >> Sure. Contribute your symbols to gedasymbols. I encourage this. But the >> delusion that this can somehow lead to a situation where a user can just >> pick a component from a menu without both careful checking and customization >> is damaging. > > Thank you for calling me delusional. That really helps move things along, > doesn't it. Delusions are common in engineering, even for perfectly sane engineers. If you can't have bad ideas, you won't have good ones either. That's why designs need review. It's also why you shouldn't be so emotionally invested in your ideas that you're personally insulted by criticism of them. Once upon a time, I was accused of "witchcraft" for digging an unexpected result out of some rather crappy astronomical data, by necessity using a previously unknown (but rigorously justified) mathematical technique. That's life for a scientist. You need a thick skin. > > >>> Your continued abusive behavior towards n00bz and veterans alike here is a >>> damaging, dead end path that leads to loss for all of us. EDA is >>> irrelevant to the problem. >> >> Huh? EDA is what gEDA does! > > The ONLY problem that I've been trying to address here in the last few > messages is your unnecessary and abusive behavior towards individuals on this > mailing list. It's got to stop. No, you're selling an approach that will damage the toolkit. I ain't buying. I guess to a salesman, that counts as an insult. I'm sorry you're so invested in your ideas that you consider criticism of them a personal insult. If you're going to have ideas, you'd better get used to criticism of them. > > No, EDA really hasn't got a damn thing to do with it. For you. For me, it has *everything* to do with it. > > >> I would wish you could appreciate this, and adopt the Hippocratic principle: >> first, do no harm. > > > Again, you have no idea what I do and don't like about gEDA, nor on my stance > on what features do and don't belong in a particular program. You're making > some pretty wild (and wrong) assumptions there. Then enlighten me. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
