Re: type based aliasing again

[craig AT jcb-sc.com]

>Allow me to share my unsolicited 2 cents with you:
>
>THE CLIENT IS ALWAYS RIGHT.

No, and if you believe that, and conduct your software consultancy
that way, you could easily land yourself in prison, or at least
find yourself liable for several million dollars in damages.  (Hope
you have liability insurance.)

>I know that there are good programmers that don't live
>by this principle (the software is their baby and they
>know best what's good for it), but if you make the
>effort to listen and accommodate EVERY (distinct)
>complaint or request you end up writing better
>software.

Here's a clue: there are six billion people on this planet.  GCC's
"clients", to use your terminology, include every one of them.

If you're saying we should listen *and accommodate* every complaint
or request from *any* of those people, based solely on the fact
that they're a "client", you are delusional.

But prove me wrong.  Take the GCC sources, start your own project,
and take your own advice.  Show us how it makes a better compiler.

(BTW, I agree with the "listen" part of your advice.  But I'd
put "critically" in front of it.)

>Now it may be that the client doesn't know exactly how
>to tell you WHAT she wants, maybe she tries to tell
>you HOW to do it instead, or she doesn't know how to
>say it politely, but this doesn't change the fact that
>you are receiving valuable feedback and you should use
>it.

We have, and we are.

>"I find *extremely* disturbing, sufficient (especially
>in conjunction with the *huge* waste of time this
>discussion has been to date, and will continue to be,
>in various forms, until the end of time)" that the gcc
>maintainers - as compiler writers - and not the
>compiler users, know best how their compiler should
>behave externally.

Then you will continue to be disturbed, since we have proof
positive that at least *some* "compiler users" have not
bothered to even read the C language standard, which *is*
an important component in determining how their compiler
should behave externally.

And if you find it disturbing that compiler developers should
be the most informed about what the pertinent standards and
specifications say about how their product works, then you
really are delusional.

Personally, I'd rather the people who know the most about
aircraft design be the *designers* of the things, not the
passengers, or the flight attendants.

With software, it does sometimes *seem* that we accept software
written by people who know less than the average user of that
software how it should work.

GCC is not, or certainly *should* not be, an example of that!

(If I were you, I'd retract a number of the statements you have
made to this list.  Any potential employer who understands
software development will, upon seeing them, avoid hiring you,
or using your software, like the plague.)

Now, end users certainly tend to have the best idea of what
*their* requirements are.

But *their* requirements are a different beast than the
requirements of how a compiler like GCC should behave.

It is up to end users to reasonably assess how a compiler -- any
compiler -- fits into their plans to meet their requirements.

If they can read the C standard and show that a C compiler does
not meet it, *then* they can claim they know more about how
that compiler should behave than the developers.  If the developers
do not listen, the end users should pick another compiler.

>This sounds to me like Sun's
>position with Java: they designed it, they know best
>how it should be used.

I don't believe Sun has ever said that, by the way.

However, what they likely *have* said is "we designed the language Java,
and we know best how the language should be evolved".  That's possible,
though it has little to do with GCC, since we're not solely responsible
for designing or evolving the ISO C language.

And certainly vendors of Java interpreters and compilers *should*
be the ones most informed about what the Java language specifications
say about how they should work externally.

>Well, if they don't happen to
>take the right decisions most of the time, less and
>less people will follow. I, for one, have stopped
>using it, after initially thinking that it looked
>promising. I am trying to use the computer as a tool
>to solve real problems, not to engage in rituals
>observing holy standards (or procedures, or
>methodologies, or patterns, or other software
>engineering silver bullets).

Then ignore the holy standards, and accept whatever the compiler
does for/to you.  Or write your own compiler.  Or use a compiler
developed by people who promised to listen to *and accommodate*
every single request from every user, or potential user, during
its entire history.

Good luck.

Or you could recognize standards and procedures and methodologies
and patterns and software engineering silver bullets as *tools*
for *you* to use to solve those real problems *better*.  The fact
that you're even subscribed to a compiler mailing list shows
that you depend far more on all those things than you are, probably,
even remotely aware of.

(And to think I used to, so long ago, hear wise old engineers give
me the same advice that I now give, and that I, too, was not exactly
a convinced listener.  Difference was, I was open-minded enough to
*consider* what they said and evaluate it.  Clearly they were right
then; just as I am right now.)

        tq vm, (burley)