Path: utzoo!attcan!uunet!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!apple.com!chewy
From: chewy@apple.com (Paul Snively)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Tail patches
Message-ID: <5352@internal.Apple.COM>
Date: 22 Nov 89 01:47:24 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 129
References:<5212@internal.Apple.COM> <32982@mirror.UUCP> <5248@internal.Apple.COM> <9012@hoptoad.uucp> <5296@internal.Apple.COM> <9041@hoptoad.uucp>

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> You, however, specialize in responses which are inane and
> peremptory; for example, your messages on tail patches that nowhere
> included a technical explanation of the problem with them,

The technical problem with them--that various system patches use come-from 
code to make sure that they work at the right time--has been spelled out 
on several occassions both by Larry Rosenstein and myself, among others.  
My "inane and peremptory" [sic] responses came when people didn't seem to see 
the reasons, or perhaps rather to care that they exist.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> or your
> message on file ids that completely ignored every point I raised (as
> some other posters noted at the time).

I addressed all of your points, as did other people here (Andrew Shebanow 
comes immediately to mind).  I'd be more than happy to continue the 
discussion, although I believe it will be much easier when System 7 final 
ships, since at that point the details of the Alias Manager, et al. will 
be much clearler.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> Another good example would be the current discussion of things that
> Apple has broken.  At first, your position was one of shocked outrage
> that anyone would suggest such a thing had ever happened.  Now that
> people have provided a number of irrefutable examples, you have not
> apologized for earlier questioning their competence or veracity;

I never questioned anyone's competence or veracity; I do often question 
whether some of the changes that we've made constitute breakage, and in 
some cases where they do, whether it's the hardware or software that's 
broken or the documentation.  The problem seems to be that often an individual sees something as broken when in fact the change fixes a problem for a much broader base of people.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> instead, we are supposed to believe that your position all along has
> been what you just changed it to, that Apple does break things
> sometimes but it has good reasons to do so.

This isn't a change; it's a different semantic interpretation of "break."  
If we change something and it makes life overall better than it was 
instead of worse, I don't call it "breaking something," although for the 
small handful of people (relatively speaking) for whom it causes a 
problem, sure, it seems like a breakage.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> And then you've tossed in
> some more inane arguments just to confirm that no one should treat you
> seriously, such as saying that developers should not pay attention to
> explicit instructions in Inside Macintosh.

You have a bad habit of overgeneralizing, Tim.  What I said was that using 
assembly language to directly manipulate something when there is a library 
routine to do so is a bad idea, and that for Inside Macintosh to recommend 
it is also bad.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> You seem to have forgotten that a job in Developer Relations is a job
> in Public Relations; it is not the pulpit of Jonathan Edwards.

I'm not in Developer Relations.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> As a
> result, you are breeding ill-will towards Apple,

I doubt it.  By your own admission, your problem is with me.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> and people are coming
> to ignore your conclusions even in the very rare cases where you
> sincerely try to prove them correct.

For whom exactly are you speaking?  So far, you're the only one making 
these claims.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> >The function of my department is to help people create good, reliable
> >Macintosh software.
> 
> And to maintain good relations with the developer comunity, which by
> nature involves taking seriously objections raised by those
> developers.  Instead, you contemptuously dismiss the complaints without
> dealing honestly with their substance, and you dismiss the complainers
> themselves as "people who aren't as experienced or as well-informed
> about how the Macintosh works".  This is highly obnoxious behavior.

Good point, and I'll take this opportunity to apologize for a comment made 
in frustration.  I do take problem reports seriously, but I do have 
difficulty taking issues like the tail-patching one seriously when it's 
been covered here and in Tech Notes so completely and by so many people.  
I'd also like to point out that professional courtesy is a two-way street; 
a developer statement that "Apple will never fix something that has been 
broken since day one" is a combination of arrogant, ignorant, and rude 
(that's the STATEMENT, folks, not necessarily the person), and certainly 
does nothing to motivate me to lend an ear to what that person has to say.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> >Perhaps I'm like an army drill sargeant or something: I'm harsh, I'm
> >stern, I'm a pain in the ass, but it's all to benefit the person being
> >disciplined.
> 
> Gee, Daddy, thanks a lot.

Gee, Tim, what a substantive rebuttal.  You know as well as I do that what 
makes the Macintosh what it is is precisely the set of standards and 
guidelines that I attempt to promulgate here.

In article <9041@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> And when "the rules" are handed down as infallible and inarguable fiats
> from on high, Apple's image suffers, the developers ignore the rules,
> and the user suffers.

Tim, the reasons behind the rules, guidelines, whatever, have been stated 
time and time again.  You know them.  I know them.  Obviously they change, 
as our hardware and system software changes, but it's just not possible to 
do everything that everyone wants.  In fact, it's not even desirable.

I'm sorry if tons of comp.sys.mac.programmer readers are getting upset 
because I advance our position here so forcefully.  I'll try to tone it 
down.  But Tim, your accusations that I have given no technical reasons 
for what I've said simply don't hold water.  Please go back and look again.

__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they 
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________