🚀 go-pugleaf

James R. Bunch wrote in message <71086q$7e3$1@nnrp02.primenet.com>...
>[snip snip]
>
>With simple drafting there's not much room to hurt yourself (not that it's
>impossible, of course).  It's when you begin to push toward the limits of
the
>package that you're likely to encounter problems.  Using AutoCad as an
>example, it when you start doing interference analysis with it that you
might
>begin to be vulnerable to its limitations.


I don't remember seeing a command to do interference analysis on AutoCad's
help screen, so I assume you are referring to a Lisp function available as
an add-on package. I would not use a package unless I could trust the
provider and I understood the operation of the package. However, AutoCad is
not a program J. Random User would have or need. I was only trying to show
that even sophisticated programs could be used successfully by someone who
was not expert in their use. I may not have used 5% of AutoCad's capability,
but I accomplished 100% of the job I had to do.

>Again, at low frequencies the models used are not likely to lead you into
>trouble.  But at some point stray parasitics begin to have significant
>impact, and if you don't know how your package handles them you may be in
>for a surprise.  You say that the programs didn't design anything, just
>captured your drawings, so you may not have exposed yourself to the
>full joy of EAD.  Consider, if you will, the utility and limitations of
>a package such as Spice, and how you would go about deciding whether or not
>you should trust its results in a particular case.  Knowing how it does
>what it does can be essential to such a decision.


My remark above applies equally to this. In addition, in both cases, I
already had the information pertaining to the design, I only needed to
portray it graphically. Consider also that the learning curve associated
with a package like Spice would preclude using it for a one-off application.
It was a small project, and not exposing myself to the joy of EAD enabled me
to prototype the project, test it, and build 300 units for field testing in
less time than it would have taken me to learn all the intricacies of using
Spice. Field testing showed that the units performed precisely as intended.
BTW, the project was a headset radio which contained an FM broadcast
receiver and a crystal-controlled UHF FM receiver (450MHZ). The wearer
normally listened to an FM broadcast station, and was automatically switched
to the UHF receiver when a UHF signal was received. Not low frequencies.

>I suspect that 95% to 99% of the time the folks you call winners are, if
>not winners, not yet losers.  Many of them may never lose in this game.

And if so, are ultimately winners.

>The problem I see is that without enough knowledge of the inner workings
>of the tools they use they are always vulnerable to taking a loosing hit,
>and some of those hits have serious consequences.  Most busted gamblers
>were "winners" at some point.  They just ended up as losers because they
>failed to understand that over the long term the house always wins.

I guess the house, in this case, consists of the system manufacturers and
program sellers, and the wager is the purchase price. Then the users are
betting what they spend that they will be able to use the system and
software to accomplish their goals. I applaud all those who overcome their
initial fear of something new and unknown, and learn the necessary skills to
use a computer system. They will probably stick to commercial word
processing, bookkeeping, or Internet browser programs, and not have any
problems with their systems. One man I know communicates with his married
daughter half-way around the world several times a week by email. Before he
got on the Internet, he did good to send or receive one letter per month.

>The question boils down, I think, to one of risk exposure and assessment.
>Anyone who attempts to use a tool he does not understand exposes himself to
>some degree of risk.  If circumstances limit the possible negative outcomes
>to the trivial, then no harm can be done.  If, however, the tool user is
>exposed to significant risk of major adverse consequences, and proceeds in
>using a tool he only partially understands, that user is a fool.


Which are you referring to as a tool, the operating system, the application
program, or the hardware? While we have been discussing applications, I get
the impression that the operating system is the actual subject.

>When folly is easy to avoid, one is doubly the fool for not doing so.


Easy for who? And at what cost? What level of training or education should
be required for operation/use of a computer system? Where and how do
beginners begin?

Sure, it would be foolish for me to sit down to a computer and try to design
a space shuttle. I don't know anything about space shuttles. I recognize my
limits there. But they are my limits, not those of the system. I won't try
to give legal advice, either, or to do corporate taxes, not even with a
computer system and a program written for that application. Not because the
computer system or program can't do it, correctly, but because I can't. I
could get the education and training to do any of those things, but I don't
have an interest in them, so I won't.

Please don't think my remarks are intended to refute the points you've made.
I recognize them as valid and important points. I only attempt to provide
another point of view. My admittedly limited observations seem to indicate
that most  programs have far more features than most users use.
Consequently, they don't even use them to their fullest capability, much
less try to push them to their limits.