home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / mcl / 2083 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  2.0 KB
  1. Path: sparky!uunet!olivea!apple!cambridge.apple.com!oddmund@idt.unit.no
  2. From: oddmund@idt.unit.no
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re2: Mother ship App.(flame)
  5. Message-ID: <199301230839.AA17801@sigyn.idt.unit.no>
  6. Date: 23 Jan 93 08:39:05 GMT
  7. Sender: owner-info-mcl@cambridge.apple.com
  8. Lines: 35
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11.  
  12. >The fact is,  MCL makes B I G CLUMSY and BUGGY applications
  13.  
  14. I believe John has a point in that there are a lot of buggy MCL 
  15. applications out there, but that isn't necessarily MCL's fault. 
  16.  
  17. As Howard at UK0392@applelink.apple.com points out, MCL bugs 
  18. which crash the Mac are fairly rare. That may be part of the
  19. "problem": Bugs in MCL programs don't cost programmers enough, 
  20. so they are too easly ignored. At least in my case, I am a lot more 
  21. careful about tracking down bugs and writing correct code in 
  22. the first place when using an environment where the price of 
  23. an error is heigh. I am quite new to Lisp, but I can write 10 pages of
  24. Lisp before I start testing - and still make the program work within 
  25. a reasonable amount of time. That is an important part of the reason 
  26. for increased programmer productivity. It is also the cause of a lot 
  27. of little bugs in little used parts of my code.
  28.  
  29. Add to this the fact that many MCL "applications" are prototypes
  30. and probably quite few go through anywhere near the kind of testing
  31. applied to traditional large market commercial applications. 
  32.  
  33. The Lisp tradition is to make many of the "prototypes" available to
  34. fellow programmers. I really like that tradition, but for obvious reasons
  35. what is given away can not be supported in the same way as what people
  36. pay for (although some people do a good job trying).
  37.  
  38. The "problem" of buggy MCL applications can be viewed from another 
  39. angle: Most of those buggy MCL applications wouldn't have been completed
  40. at all if they had been implemented in another language, and they most 
  41. certainly would not have been less buggy at the same level of fuctionality.
  42.  
  43. Oddmund Mogedal
  44. Norwegian Institute of Technology
  45. oddmund@idt.unit.no
  46.