On Thu, Nov 14, 2013 at 4:27 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> We talk past each other every time we have this argument.

Not every time -- I've learned a few things from y'all in this community.  :)

> On 14 November 2013 20:47, Chris Muller <asqueaker at gmail.com> wrote:
>> I know module-heads like to say it's all about modularity and not size
>> but I think it being about size is unavoidable.  (And, when I say
>> "size" I'm talking only talking about disk and memory but also
>> coherence which is a valuable thing).
>>
>> Because otherwise "so what" if FFI includes the constants and VMMaker
>> depends on it solely for that portion of it?  How many methods making
>> up FFI are we talking about?  There are plenty of _other_ methods in
>> the image which are not being used by VMMaker, what about them?
>>
>> Acknowledged or not, at some point we're forced to assume a balance
>> between number of extra methods and number of extra packages.  The
>> hand-made-micro-packages approach puts these two metrics at inverse of
>> each other, trading domain complexity for package complexity.
>
> We can argue about the granularity of the packages. I don't really
> care about that. I argue about small packages in the base image only
> because you cannot break the cycles without distinguishing about the
> parts.

Yes, we're in agreement that should be a criteria for determining
package boundaries / granularities.

> Please, please show me that I'm wrong so that I stop tilting at
> the tangle web of windmills. Just take System. That would be a good

Ha, I knew it!  You ALWAYS pick "System" every time we have this argument.   :)

> start. Show me how System makes sense as a package. Because all I see
> is a big fat mess of separate things that have no business being
> together. Projects? Change notifications? UI? Serialisation?

"big fat mess" and "no business being together" are size / coherency
judgements.  Busted!  :)

The truth is, I'm pretty sure we've agreed about System for a while.
If all dependency cycles could be removed, I wouldn't care so much
about System being "big and fat" because I see it as the "Smalltalk
programming system", but I think the cycles probably won't be able to
be eliminated without breaking it up and so it's moot to disagree on
System anyway.

You had brought up a one-class package which is what got this going
this time..  :)

>> This is why want Spoon to make micro-packaging less important.  Let
>> the machine imprint a truly "optimal", application-specific, image
>> that no amount of human-wrangling could ever come close.
>
> Shrinking is useless. You have no idea what you deploy. I _do not

Dabble DB who wanted to run hundreds of images.  I also have cases
where I need to run many images.  For that, shrinking is not useless.
The idea of Spoon is to deploy only one single "fat" image (with
everything you know you need and more) from which as many minimal
images can imprint from.  Since they only download methods they need,
as they get called, memory usage is optimized.

> care_ about this theoretically minimal image, because otherwise I'd
> just copy with Guille Polito's doing, and building up a whole new
> object space starting with nil. _That_ is minimal.

I'm not aware of his work..

> I've been rolling out clearly versioned code, with well-understood
> dependencies, for years now in every language I know except for the
> one I love the most. And in every one of these languages (C#, Ruby,
> Java, Scala) I have had _no_ serious pain in managing dependencies.
> You define your immediate dependencies, and you're _done_.

Yes, we seem to be getting there.