We talk past each other every time we have this argument.

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. 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
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?

> 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
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'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_.

frank