<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Eliot,<br>
<br>
On 11/15/2013 3:38 PM, Eliot Miranda wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE1BAxxVs7SJJzBuPBzbZY4-Jp=FyW2z+nM479CDc5-r2A@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Frank,<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Nov 15, 2013 at 2:14 AM,
Frank Shearar <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On 15 November 2013 02:54, Chris Muller
<<a moz-do-not-send="true"
href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>>
wrote:<br>
> On Thu, Nov 14, 2013 at 4:27 PM, Frank Shearar
<<a moz-do-not-send="true"
href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>>
wrote:<br>
>> We talk past each other every time we have
this argument.<br>
><br>
> Not every time -- I've learned a few things from
y'all in this community. :)<br>
><br>
>> On 14 November 2013 20:47, Chris Muller <<a
moz-do-not-send="true"
href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>>
wrote:<br>
>>> I know module-heads like to say it's all
about modularity and not size<br>
>>> but I think it being about size is
unavoidable. (And, when I say<br>
>>> "size" I'm talking only talking about
disk and memory but also<br>
>>> coherence which is a valuable thing).<br>
>>><br>
>>> Because otherwise "so what" if FFI
includes the constants and VMMaker<br>
>>> depends on it solely for that portion of
it? How many methods making<br>
>>> up FFI are we talking about? There are
plenty of _other_ methods in<br>
>>> the image which are not being used by
VMMaker, what about them?<br>
>>><br>
>>> Acknowledged or not, at some point we're
forced to assume a balance<br>
>>> between number of extra methods and
number of extra packages. The<br>
>>> hand-made-micro-packages approach puts
these two metrics at inverse of<br>
>>> each other, trading domain complexity for
package complexity.<br>
>><br>
>> We can argue about the granularity of the
packages. I don't really<br>
>> care about that. I argue about small packages
in the base image only<br>
>> because you cannot break the cycles without
distinguishing about the<br>
>> parts.<br>
><br>
> Yes, we're in agreement that should be a criteria
for determining<br>
> package boundaries / granularities.<br>
><br>
>> Please, please show me that I'm wrong so that
I stop tilting at<br>
>> the tangle web of windmills. Just take
System. That would be a good<br>
><br>
> Ha, I knew it! You ALWAYS pick "System" every
time we have this argument. :)<br>
<br>
</div>
</div>
It's one of the most egregious offenders, so I'm bound to
pick on it :)<br>
<div class="im"><br>
>> start. Show me how System makes sense as a
package. Because all I see<br>
>> is a big fat mess of separate things that have
no business being<br>
>> together. Projects? Change notifications? UI?
Serialisation?<br>
><br>
> "big fat mess" and "no business being together" are
size / coherency<br>
> judgements. Busted! :)<br>
<br>
</div>
I use a pejorative term here only because System's
(probably) the<br>
worst entangler we have. I want the Squeak base image to
be like a<br>
layer cake. If you draw the dependencies between packages,
and Kernel<br>
sits at the bottom, then all the dependency arrows point
either<br>
sideways (with no cycles) or downwards. System is like a
giant<br>
pineapple sitting in the middle of that cake. It cuts
across these<br>
various layers, because it provides high level
functionality (no good<br>
examples off the top of my head because I'm at work and
don't have an<br>
image open - Project maybe?), low level functionality
(change<br>
notification), and "support" stuff (which largely looks
like a "useful<br>
things that we don't know where else to put" bucket).<br>
</blockquote>
<div><br>
</div>
<div>First let me stress that I agree strongly with your
desire to see the system properly modularized. Personally
I like the image of an onion, but then I like clams in
white wine with onions and coriander much more than I like
cake. Second, I *think* it's impossible with a system
like Smalltalk to meaningfully onionize the core of the
system (i.e. System). That's because it is recursively
implemented. None of the core libraries (arithmetic,
collections) can exist without the kernel execution
classes (behavior, method dictionary, compiled method),
None of the core execution classes can function without
the core libraries (method dictionary is a collection,
arithmetic is used throughout the core system).</div>
<div><br>
</div>
<div>Observe that having a separate development environment
such as Spoon doesn't change much here. We can easily
extract the compiler (and a binary loader) from the
system; it is then inert (cannot add more code) but still
functional. We can use Spoon to create methods in one
image and upload them to another. But within an image
there will always be circularity which is fundamentally to
do with teh system being implemented in itself, with
everything (including code) being objects. And this
property of everything being an object is the single most
valuable property of the system; it leads to the system's
liveness. So at some stage we have to accept the tangle
that lies at the heart of the system. It doesn't have to
be a tangled mess, and can have clean boundaries. But IMO
inevitably at the core of the sytsem there will be some
small number of packages which are inevitably
interrelated, inseparable and unloadable.</div>
<div><br>
</div>
<div>I'm probably teaching you to suck eggs but I had to let
that brain fart free.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> The truth is, I'm pretty sure we've agreed about
System for a while.<br>
> If all dependency cycles could be removed, I
wouldn't care so much<br>
> about System being "big and fat" because I see it
as the "Smalltalk<br>
> programming system", but I think the cycles
probably won't be able to<br>
> be eliminated without breaking it up and so it's
moot to disagree on<br>
> System anyway.<br>
<br>
</div>
Parts of System depending on other parts of System in a
cyclic manner<br>
("intra-package" cycles) don't matter. Unless you try to
break up the<br>
package, of course, in which case you can't load the parts
without<br>
weird preambles and non-MC-friendly things.<br>
<br>
I understand why you see System as being "the Smalltalk
programming<br>
system". I'm trying to untangle what exactly "the
Smalltalk<br>
programming system" actually means, and how it's built. I
suppose I'm<br>
looking at the packages through a microscope?<br>
</blockquote>
<div><br>
</div>
<div>As you well know that won't work. We need to look at
it in large chunks. For me its core class libraries
(essentially Object (so one can add new classes that
integrate with the system), arithmetic, collections and
streams), the execution classes, environments (Smalltalk,
SharedPools), exceptions and some base error reporting
facility. Above that one can add System (managing the
evolution of the environment) & Compiler. Above that
the programming tools. Etc.</div>
<div><br>
</div>
<div>This works (I think) by looking at functionality.
Smalltalk is a programming system used to express
programs. The most elemental programs use arithmetic
and/or collections; the next most elemental programs add
new classes rooted at Object. All these elements are
themselves expressed as objects. These programs may run,
and in doing so may raise errors which need to be
reported. Note that I *haven't* included how those
programs are created in the elemental soup. Whether the
image just is, or whether code is created by the
Compiler/ClassBuilder, or loaded via a binary loader isn't
elemental; the fact that there are at least three ways to
go about it proves this.</div>
<div><br>
</div>
<div>So IMO if you want to break the system into modules you
first come up with a model of the system's functionality,
and you design modules around that model. All forms of
shrinkage, unloading, loading, compiling, remote
debugging, etc, etc are merely arcs in the functionality
model. IMO an elegant functionality model is one where
the atom of functionality is small and can easily be used
to create other compound functionalities in as few steps
as possible.</div>
<div><br>
</div>
<div>So a base headless image with arithmetic, collections,
file streams, execution classes, exceptions, compiler,
read-eval-print-loop and error reporting to standard out
seems close. Another could be arithmetic, collections,
file streams, execution classes, exceptions, error
reporting to standard out, a binary loader and a
command-line argument parser such that one can specify
packages to load. Another might be arithmetic,
collections, file streams, execution classes, exceptions,
and error reporting to standard out, that requires Spoon
to load code into it.</div>
<div><br>
</div>
<div>Once one's chosen one or more of these bases then other
functionalities such as a squeak trunk image with the
programming tools and morphic, or a squeak trunk with MVC,
or a headless scripting environment with a
read-eval-print-loop and lots of file system utilities,
can be constructed by loading modules, and hence those
modules can be derived from what it would take to
construct a functionality.</div>
<div><br>
</div>
<div>If I'm missing the point of this discussion forgive me,
but it seems to me that without a clear notion of what the
atom is there's endless scope for confusion and delay.</div>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
best,
<div>Eliot</div>
</div>
</div>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
I am in violent agreement, in general, with what you are saying, but
I think there are some devilish details out there. Many subsystems
need their hooks deep inside that core. Once they get their hooks
inside, it is hard to separate these subsystems from the core
itself. This becomes especially tricky when the subsystems do, in
principle, belong to the core, but much lighter versions would be
possible. I think that in order to have a small, understandable
core, a useful discipline would be to keep a working, as simple as
possible variant of every component, and not to give in to the
temptation to replace them with richer functionality variations
thereof. All those richer functionality replacements should be
loadable/unloadable.<br>
For example, I think VW made a mistake when introducing XML (a huge
bloat) into the core to replace chunk format with XML. Another
example would be the enhanced debugger, which polluted what was
before a nice and clean parse tree hierarchy with a lot of state
only used by the debugger - all this while the previous debugger was
quite capable and much simpler.<br>
<br>
Regards,<br>
Florin<br>
<br>
<br>
</body>
</html>