home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1970 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  3.7 KB
  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!cs.utexas.edu!sun-barr!olivea!apple!goofy!cambridge.apple.com!ralex@tigger.cs.colorado.edu
  2. From: ralex@tigger.cs.colorado.edu (Repenning Alexander)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: MCL size/distribution (was: MCL support for MOP)
  5. Message-ID: <199301102258.AA24857@tigger.cs.colorado.edu>
  6. Date: 10 Jan 93 22:58:27 GMT
  7. Sender: info-mcl-request@cambridge.apple.com
  8. Lines: 72
  9. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  10.  
  11. Subject: Re: MCL size/distribution (was: MCL support for MOP)
  12.                                                                  
  13. >We'll probably be                                             
  14. >looking into a few ways to reduce the size of MCL (though probably
  15. >not for 2.1).                                     
  16. >1) A tree shaker..
  17. >2) Make the development environment be optional..
  18. >3) One or more shared libraries..
  19.  
  20. Many systems have gone (or like to go) trough the following stages:
  21.  
  22. a) Prototype
  23. b) Testing: Public Domain application
  24. c) commercial application
  25.  
  26. MCL is certainly a great (if not the best) product addressing stage (a). It 
  27. is a great environment to prototype things. 
  28.  
  29. In stage (b) things already become a bit more problematical. A 1.5 MB
  30. "hello world" despite todays improved technology doesn't fly over the
  31. internet. As a source for pre- commercial user testing the internet is
  32. an in-valuable source. However, with a memory demand starting at about
  33. 1.5 MB this is tricky - or lets just say impossible. That is, the size
  34. of your applications has an enormous impact on the testing stage.
  35.  
  36. Stage (c) is even more problematic. Something Lisp users get to hear
  37. quite often is "you did a great prototype in Lisp now lets implement
  38. the application in C." This is frustrating! If my plan is to go on
  39. from stage (a) I don't like to loose all or more of the time I saved
  40. using MCL by strarting from scratch with C or C++ (please no
  41. programming language flames). Lisp has great potential of not only
  42. being a tool to prototype but also to maintain and extend
  43. applications. I like to have a Lisp tools that supports stages a-c and
  44. I don't like to be considered a fool (by non-lisp programmers) for
  45. using Lisp to do so.
  46.  
  47. One could argue that these concerns are only temporary since RAM size
  48. is growing exponential, the price of RAM is decreasing, etc. This is
  49. only of litte comfort for users since they will always compare things
  50. to existing high-functionality applications like Word. After all,
  51. these applications probably have been created by companies like MS
  52. using quite powerfull programming environments as well. All I'm saying
  53. here is that you cannot justify extreemly large applications with
  54. powerfull programming environments.  Switching the environment is not
  55. an option for me (I rather change my profession). Therefore, I can
  56. only hope that the MCL team appreciates a A-C market.
  57.  
  58.  
  59. A GOOD tree shaker would be my favorite. In addition to ordinary tree
  60. shaking it should allow me to explicitely keep/remove entities like
  61. symbols, documentation strings, file references, macro functions, and
  62. entire modules (e.g., compiler, editor, etc). The interface to the
  63. tree shaker should be simple. If I need to "click around" for an hour
  64. it's no good. I could imagine a bunch of keyword added to
  65. save-application (e.g., :shake-tree-p, :strip-documentation-strings,
  66. :keep-symbols (..) , strip-symbols (..)). That's maybe a bit naive,
  67. but you get the idea.
  68.  
  69. >2) Make the development environment be optional..
  70.  
  71. Could this be part of the shaker?
  72.  
  73. >3) One or more shared libraries..
  74.  
  75. This would help me to keep a large number of applications - which I
  76. don't.  Also this fragments my application -> more files -> increased
  77. user confusion.
  78.  
  79. So many demands, so little time ..
  80.  
  81.   Alex Repenning
  82.   University of Colorado at Boulder
  83.