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

  1. Xref: sparky comp.sys.amiga.misc:17022 comp.sys.amiga.advocacy:29353
  2. Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!apple!decwrl!contessa!mwm
  3. From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
  4. Subject: Re: Programming
  5. Newsgroups: comp.sys.amiga.misc,comp.sys.amiga.advocacy
  6. Distribution: world
  7. References: <mwm.2n4z@contessa.palo-alto.ca.us> <1e43mkINNler@ub.d.umn.edu> <92321.133303DXB132@psuvm.psu.edu>
  8. X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
  9. Keywords: 
  10. Summary: 
  11. Message-ID: <mwm.2ojt@contessa.palo-alto.ca.us>
  12. Date: 17 Nov 92 10:38:30 PST
  13. Organization: Missionaria Phonibalonica
  14. Lines: 182
  15.  
  16. In <92321.133303DXB132@psuvm.psu.edu>, <DXB132@psuvm.psu.edu> wrote:
  17. > In article <mwm.2njn@contessa.palo-alto.ca.us>, mwm@contessa.palo-alto.ca.us
  18. > (Mike Meyer) says:
  19. > >> LOTS of stuff.  I HIGHLY doubt that multimedia or presentation tools
  20. > >> have the versatility of AMOS.  How many multimedia programs let you
  21. > >> write spreadsheets and databases.
  22. > >Most of them.
  23. > Name just one.
  24.  
  25. Can do: CanDo can do those things.
  26.  
  27. > Yes, the only thing that matters is what YOU care about. If it doesn't
  28. > satisfy YOUR needs, then it MUST be junk. Again, name JUST ONE
  29.  
  30. Nope; if it's incapable of producing bug-free program, then it must be
  31. junk. And how about AmigaVision?
  32.  
  33. > "multimedia tool" that you refer to. Although, since you imply more
  34. > than one, I would prefer a list. I will email you a 10-line AMOS demo and
  35. > you can duplicate with this tool. (NOT)
  36.  
  37. Better yet, mail me a 10-line AMOS demo that doesn't screw up
  38. commodities.
  39.  
  40. > >If AMOS is so all-fired easy, it should be *TRIVIAL* to write a
  41. > >utility (any utility; you choose it) that meets those criteria.
  42. > Well, since it isn't, I guess AMOS wasn't designed to create the
  43. > boring, slow, graphics-less, animation-less, copper-less, *AMIGA-LESS*
  44. > software you crave.
  45.  
  46. No, it was designed to create nintendo-like games to work in the
  47. mono-tasking, hardware-bashing, MSDOS-like environment you crave.
  48.  
  49. > >In the meantime, are you qualified to judge *ALL* other languages?
  50. > >There are LOTS of languages that make assembler or the FORTRAN family
  51. > >(Pascal,C,Algol,etc.) look painful; they share features with the BASIC
  52. > >family. There are languages that let you do the equivalent of your
  53. > >LOADIFF example with 0 lines of code (click on insertion point; click
  54. > >on "loadimage"; use file requester to select the file; done).
  55. > How usefull is that? COme on, I could say "Want to load an IFF?
  56. > No problem, use DPaint!". Use your brain.
  57.  
  58. Please make sure you know what you're talking about; that's not
  59. DPaint; that's AmigaVision. You know, the point-and-click multimedia
  60. tool that lets you do graphics, animations, and the other stuff you
  61. seem to want badly enough to let it make your system act like a IBM
  62. PC?  Except AmigaVision does it without making your system act so
  63. badly.
  64.  
  65. > >Ignore the last question - if that's the limit of your experience, you
  66. > >aren't qualified to judge if AMOS is easy. Try AmigaVISION, CanDo,
  67. > >SAS, the Director, Visual Basic, enough Scheme to understand
  68. > >continuations, and SmallTalk. Then tell me that AMOS is
  69. > >"super-simple".
  70. > You're mentioning packages that don't even claim to be full-fledged
  71. > programming languages. And AMOS is easy.
  72.  
  73. AMOS is EASY. AMOS is EASY. AMOS is EASY. I said it three times, so it
  74. must be true. Odd; it's so easy that no one can create a multi-tasking
  75. friendly application in it. Or maybe that just makes it less than a
  76. full-fledged programming language?
  77.  
  78. > >All I ask is that someone show that someone state for certain that you
  79. > >can disable the buggy AMOS behavior. That's pretty easy, isn't it.
  80. > Why would I want to disable behavior that let's me write more
  81. > interesting programs, faster?
  82.  
  83. Because it causes the program to behave in obnoxious ways when it
  84. doesn't need to. C packages have a fairly heavy runtime start up. I
  85. turn it of regularly. AMOS has a VERY heavy (in terms of behavior)
  86. runtime support package. How do you turn it off?
  87.  
  88. > Have you ever tried to write a simple
  89. > game in 'C' (or pick any language you mentioned above...most of which
  90. > are so rudimentary that it would impossible)? It's a nightmare of
  91. > RKM calls. You can write an interesting program in AMOS without
  92. > reading -anything- but what's in the AMOS manual.
  93.  
  94. Sigh. You haven't looked into CanDo, have you? Or AmigaVision. You can
  95. write interesting games in either one without reading anything but
  96. their manuals. Unless you're so fascinated by pretty lights that
  97. they're the only thing that make a game interesting.
  98.  
  99. > >Sorry, I *know* that all languages have advantages over others. AMOS
  100. > Perhaps you could apply that understanding?
  101.  
  102. Oh, I do. AMOS is pretty clearn all right for writing things that need
  103. lots of fast moving sprites. No problem there. It's pretty clearly NOT
  104. OK for anything that doesn't need that, because it always ties the
  105. system up as if it did need that.
  106.  
  107. > You call them bugs. They're side effects of the requirements of
  108. > supporting the features that AMOS supports. If you think every routine
  109. > in AMOS should be duplicated, one for games, another (where possible)
  110. > for Intution-compatibility, you're asking for the impossible.
  111.  
  112. Hmm - I never considered that the AMOS design was sufficiently bad
  113. that *everything* it did was incompatable with intuition. If that's
  114. the case, you're right - I'm asking the impossible. Of course, that
  115. doesn't make AMOS useful for anything more than it is now.
  116.  
  117. > >Now, which languages have you worked with that meet those
  118. > >qualifications? None in the list you gave earlier, certainly.
  119. > Again, you seem to be blissfully unware that the popular languages
  120. > (take 'C') were not designed out of ignorance. How many langauges have
  121. > you designed? Also, how fast do you think this hypothetical language
  122. > will be? If it's slower than 'C', no-one will use it for commercial
  123. > software.
  124.  
  125. I've probably not designed more than a dozen languages. That
  126. "hypothetical" one isn't; there are a number of such languages around.
  127. And yes, people *do* use them for commercial software. Of course, your
  128. basic contention is wrong: C++ is replacing C in lots of places, and
  129. it's tends to be slower C.
  130.  
  131. > >> Do they have the same graphics, sound, and
  132. > >> animation capability with the same ease.
  133. > >I don't know, but I suspect the answer is "yes".
  134. > Then you don't know what you're talking about AT ALL.
  135.  
  136. Oh? What languages have you compared AMOS to? C?
  137.  
  138. > >> To play a MOD file in amos, you type Music "<music name>".
  139. > >What? No point-and-shoot? And you call this simple?
  140. > Yes. And I'd call that comment stupid.
  141.  
  142. You're right - saying "Music <music name>" is simple is stupid.
  143.  
  144. > >> Are they limited to a compiler or an interpreted environment?
  145. > >Some yes, some no.
  146. > Really? I'm not aware of any "presentation tool" type stuff with a
  147. > compiler available. Name them.
  148.  
  149. You should pay attention to the context; we were talking about other
  150. languages that were as "simple" as AMOS. Not presentation tools. You're
  151. right - I dont know of a compiled presentation tool. However, I do know
  152. of languages that are noticably simpler to use than BASIC that have
  153. both environments available.
  154.  
  155. > >> Do they support CDTV?
  156. > >All of them can be used on CDTV.
  157. > I know AMigaVision can't be. CDTV is a 1MB system, and AmigaVision
  158. > won't fit.
  159.  
  160. You're right - you can't develop AmigaVision scripts on a CDTV. You
  161. can run them, though.
  162.  
  163. > >Yes, there are. And their professional programs *behave*
  164. > >professionally - they don't shut down intuition control, and they
  165. > >don't interfere with the operation of other programs. The
  166. > >"professional" AMOS programs I've seen don't manage that.
  167. > Style over substance seems to be a motif in your comments.
  168.  
  169. Actually, it's proper system interaction over flash. I'm sorry, but
  170. pretty light shows don't impress me nearly as much as solid, reliable,
  171. well-behaved programs.
  172.  
  173. > Who cares if it's junk and expensive and late to market as long as it
  174. > meets the style guide...
  175.  
  176. Whereas AMOS programs are junk and overpriced and don't ever get to
  177. market? At least, you claim you've not seen an commercial AMOS
  178. programs.
  179.  
  180.     <mike
  181.