'''The New Tcl Philosophy''' 
----
 Small core         == Good.
 Static executables == Bad.

 Core only distros    == Bad.
 Fully loaded distros == Good.

----

What bugs me about this ''slogan'' is that we do no necessarily see it
in practice.  For instance - many of the string features that have been
added over the past few years certainly could have been done in an extension
that was shipped with the core distribution - but instead, it went into the
core.

In fact, how much currently in the core has to be there?  Seems to me
that a small core interpreter, able to do loading of scripts, dynamic loading
of extensions, and interpretation of code, would be possible without sockets,
regular expressions, the history command, etc. in the true '''core''' code,
but with all those features distributed in the core '''distribution'''
of code, so that by default, Tcl would include those features - but as
dynamically loaded extensions.

The core itself might need some new features - to provide the abiltiy for
dynamically loaded commands to be treated as byte codes, for instance.

----
''[escargo] 16 Jan 2003'' - But what are the costs and benefits of the different
approaches?

For example, for every feature that '''might''' be '''currently loaded''' or not,
code either has to load it or otherwise test that it is loaded or else handle the
error that results if it not loaded.  That's a burden on the programmer (writing
the code) and on the execution (since it adds some run-time overhead and code volume).

Part of the problem is where the cost is paid.  Is it paid when code gets loaded?
Is it paid when code gets byte-compiled?  Is it paid when code gets executed?

I personally think dynamic linking is great.  I liked it ever since I used it in
[Multics] many years ago.  But there are advantages to statically binding all parts
of a program together.  (In some ways this is similar to the discussions about the
Linux kernel and its loadable modules.)