home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / programm / 15585 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  3.7 KB

  1. Path: sparky!uunet!ogicse!decwrl!decwrl!contessa!mwm
  2. From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: LISP - USE IT.
  5. Message-ID: <mwm.2kwj@contessa.palo-alto.ca.us>
  6. Date: 9 Nov 92 19:31:36 GMT
  7. Article-I.D.: contessa.mwm.2kwj
  8. References: <1992Nov5.014803.1@eagle.wesleyan.edu> <mwm.2jht@contessa.palo-alto.ca.us> <1992Nov6.220216.2313@sth.frontec.se> <mwm.2k43@contessa.palo-alto.ca.us> <1992Nov9.132635.2620@sth.frontec.se>
  9. Distribution: world
  10. Organization: Missionaria Phonibalonica
  11. Lines: 72
  12. X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
  13.  
  14. In <1992Nov9.132635.2620@sth.frontec.se>, bjst@sth.frontec.se (Bjorn Stenberg) wrote:
  15. > mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
  16. > > ARexx is so ubiquitous in the Amiga environment that using
  17. > > anything else calls for a VERY good reason. Being portable across
  18. > > multiple platforms is such a reason.
  19. > Or complex programming tasks. I'm in such a situation myself, and found that
  20. > I'd have to add a lot of things to ARexx to make it suit my needs.
  21.  
  22. If you're doing something complex, you probably want a language with
  23. powerful features to go with it - you know, things like closures,
  24. continuations, garbage collection, list manipulation primitives, etc.
  25. You should probably be using a modern LISP.
  26.  
  27. > bjst@sth.frontec.se (Bjorn Stenberg) wrote:
  28. > > > the language is designed with the target of being easily implemented
  29. > > > instead of easily used...
  30. > > You don't know what you're talking about.
  31. > I think I do. I've done it.
  32. > Having operators looking like "+ 2 5" has no other reason than making the
  33. > language easier to interpret and harder to use.
  34.  
  35. Oh? You don't write macros in your LISP? You don't write programs that
  36. write other programs? You don't read in complex data structures in an
  37. ASCII format? All of those are much easier to do in LISP, either
  38. directly or as a side effect of the s-expression notation the language
  39. uses.
  40.  
  41. Of course, it's no harder to write a LISP parser that reads in
  42. algebraic notation than it is for any other language. It's been done a
  43. number of time, and in those LISPs for which it was done (ITS LISP and
  44. InterLISP) it it was a generally available feature.
  45.  
  46. It's just that programs written in that style are harder to read and
  47. less maintainable than programs written in a normal LISP style. I
  48. don't think anyone wanted that ability badly enough to perpetrate it
  49. on new implementations.
  50.  
  51. > > Use LISP where it's appropriate - where you're doing a large product, and
  52. > > need a powerfull language;
  53. > There are lots of other powerful and versatile languages which aren't TORTURE
  54. > to the user. Choose one of those instead, I'd say.
  55.  
  56. Name one. The requirements are: pointers that can't point at garbage;
  57. garbage collection; a sane typing system (which lets out the entire
  58. FORTRAN/ALGOL and ML families); sane handling of the funarg problem
  59. (which lets out many older LISP implementations); continuations or
  60. something similar; a real macro facility that lets you use the entire
  61. language; primitives for dealing with extensible collections; user
  62. extensions being identical to builtins; user-replaceable builtins at
  63. every level; no important second-class citizens (like functions or
  64. arrays); probably others I've left out.
  65.  
  66. Loosing any one of those is TORTURE. Trivial changes in syntax are
  67. just that - trivia.
  68.  
  69. > > Since FPL isn't ARexx, I'd urge developers to avoid it as well.
  70. > Sometimes ARexx just isn't enough. In those cases FPL is great.
  71.  
  72. When ARexx/C/Modula/Pascal/Eiffel/Sather/ML/Prolog just isn't enough,
  73. LISP is great :-).
  74.  
  75. > Well, we basically share the same opinion: DON'T USE LISP! So perhaps there's
  76. > no need to argue any further. :-)
  77.  
  78. Nope - I believe in using the language that is appropriate for the
  79. task. LISP is appropriate for a large number of tasks.
  80.  
  81.     <mike
  82.