home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / lisp / mcl / 1996 < prev    next >
Encoding:
Internet Message Format  |  1993-01-13  |  4.0 KB
  1. Path: sparky!uunet!olivea!apple!cambridge.apple.com!nrb!keunen@relay.EU.net
  2. From: nrb!keunen@relay.EU.net (Vincent Keunen)
  3. Newsgroups: comp.lang.lisp.mcl
  4. Subject: Re: MCL support for MOP
  5. Message-ID: <19930111131018.6.KEUNEN@nrbmi1.ia.nrb.be>
  6. Date: 11 Jan 93 13:10:00 GMT
  7. References: <9301082050.AA28536@cambridge.apple.com>
  8. Sender: info-mcl-request@cambridge.apple.com
  9. Reply-To: nrb!keunen@relay.EU.net
  10. Lines: 80
  11. Approved: comp.lang.lisp.mcl@Cambridge.Apple.C0M
  12.  
  13.  
  14.     Date: Fri, 8 Jan 1993 23:56+0200
  15.     From: bill@cambridge.apple.com (Bill St. Clair)
  16.  
  17.        We'll probably be
  18.     looking into a few ways to reduce the size of MCL (though probably
  19.     not for 2.1). Some ideas are:
  20.  
  21.     1) A tree shaker to automagically remove parts of MCL that are
  22.        not used by your application.
  23.  
  24. Great!  I think this would be very nice.  I believe it is also the
  25. hardest solution out of the 3 (to come up to the same final size).
  26.  
  27.     2) Make the development environment be optional, or distribute 2
  28.        MCL applications: with & without development environment. Maybe
  29.        even a third application that has just Common Lisp with no
  30.        application framework.
  31.  
  32. If this is very significant, it could help.
  33.  
  34.     3) One or more shared libraries for the different pieces of MCL.
  35.        This will allow small MCL applications at the expense of some
  36.        large inits.
  37.  
  38. For this to be useful, one needs tools that will tell what library each
  39. function comes from, source analysers,... so that we can decide if each
  40. particular library could be left out without to much work (I mean if I
  41. use only 2 functions from a big library, I can probably rewrite them
  42. differently to keep from using the lib.
  43.  
  44.     Feedback please. Do you need these facilities? Other ideas?
  45.     The MCL development team has decided that MCL's size is not the
  46.     most important thing we have to work on right now, but it's
  47.     still important to us.
  48.  
  49. I agree that MCL is much smaller than other lisp environments and still,
  50. is very comfortable (often more).  However, this opens new opportunities
  51. that other environments can't just cope with because of the resources
  52. needed (lisp on unix,...).  So let's not compare too much MCL with other
  53. lisps on other machines.
  54.  
  55. For the moment, the size required by MCL forces it to be focused on
  56. big/difficult projects.  (don't forget the big cognitive load associated
  57. with CL).  I think that having a way to reduce MCL runtimes
  58. (applications generated by MCL) under 1 meg would open the door to many
  59. more possibilities.  People usually start small and then grow bigger.
  60. And if you start small and get a 2meg app, you don't feel well (even if
  61. it will not grow as much after).  
  62.  
  63. There was a small app I wanted to develop: I connect to my bank to make
  64. payments and the like.  I always keep a log of all transactions.  I
  65. wanted to develop a small app that would parse the log file (very easy
  66. in lisp), build a database of all transactions (thank you clos) and then
  67. do some inferencing to cross-check various things.  I would have
  68. distributed this app to all the people that use the bank application.
  69. But it would seem a bit foolish to have the bank app at 300Ko and the
  70. "utility to analyse the log file" at 2000Ko!...
  71.  
  72. I am sure there are lots of utilities that would be very easy to develop
  73. in lisp that don't get developed in C because it's too hard. (think at
  74. all the parsing stuff, rules based stuff, dynamic OO,...).  However,
  75. when you get a 300Ko app or a 2000Ko one, you don't care how much time
  76. the developer spent on it.  You just say the second one is too big EVEN
  77. if it has more features than the other one...
  78.  
  79. To sum up:  yes MCL is small.  But if it were smaller, it would open
  80. many more opportunities.
  81.  
  82. I am still in love with MCL. Be tough with your lovers.
  83.  
  84. Vincent
  85. --
  86. Never trust a pretty header: use keunen@nrb.be to reply
  87. --
  88. Keunen Vincent                  Network Research Belgium
  89. R&D, Software Engineer          Parc Industriel des Hauts-Sarts
  90. keunen@nrb.be                   2e Avenue, 65
  91. tel: +32 41 407282              B-4040 Herstal
  92. fax: +32 41 481170              Belgium
  93.