home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / apple2 / 25376 < prev    next >
Encoding:
Internet Message Format  |  1992-12-11  |  11.5 KB

  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!stanford.edu!apple!goofy!mumbo.apple.com!gallant.apple.com!city-lights.apple.com!user
  2. From: mattd@apple.com (Matt Deatherage)
  3. Newsgroups: comp.sys.apple2
  4. Subject: Re: The Apple II Now and Forever
  5. Message-ID: <mattd-111292174450@city-lights.apple.com>
  6. Date: 12 Dec 92 02:31:51 GMT
  7. References: <1fa4ssINNmc8@usenet.INS.CWRU.Edu> <Byr8tx.DH0@news.iastate.edu> <mattd-041292181555@city-lights.apple.com> <1fq5vbINNf69@gap.caltech.edu> <mattd-071292114245@city-lights.apple.com> <1g9sb2INNlsd@gap.caltech.edu>
  8. Sender: news@gallant.apple.com
  9. Followup-To: comp.sys.apple2
  10. Organization: Developer Support Center, Apple Computer, Inc.
  11. Lines: 209
  12.  
  13. In article <1g9sb2INNlsd@gap.caltech.edu>, toddpw@cco.caltech.edu (Todd P.
  14. Whitesel) wrote some stuff.
  15.  
  16. OK, let's look at these things.  There's a few misunderstandings here.
  17.  
  18. 1)  Remember how this started?  Hal implied "The original IIgs team wanted
  19. to do X, but Apple wouldn't let them."  I said "I don't see how you can
  20. know that, because you weren't there."  (Neither was I, for those who
  21. don't know, but I know a lot of people who were and I have no evidence
  22. that it was true.)  You said "Ah, the old discredit defense.  When will
  23. you admit that people didn't have to be there to understood what
  24. happened?"  I followed with "You don't have to read Moby Dick to write
  25. a book report on it, and it's just as likely to be accurate."
  26.  
  27. (The above paraphrase is, of course, as I see things.)
  28.  
  29. In the nearly five years I've been doing whatever-it-is-that-I-do, I've
  30. seen an incredible amount of speculation about what goes on behind
  31. the scenes at Apple.  The vast majority of that speculation is, to the
  32. best of my knowledge, flat-out wrong.  For example, in the MacWEEK forum
  33. on CompuServe last night I saw someone speculating "The reason Apple
  34. hasn't put [Macintosh] Network Software Installer 1.3 on ftp.apple.com
  35. yet is because they want us all to use AppleLink and pay those outrageous
  36. fees."
  37.  
  38. The truth, as most readers here can probably guess, is that Mark Johnson
  39. runs the ftp site in his spare time and he hasn't had time to HQX and
  40. upload the new disk, which is only a few weeks old.
  41.  
  42. Most of the speculation I see is like that.  The big one of years gone
  43. by, which is slightly re-emergent today, is "The Apple IIgs team wanted
  44. to make the machine much more powerful but Apple wouldn't let them
  45. because it would endanger the Macintosh."  Now, while the employment
  46. agreement doesn't let me talk about anything that might or might not
  47. have been a product, I am as sure as I'm ever going to get that no
  48. features were removed from the original IIgs to protect the Macintosh.
  49.  
  50. _Hundreds_ of people think they have enough expertise to guess that
  51. what I just said isn't true.  My personal experience shows me that it
  52. is.  That's what I mean when I identify things as speculation and
  53. try to dismiss them, even if I can't talk about all the details.
  54.  
  55. > I do however take issue with your tendency to simply ridicule people because
  56. > you cannot disclose the actual facts that prove them wrong. Perhaps you have
  57. > never considered this, but the person being ridiculed usually is not the
  58. > source of the information, and probably heard it from somebody they thought
  59. > they could trust. No matter what the circumstances, the last thing they need
  60. > to hear is an authority like yourself essentially smugging them off the net!
  61.  
  62. I suppose I could replace "That's silly" with "Whoever told you that is
  63. being silly," but if someone posts something as if they are the author,
  64. I have no way to know they're not, and I don't want to imply people
  65. on here aren't capable of original thought (or even highly demented
  66. thought, which is much more desirable).
  67.  
  68. Hal's original post said something like "Apple wanted to ...."  Not
  69. "According to reports" or "I heard" or "It's been said", but stated
  70. as fact he had personal knowledge of.
  71.  
  72. > [shortcomings of system software]
  73.  
  74. Note:  We weren't originally talking about this; we were talking about
  75. whether people who weren't "there" can accurately know what went on
  76. inside Apple.  However, since you bring it up:
  77.  
  78. There are generally two kinds of criticism of the system software:  "This
  79. is broken, this isn't fast enough, this doesn't work right with that" 
  80. criticism are usually valid, usually bugs, etc.  Even some design issues
  81. fall into this, like "There should have been arbitration of DOC RAM" and
  82. "You should be able to uniquely identify GS/OS devices."
  83.  
  84. The _other_ kind is usually "Apple should have done X but they didn't
  85. because they weren't serious about the Apple IIgs."  (Sometimes this
  86. stops after "Apple should have done X", sometimes not.)  These criticisms
  87. I generally don't find to be valid.
  88.  
  89. "TextEdit should scroll horizontally."  Yeah, it should -- and what that's
  90. already in the system would you like to do without to make the engineering
  91. effort available to do it?  "We should have had HFS and MS-DOS read-write
  92. FSTs in 1988."  Maybe so -- maybe there should have been 500 Apple IIgs
  93. engineers and everything should have been ready in 1985.  In reality,
  94. resources are limited and if I had to make the decisions about what got
  95. done and what didn't, I'm not sure I wouldn't have decided the same way.
  96.  
  97. I find a lot of criticisms of the system to fall into this latter
  98. category of "I think Apple should have done different things with the
  99. IIgs."  You can think that, go ahead -- I think that in some cases.
  100. I generally find the decisions that engineering made about what to
  101. do with the resources they have to be quite solid, and those I'm
  102. perfectly willing to defend.
  103.  
  104. > But I can't and never have
  105. > claimed to tell you what goes on at Apple as if I had secret agent 
  106. > equipment hidden in every cube!! Only you seem to believe that I am
  107. > saying that.
  108.  
  109. No, I didn't say you did, either.  We were originally talking about
  110. "The Apple II team  wanted to make the first IIgs multitasking but 
  111. Apple wouldn't let them."  No one who wasn't there can know if that's
  112. true or not, but from what I know I don't believe it to be true.
  113.  
  114. > if you spent more brain power
  115. > analyzing what you read, you'd waste less of it in replying to things the
  116. > author quite evidently never intended!!
  117.  
  118. "Ha!", he says, in his best Jon Lovitz voice.  "You've never worked in
  119. DTS!"
  120.  
  121. Some days in this job you get the strangest, most absurd questions you
  122. can possibly imagine from developers.  You'll read them about ten times
  123. and you'll say "They can't possibly mean this, they mean this other
  124. thing."  So you answer the other thing, which is an eminently reasonable
  125. question, and you get back a huge flamer saying "I DIDN'T ASK YOU THAT!"
  126.  
  127. Most of the time, there's been a misunderstanding way up the thought
  128. chain and the programmer is lost on the wrong branch of the tree.  He
  129. doesn't know this, of course, so he asks a question at the twig-level
  130. and not at the trunk-level.  So you answer the question at the twig-level
  131. and, surprise!  It doesn't solve the problem.  So you ask what the
  132. trunk-level problem is, and you backtrack, and eventually you get to
  133. where the thought error happened.  You've probably seen this on GEnie
  134. in more than one case -- "Can you tell us more about what you're trying
  135. to do with this so we can suggest some alternate strategies?"
  136.  
  137. There was a _great_ example of this on GEnie (and on AOL too) just this
  138. past week from a new Apple IIgs programmer, who asked "Can I call
  139. ModalDialog with a filter procedure from an NDA?  When I do, it crashes."
  140. Those who are into this know there's no reason that it shouldn't work,
  141. so we asked him to give us more details.  As it turned out, he was
  142. converting it from an application and was calling StartUpTools for
  143. all the standard application tools from within his NDA's Open routine.
  144. This is apt to cause all kinds of trouble, but (of course) he had no
  145. idea this was a problem at all.
  146.  
  147. Experience shows me that if we _hadn't_ answered the twig-level question
  148. ("Can you use filterProcs from ModalDialog in an NDA?"), he wouldn't have
  149. been happy until we did.  The authoritative "Yes, something else must
  150. be wrong" satisfied him, but sometimes it doesn't.
  151.  
  152. I have no problems admitting that this newsgroup normally tires me out,
  153. and I don't read any messages except those with interesting titles.  I
  154. sometimes lose patience because there are a lot of people reading this
  155. who have a lot of time on their hands and therefore assume that I must
  156. have a lot of time as well.  Saying "No, something else must be wrong,
  157. what else are you doing" is just as likely to produce a flame war as
  158. it is to start something useful.  That's why, on here, generally I
  159. restrict myself to correcting errors I see elsewhere or answering twig-
  160. level questions.  There are questions on here that could be answered
  161. on GEnie (or AOL or elsewhere) with a minimum of back-and-forth, but
  162. it never happens that way here.  People come in and complain that I
  163. should have given a full answer the first time, or someone comes in and
  164. suggests something completely irrelevant and starts flaming when it's
  165. suggested that this is completely irrelevant, or in some documented cases
  166. it produces a stream of Email to my personal account at the rate of two
  167. technical questions per day for about eight weeks.
  168.  
  169. So sometimes on here we don't get past the twig-level question.  That's
  170. regrettable, but that's the dynamics of this group.  It's different on
  171. the commerical services, because for some reason people take their time
  172. more seriously when they're paying for it.  It might be different on
  173. the net if comp.sys.apple2.programmer had passed, and I hope that when
  174. it's eligible for voting again in February that people will pass it
  175. this time, because the lack of it _does_ keep people like me from
  176. giving more in-depth technical help on here, because I always regret it
  177. in the end.
  178.  
  179. (I'm probably going to regret having said this much, too, but at least
  180. I could redirect flames to alt.i.hate.matt.)
  181.  
  182. > This is the FIRST time I've ever
  183. > heard you mention that somebody else at Apple disagrees with your version
  184. > of history.
  185.  
  186. If I have personal knowledge of something, I say it as fact.  If I don't,
  187. I say it as opinion ("I believe," "I have no evidence," etc.)  If this
  188. is not true, it's a mistake on my part, because I intend to do it this
  189. way.
  190.  
  191. > where
  192. > somebody attacks a weak spot in the system and your response just diffuses
  193. > their question with virtually ZERO information content.
  194.  
  195. When it comes to "Why did Apple decide to do X instead of Y," most of the
  196. time I can't tell you, even if I do know (mostly I do, sometimes I
  197. don't, sometimes I've been told but I find it hard to believe).  I can
  198. see how trying to answer this without revealing things I can't could be
  199. seen as providing zero information content -- but in those cases the
  200. point is usually "It's not that easy a decision."
  201.  
  202. > And if they manage to set off one
  203. > of your infamous red flags in their initial post, well you might as well let
  204. > somebody else answer. This doesn't get THEM much of anywhere, and they don't
  205. > even know what they did wrong.
  206.  
  207. My #1 red flag is repetition -- I absolutely can't stand having to answer
  208. the same questions over and over, which is one reason I've written so
  209. many Technical Notes.  If comp.sys.apple2.programmer passes, I hope there's
  210. a good FAQ list.
  211.  
  212. > Todd Whitesel
  213. > toddpw @ cco.caltech.edu
  214.  
  215. ============================================================================
  216. Matt Deatherage, Developer Support Center, Apple Computer, Inc.
  217. Personal mail only -- please POST technical questions, questions about
  218. Apple and its policies, where to find documents and related inquiries.
  219. The opinions I express don't represent Apple, which makes us both happy.
  220. ============================================================================
  221.