home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / misc / 16942 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  6.9 KB

  1. Xref: sparky comp.sys.amiga.misc:16942 comp.sys.amiga.advocacy:29251
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!uxa.ecn.bgu.edu!psuvax1!psuvm!dxb132
  3. Organization: Penn State University
  4. Date: Mon, 16 Nov 1992 13:33:03 EST
  5. From: <DXB132@psuvm.psu.edu>
  6. Message-ID: <92321.133303DXB132@psuvm.psu.edu>
  7. Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.advocacy
  8. Subject: Re: Programming
  9. Distribution: world
  10. References: <mwm.2n4z@contessa.palo-alto.ca.us> <1e43mkINNler@ub.d.umn.edu>
  11.  <mwm.2n8f@contessa.palo-alto.ca.us> <1e4r1uINN2jt@ub.d.umn.edu>
  12.  <mwm.2njn@contessa.palo-alto.ca.us>
  13. Lines: 156
  14.  
  15. In article <mwm.2njn@contessa.palo-alto.ca.us>, mwm@contessa.palo-alto.ca.us
  16. (Mike Meyer) says:
  17.  
  18. >In <1e4r1uINN2jt@ub.d.umn.edu>, rfentima@ub.d.umn.edu (Robert Fentiman) wrote:
  19. >> In article <mwm.2n8f@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us
  20. >(Mike Meyer) writes:
  21. >> >These sound like things you want to write games, or to do
  22. >> >presentations. They also aren't unique to AMOS; any serious multimedia
  23. >> >or presentation tool has those capabilities.  I'd be surprised if most
  24. >> >of those aren't better for building presentations than AMOS. Guess
  25. >> >what that leaves AMOS most suitable for?
  26. >>
  27. >> LOTS of stuff.  I HIGHLY doubt that multimedia or presentation tools
  28. >> have the versatility of AMOS.  How many multimedia programs let you
  29. >> write spreadsheets and databases.
  30.  
  31. >Most of them.
  32.  
  33. Name just one.
  34.  
  35. >Well, since I don't know anyone locally who uses AMOS, I have to ask
  36. >on the net. You're handy. Want to mail me a copy of yours?
  37.  
  38. I'm sure you hang around people who are just as uptight and unhappy and
  39. yourself, therefore it's no surprise you don't know someone using AMOS.
  40.  
  41. >> >Utilities can? System-friendly, AUISG-compliant utilities? The
  42. >                  ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^
  43. >> >evidence indicates otherwise.
  44. >>
  45. >> Database, Spreadsheet, Video-Titler, etc...
  46.  
  47. >What utilities you can write is immaterial. Almost any multimedia tool
  48. >can do most or all of those. What matters is the stuff you ignored; the
  49. >stuff I underlined.
  50.  
  51. Yes, the only thing that matters is what YOU care about. If it doesn't
  52. satisfy YOUR needs, then it MUST be junk. Again, name JUST ONE
  53. "multimedia tool" that you refer to. Although, since you imply more
  54. than one, I would prefer a list. I will email you a 10-line AMOS demo and
  55. you can duplicate with this tool. (NOT)
  56.  
  57. >If AMOS is so all-fired easy, it should be *TRIVIAL* to write a
  58. >utility (any utility; you choose it) that meets those criteria.
  59.  
  60. Well, since it isn't, I guess AMOS wasn't designed to create the
  61. boring, slow, graphics-less, animation-less, copper-less, *AMIGA-LESS*
  62. software you crave.
  63.  
  64. >You're wrong - I have read AMOS code. It's a modern BASIC with lots of
  65. >gaming extensions. If that's radically wrong, let me know.
  66.  
  67. Nope, right on.
  68.  
  69. >In the meantime, are you qualified to judge *ALL* other languages?
  70. >There are LOTS of languages that make assembler or the FORTRAN family
  71. >(Pascal,C,Algol,etc.) look painful; they share features with the BASIC
  72. >family. There are languages that let you do the equivalent of your
  73. >LOADIFF example with 0 lines of code (click on insertion point; click
  74. >on "loadimage"; use file requester to select the file; done).
  75.  
  76. How usefull is that? COme on, I could say "Want to load an IFF?
  77. No problem, use DPaint!". Use your brain.
  78.  
  79. >> I have programmed
  80. >> in AmigaBASIC, C, Pascal, AmigaDOS scripts, UNIX scripts, and AMOS
  81. >> definiely IS EASY.
  82.  
  83. >Ignore the last question - if that's the limit of your experience, you
  84. >aren't qualified to judge if AMOS is easy. Try AmigaVISION, CanDo,
  85. >SAS, the Director, Visual Basic, enough Scheme to understand
  86. >continuations, and SmallTalk. Then tell me that AMOS is
  87. >"super-simple".
  88.  
  89. You're mentioning packages that don't even claim to be full-fledged
  90. programming languages. And AMOS is easy.
  91.  
  92. >All I ask is that someone show that someone state for certain that you
  93. >can disable the buggy AMOS behavior. That's pretty easy, isn't it.
  94.  
  95. Why would I want to disable behavior that let's me write more
  96. interesting programs, faster? Have you ever tried to write a simple
  97. game in 'C' (or pick any language you mentioned above...most of which
  98. are so rudimentary that it would impossible)? It's a nightmare of
  99. RKM calls. You can write an interesting program in AMOS without
  100. reading -anything- but what's in the AMOS manual.
  101.  
  102. >Sorry, I *know* that all languages have advantages over others. AMOS
  103.  
  104. Perhaps you could apply that understanding?
  105.  
  106. >is pretty clearly OK for writing games. Unfortunately, it apparently
  107. >has bugs that nobody knows how to work around, which makes it
  108. >unsuitable for anything else. C is OK as a portable assembler; there
  109.  
  110. You call them bugs. They're side effects of the requirements of
  111. supporting the features that AMOS supports. If you think every routine
  112. in AMOS should be duplicated, one for games, another (where possible)
  113. for Intution-compatibility, you're asking for the impossible.
  114.  
  115. >Now, which languages have you worked with that meet those
  116. >qualifications? None in the list you gave earlier, certainly.
  117.  
  118. Again, you seem to be blissfully unware that the popular languages
  119. (take 'C') were not designed out of ignorance. How many langauges have
  120. you designed? Also, how fast do you think this hypothetical language
  121. will be? If it's slower than 'C', no-one will use it for commercial
  122. software.
  123.  
  124. >> Do they have the same graphics, sound, and
  125. >> animation capability with the same ease.
  126.  
  127. >I don't know, but I suspect the answer is "yes".
  128.  
  129. Then you don't know what you're talking about AT ALL.
  130.  
  131. >> To play a MOD file in amos, you type Music "<music name>".
  132.  
  133. >What? No point-and-shoot? And you call this simple?
  134.  
  135. Yes. And I'd call that comment stupid.
  136.  
  137. >> Are they limited to a compiler or an interpreted environment?
  138.  
  139. >Some yes, some no.
  140.  
  141. Really? I'm not aware of any "presentation tool" type stuff with a
  142. compiler available. Name them.
  143.  
  144. >> Do they support CDTV?
  145.  
  146. >All of them can be used on CDTV.
  147.  
  148. I know AMigaVision can't be. CDTV is a 1MB system, and AmigaVision
  149. won't fit.
  150.  
  151. >Yes, there are. And their professional programs *behave*
  152. >professionally - they don't shut down intuition control, and they
  153. >don't interfere with the operation of other programs. The
  154. >"professional" AMOS programs I've seen don't manage that.
  155.  
  156. Style over substance seems to be a motif in your comments.
  157. Who cares if it's junk and expensive and late to market as long as it
  158. meets the style guide...
  159.  
  160. >Yes, I'll argue that BASIC is not good for learning programming. If
  161. >you want, I'll even dig ou the citations that refer to BASIC as a
  162. >childhood disease (Wirth, among others), because it gives people bad
  163. >habits. Since AMOS has made it to the '70s in terms of language design
  164. >(i.e. - it's a modern BASIC), we're talking about different bad
  165. >habits. And they probably aren't wired into the language, they're
  166. >wired into the package.
  167.  
  168. Among my engineering friends, CmpSci itself is considered a childhood
  169. disease. :-)
  170.  
  171.