🚀 go-pugleaf

  
  ...

  A general philosophical point is in order, however: The traditional
  problem of Lisp systems has been creating minimal applications.
  Carrying around lots of extra baggage such as optimizing code,
  compilers, and interpreters just continues this negative aspect.  The
  problem that we should be attacking in designing modern Lisps is the
  ability to create small, efficient applications which do not require
  enormous complexity to implement.  I think this is the major general
  complaint against Common Lisp and CLOS + MOP.  (Of course, there are
  any number of problems with specific language aspects due to
  featurosity accretion.)
  
You can certainly blame Lisp for being big, but you can also blame your
operating system.  For example, a lot of your extra baggage could be shared
among all your applications.  While this happens on Lisp machines, it does
not happen, yet on UNIX machines.

What would you leave out of CLOS and the MOP?

  Scheme has solved the problem to some extent, but the price is a
  language which many Lisp users would consider lacking in utility.
  
  EuLisp and Le-Lisp version 16 try to solve this problem by adding
  module systems and eliminating the guaranteed runtime mapping of all
  symbols to functions/values, along with some other improvements.
  
     Also, I'm not sure how your point about functions is related to
     dispatch optimization, but many unwanted runtime bindings between
     names and functions could be eliminated with some combination of
     unintern and setf of fdefinition.  (Not so for common-lisp package
     functions, of course.)
  
  If you accept that I was talking about a different kind of
  optimization than you, it should be clear that the points are related:
  both the fully extensible MOP and the guaranteed runtime name/function
  binding make it difficult to create small applications.
  
Why?  I can imagine a delivery strategy where the MOP could be quite useful
in delivering smaller applications.  For example, once you are willing to
crystalize your application by doing a DISKSAVE or whatever, CLOS has as
much knowledge about your program as C++ does.  Simply by loading the
appropriate metaclasses, and recompiling your software, you could have a
more compact, efficient application.  This would be better than having a
bunch of compiler switches because it makes things more user accessable.

Now your application may still be big because of other Lisp baggage, but
not because of the MOP.  Lucid's Energize environment for C++ development
provides a clean separation betweeen powerful development tools, and
compact delivery.  If we had a Lisp that could make that same separations,
i don't see why it wouldn't fit quite well into the constraints of some "modern"
operating system. 

k