home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / applicat / 8678 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  9.1 KB
  1. Xref: sparky comp.sys.amiga.applications:8678 comp.sys.amiga.introduction:1535 comp.sys.amiga.misc:16873 comp.sys.amiga.advocacy:29161
  2. Path: sparky!uunet!ukma!darwin.sura.net!spool.mu.edu!umn.edu!news.d.umn.edu!ub.d.umn.edu!not-for-mail
  3. From: rfentima@ub.d.umn.edu (Robert Fentiman)
  4. Newsgroups: comp.sys.amiga.applications,comp.sys.amiga.introduction,comp.sys.amiga.misc,comp.sys.amiga.advocacy
  5. Subject: Re: Programming
  6. Date: 15 Nov 1992 14:53:10 -0600
  7. Organization: University of Minnesota, Duluth
  8. Lines: 179
  9. Message-ID: <1e6dbmINNh75@ub.d.umn.edu>
  10. References: <mwm.2n8f@contessa.palo-alto.ca.us> <1e4r1uINN2jt@ub.d.umn.edu> <OAHVENLA.92Nov15135840@lk-hp-4.hut.fi>
  11. NNTP-Posting-Host: ub.d.umn.edu
  12.  
  13. In article <OAHVENLA.92Nov15135840@lk-hp-4.hut.fi> oahvenla@snakemail.hut.fi (Osma Ahvenlampi) writes:
  14.  
  15. >I haven't even seen AmigaVision, so I can't speak for it, but I have done some
  16. >pretty extensive work with HyperCard (a Mac program). It is a multimedia
  17. >program, one of the first. It is also a database, and in fact is to some extent
  18. >marketed as a database. I have done a 1500 card application using sounds,
  19. >text, animation and so on with it, and it wasn't very difficult. In fact, it is
  20. >VERY easy. It has a HIGH object orientation, which makes it very simple to add
  21. >new elements to your programs. True, I haven't seen a spreadsheet made with
  22. >it, but that's because there are already some very powerful spreadsheets out
  23. >there. Show me an AMOS spreadsheet.. I have seen HyperCard based games that
  24. >beat AMOS games easily.
  25.  
  26. Is HyperCard available for the Amiga at all?  Is it the same as th eMac
  27. version?  If not, your argument is pointless.
  28.  
  29. >>look at the AMOS manual.  Also consider getting the AMOS demos (like the
  30. >>demo of AmosPro, available at many FTP sites).  AMOS has over 500
  31. >>commands (in addition to those from the 3D support module), and AMOS Pro
  32. >>has over 700.
  33. >
  34. >Oh, well that tells something about you. If you think lots of commands make
  35. >a language powerful, boy, are you lost... You said that C is a good language.
  36. >Well, C has 32 commands. That twice too many, I'd say.
  37.  
  38. I can tell I'm not he one who needs a compas.  Show me code in C where
  39. routines are not made up of more basic routines.  The more basic
  40. functions you have, the less work you have to do. QED.
  41.  
  42. >Seems like you didn't get it. LoadIFF is probably bug free, but there are
  43. >commands in AMOS that are not. Suppose LoadIFF had a bug, like thrashing the
  44. >picture, if it was size 319x76. Now, you command syntax is correct, where the
  45. >hell is the bug?
  46.  
  47. I understood PERFECTLY what Mike was saying, that the people who wrote
  48. the AMOS interpreter missed all the bugs when they released their
  49. product.  If you would read other sections of my post more clearly, you
  50. would notice I covered this topic. 
  51.  
  52. >On your assembly (I think that was what you meant) program the bug would be
  53.  
  54. You're right, I don't know Assembly at all.  I was giving an example of
  55. the readability of AMOS for debugging purposes vs assembly.
  56.  
  57. >spotted automatically by the compiler. There is no instruction "Move A.x".
  58.  
  59. Pre run time errors are spotted by the AMOS editor as well.  I'm talking
  60. about run time errors.   I know what I am talking about.
  61.  
  62. >BTW: It is obvious you don't even know what you're exactly loading. IFF picture
  63. >is NOT loaded with 11 assembly instructions, or even 20. It can be read from
  64. >disk in that, if you count dos.library calls as one instruction, but after
  65. >that it has to be converted into a bitmap. You can not just show IFF format.
  66. >IFF is interleaved, possible packed, and has a lot more information than just
  67. >the bitmap.
  68.  
  69. It is not so abvious.  I understand 100% what an IFF picture is.  The
  70. code I was trying to represent was the code for an IFF loading routine
  71. (since I don't know assembly, you must give me the benefit of the
  72. doubt).  I was attemplint to show how simple it is in AMOS vs. writing your own
  73. routine in another language.
  74.  
  75. >If you want to do it easily, there is the iff.library. If you want do to it
  76. >more efficiently, retaining simplicity, update iff.lib. In AMOS, you'd have
  77. >to re-compile your program, provided there even is a updated, more efficient
  78. >version available.
  79.  
  80. You forget, most of the time, AMOS programs are not compiled (so other
  81. users can learn from them).  They are interpreted (it IS BASIC after
  82. all), that can be compiled if you want your program protected or to run
  83. faster.  AMOS has access to ALL libraries as well.
  84.  
  85. >You, on the other hand, seem to have VERY little experience, period. Your
  86. >concepts of programming are exactly the things I want to avoid by not using
  87. >AMOS programs.
  88.  
  89. You have NEVER seen anything I have programmed.  You have no right to
  90. judge me as a programmer because of the languages I like to use. 
  91. Granted, I'm no programming wiz (that's why I'm taking CS classes,
  92. having CS as one of my majors).  You have come to the wrong coclusion
  93. saying that I have VERY little programming experience.  My concepts of
  94. programming include modularity, usability, serving the purpose for which
  95. it written.  ANY language can be used to accomplish these tasks.  I like
  96. AMOS because it allows me to do complex things easily without
  97. sacrificing versitality.  I don't need to worry about clipping when I do
  98. a game, for example).  I write programs to do what they are supposed  
  99. to do.   If you think these bad habits, argue with my CS teachers and go
  100. (re)take some classes yourself.  
  101.  
  102. >>>> C is a good language,
  103. >>>
  104. >>>Giggle. Oh well - I guess that's to be expected if you think that
  105. >>>typical AMOS behavior is acceptable.
  106. >
  107. >>I suppose that comment is to be expected for a person who is closed
  108. >>minded that ALL languages have advantages over others.  So exactly what
  109. >>DO you think is a good language?
  110. >
  111. >All languages have advantage over other, just as you quoted. What do you want
  112. >to do? If you just want a general, all-purpose language, I'd choose C, not
  113. >because it's powerful, but because it's pretty easy, well supported, and is 
  114. >found on several platforms.
  115. >
  116. >>animation capability with the same ease.  To play a MOD file in amos,
  117. >>you type Music "<music name>".  Can they have more sprites on the screen
  118. >
  119. >And if you want to play a MED file?
  120.  
  121. Check out Amos Pro.  It does it.
  122.  
  123. >>than is normally allowed by the system (no, I will NEVER deny AMOS's
  124. >>excellence when it comes to making games)?  How about Copper support?  
  125. >
  126. >graphics.library is the only legal way of directly accessing Copper.
  127.  
  128. Talk to Mandarin about this one.  Sooo, Euro demos are illegaly making
  129. good programs.  Hmmm.  Better talk to people on XXX.amiga.demos about
  130. this one.
  131.  
  132. >>Multiple screens of different sizes and resolutions, and manipulating
  133. >>the screens (and I don't mean windows)?  Do they have wide support
  134. >
  135. >I seem to remember something about intuition.library...
  136.  
  137. Can they do it with single commands?  Amos can do it without the hassle
  138. of opening the intuition.library.  Besides, this comment was in response
  139. to Mike saying Amos was restricted to its screen (singular).
  140.  
  141. >>(hundreds of PD programs for AMOS that can be used as tutorials; AMOS
  142. >
  143. >No, I can't use the AMOS programs as tutorials in C or assembly, but (this
  144. >is a raw guess) 40% of PD programs found on Fish disks have source included,
  145. >usually in either language.
  146.  
  147. You missed the point.  I was showing how AMOS is well supported for
  148. someone to learn programming.  Amos has its OWN PD collection as well.
  149.  
  150. >>newsletters; quick return of information and bug fixes from the deveoper
  151. >>- refer to Amazing Computing June '92 review of AMOS)?  Are they limited
  152. >>to a compiler or an interpreted environment?  Do they support CDTV?  I
  153. >>can assure you, AMOS does ALL of these things (and more).
  154. >
  155. >>Are there any professional programs written in these languages (for
  156. >>amos, the award winning Fun School (?), from the Fun, 2, 3 series of
  157. >>educational software (another non-game use of amos))?
  158. >
  159. >>Again, none of these questions are intended to be rhetorical, as I don't
  160. >>know of any of the references you refer to.  And, as you like to point
  161. >>out, your aguments are useless unless ONE language incorperates * ALL *
  162. >>these features.
  163. >
  164. >Your every point for AMOS works for C, the most popular programming language
  165. >in Amiga envinronment. You have yourself stated that AMOS programmers probably
  166. >switch to C at some point. If AMOS was powerful enough, they wouldn't. C is
  167. >not difficult. AMOS may seem easy, but making good code with it is much more
  168. >difficult than it would be with C. In addition, with C you can do 100% system
  169. >compliant code (remember where this thread started from? You seem to have
  170. >managed to turn it into a battle about whether AMOS is easy or not).
  171.  
  172. Oh, and comments like "Amos is a *ROTTEN* introduction language are
  173. staying on that topic?  The discussion started when someone said
  174. basically that AMOS Sucks.  There is NO single topic on this thread.
  175.  
  176. >Osma Ahvenlampi  -  oahvenla@snakemail.hut.fi   * Workstation power for micro-
  177. >All my opinions are not necessarily really mine * computer price: Amiga := FUN
  178.  
  179. BTW, I meant to say it would be best to move this thread to:
  180.  
  181. comp.sys.amiga.programmer
  182.                        ^^
  183. Because it deals with the topic better ( a suggestion hinted at by the
  184. party I referred to in my last post).
  185.  
  186.     Thanks
  187.     Robert Fentiman
  188.  
  189. UseNet: rfentima@ub.d.umn.edu
  190. At: University of Minnesota, Duluth
  191.  
  192.