This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bad puppies and coding practices


>In article <19990212034058.4359.qmail@deer> you write:
>>>and on the whole we'd like to try triggering that sort of thing,
>
>>I meant "try *to avoid* triggering", which I hope was obvious.
>
>Actually, no, it's not obvious at all.   It's better if the compiler
>says `your code is plain wrong, you dummy', but a compiler that breaks
>things when you don't follow clean coding practices is a GREAT teaching
>tools. :->

I agree with that last sentiment, but I'm not sure there'll be much
agreement that *gcc* should default to be a great teaching tool.
And as long as people who *think* they don't need teaching can
turn off its teaching facilities, they'll do it...while the people
who really *don't* need it for teaching would avoid a product
that insists on wildly changing its behavior (even if entirely within
spec) even as their overall product nears deployment stage.

But, as it turns out, if we just concentrate on making it a better
optimizing compiler with only modest emphasis on teaching-tool-like
features (-pedantic, -Wall, etc.), it'll someday, sometime, somehow,
somewhere, teach most of its users *not* to make so many assumptions
about how it works.

And, from an engineering perspective, I prefer that tools as complex
as gcc be designed so they offer a simple "switch" of sorts between
the default mode -- "work as much like you always have as possible" --
and the stress-my-system mode, aka "change as much as you can about
how you work while remaining within specs, so I can see if my system
is designed to use it with the proper tolerances".

(Which makes me wonder if we should offer a switch to make gcc
go increasingly out of spec, for people who want to find the point
of actual failure.  Kind of like how aircraft manufacturers don't
just test to see whether the wings of a jet can flex *within* specs
without breaking, but literally flex them until they *do* break
so they can see how far out of the specs the wings' tolerances are,
or how drug manufacturers stuff helpless animals full of a new drug
until it dies to see what it really takes to do that.  When it
comes to the equivalent for gcc, these days, I feel like I want
to nominate penguins for the testing.)

>A bit like wacking puppies on the nose to teach them proper toilet
>habits... 

I don't know whether there have been better (less physical) methods
devised vis-a-vis house-training dogs, but I'm under the impression
that there have been improvements in "breaking" horses, requiring
much less physical control of the animal and achieving much faster
results.  I gather this has to do with using techniques that gain
the animal's respect using the cues the horses themselves are
genetically predisposed to recognize, as compared to the traditional
methods, which are more like whacking them on the nose with a paper
(use of infliction of pain and direct physical control).

It is true that, if you don't know how to reach the subject directly
using it's own open mind, sometimes the best you can do is develop
some kind of Pavlovian response in it so that it avoids bad behavior.

But, I like to think we can do better.  By figuring out how to earn
the respect of potential gcc users by showing we have a solid appreciation
of what it takes to work in *their* field and, at the same time,
that we won't tolerate their attempting to control us in our own,
perhaps we can gain their respect (making it mutual, since we'll
be coming into the situation with our own respect for their field),
making the job of educating them much easier.

Then, instead of relying on the unexpectedly disastrous-but-conforming
behavior of products like gcc to frustrate them out of employing bad
coding habits, we might find they're much more receptive to employing
*good* coding habits from the outset, making the mutual relationship
much more enjoyable, and less stressful, for all.

In my personal experience, I've found this to be pretty easy with the
Fortran audience, to the (very modest) extent to which I've been able
to practice it.

What we now need is someone who is able to practice these techniques
with regards to the Linux developers, especially Linus Torvalds.

I.e., a "Norse Whisperer".


(Okay, seriously, how many of you *really* saw that coming?  :)

        tq vm, (burley)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]