Dylan rather than CL -- why?

[fhd@panix.com (Frank Deutschmann)]

I'm new to Dylan and this group (just finished skimming the
Dylan book), so please accept my appologies if this is a FAQ or
"taboo" ( :-) ) subject!

In Ike Nassi's Preface to the Dylan book, he says something along the
lines of Common Lisp being for exploratory programming with some
delivery capability, and Dylan being aimed at delivery with some
exploratory capability.  I would really like some clarification of
this statement from someone with Lisp/CLOS, Scheme, and Dylan
experience; my intent is certainly not to provoke a language war, but
rather as Dylan is "the new kid on the block" (so to speak), I would
like to know what its benefits are over the languages I'm experienced
with.

My main questions are:
	1) Is Dylan simply a slimmed down CLOS, stripped of hoggish
features?
	2) What is the motive for a "smaller" language?  Is the
prime motivator run-time overhead, developer learning curve, or
something else?
	3) Why seperate the developmet environment from the language?
	This is the most difficult for me to understand: OO languages that did
not specify their development environment (C++, Ada, Prolog [not OO])
are now stuck with a multitude of development environment, each with
its own set of quirks and developer learning curve.  While most have
some commonality (the Smalltalk-lik "browser" seems to have caught on,
to say the least), each environment is incompatabile with the others
for a particular language, requiring that developers spend time
re-learning the development environment when they switch (which
happens often, as developers move from project to project).
	It also seems to me that those languages which have attached
environments (Smalltalk, Objective-C, and the Symbolics environment [though not
strictly *A language specification*]) have had the biggest impact on
the programming world: I believe that it is the close relationship
between language and development environment which has made these
language systems, and the OO concepts they introduced, change the way
the world thinks about systems development.
	So when the development environment is so important to end
product, and the language is "oriented toward delivery," why separate
the environment from the language?  Clearly, one of the arguments may
well be that to keep memory footprint small, you don't want to deliver
the development environment with the product.  But that seems a rather
irrelevant argument; virtually all current Lisp environments have the
capability to deliver "stripped" systems.  In addition, where the
target hardware can support it, it is nice to have at least some of
the development environment present, to allow end-user programming and
live system debugging.
	A more significant argument which I could forsee would be the
desire not to dictate a paradigm for programming in a group
environment.  One of the most significant drawbacks to Smalltalk,
IMHO, is its lack of support for large scale projects which involve
many developers; while third parties have developed environments which
provide improved support, that, of course, eliminates some of the
benefits of having a standard development environment.  I would think
Dylan would provide far more benefit if a standard development
environment, which has implicit support for large-scale development
effots, had been specified with the language.

	4) What about compatability with (meaning "linkage to")
existing languages, such as Lisp, C, Scheme, Prolog?  The Dylan book,
so far as I can see, make no mention of capability for inter-language
calls, though that would seem to be a real nice feature to have,
especially on systems short of horsepower (where you would probably
like to drop into C for some tasks).  I can't help mentioning the
Poplog envionment here: with all languages easily interacting, the
"synergy" can really help get systems built, with each language used
for what it does best.  I think that the continued preocupation to
come up with one do-all best general purpose language has been a real
step backwards -- better to have some "killer" concepts which
languages stick to, with languages aimed at specific problems and tied
together with a powerfull development environment.

Interested to hear you comments,
-frank