On 8/1/13, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 1 August 2013 17:07, Chris Muller <asqueaker at gmail.com> wrote:
>>>>> Yes, but the stripping out part is manual. Well, it's scripted [1],
>>>>> and when a new package becomes unloadable I add it to the script, run
>>>>> ... snip ...
>>>>
>>>> I was thinking about something.  Your Stripping script, and any
>>>> external ".st" script for that matter, should be a one-liner simply to
>>>> call one single method, rather than having any sort of code with
>>>> implementation details.  One reason for this is so that browsing
>>>> senders will miss as little as possible due to being externalized in
>>>> an .st script.
>>>
>>> I'm prepared to be argued over to agreeing with you, which means that
>>> at the moment I don't :). The reason is that I don't see a car factory
>>> inside my car: the car factory assembles a bunch of bits and gives me
>>> a car. (This is one of the things that annoys me about Metacello: I
>>> don't want to see ConfigurationOfs in my image.)
>>
>> Good luck with that car company.  :)  A factory with no development
>> tools, and no visibility from the "car", I predict a crash at some
>> point in the near future (pun intended).   :)
>>
>> I guess I regard the the image as both car AND factory.  We're dealing
>> with a car that has the ability to mutate from a Cadillac into a
>> Prius, why shouldn't that capability be visible and managed under the
>> same powerful dev tools as everything else?
>>
>>>> There are two scenarios for deploying a minimal production image.  The
>>>> "conventional" way, used by other languages, is to develop the code
>>>> base in a rich fat image and, when its ready, version it all up and
>>>> Assemble it manually into a brand new SqueakTrunk image, sans all the
>>>> richness.
>>>
>>> No. The usual mainstream approach is the opposite: it builds an
>>> application up from a bunch of libraries together with your own code
>>> to produce a binary. That binary doesn't have an IDE in it, or a
>>> debugger, or anything else that I'd expect from a rich fat image.
>>
>> That's exactly what I said.  "Assemble".
>
> Right, sorry. I saw the "develop the code base in a rich fat image"
> part, and didn't properly register the rest of the sentence.
>
>>> Stripping is _hard_. Just look at all the Self literature. (My brief
>>> Googling has failed me, but I did read an interesting approach in
>>> connection with abstract interpretation.) Well. It's very easy to
>>> remove things from an image. The problem is removing only the bad bits
>>> and leaving the good bits.
>>
>> "Strip" is not a good word because it evokes all the complicated
>> graph-traversal stuff like deploying a "stripped" image from
>> VisualAge.  I'm simply talking about large-grained "unloading
>> extranneous packages", which have no bearing on an app, just as you do
>> with your .st script, for the purpose of running in production with a
>> smaller image.
>
> Come to think of it, I'm not stripping anything. I'm unteasing
> packages and, when they have no higher level packages depending on
> them, I'm adding them to the recipe that builds the image.
>
>> But, I want to be able to TEST my application with a...  let's call it
>> "Reduced" image without having to version all code and re-Assemble it
>> into an entirely new image first.  Smalltalk embraces the idea of live
>> and continuous evolution of software, and so Reduce will be needed
>> much more often than Assemble.
>
> Well, of course, you need to do precisely that, and for good reason:
> how can you otherwise be confident that the thing you _think_ you
> built is the thing you _intended_ to build?
>
> Live and continuous evolution of software is orthogonal to modularity.
> You can get far without it. And having it doesn't mean you stop
> evolving.
>
>>>> The other way, supported only by Smalltalk, is where I start with a
>>>> ReleaseSqueakTrunk image (rich and fat) and develop my code and
>>>> objects until I'm ready to deploy.  Instead of being required to
>>>> hand-assemble a new image I simply Strip the image I'm in and deploy
>>>> that.
>>>>
>>>> (As I type this e-mail, the merits of Spoons approach continue to woo
>>>> me.  Craig?!)
>>>
>>> As Eliot put it, Spoon and my packaging work are pushing two different
>>> things: Spoon produces _minimal_ images, while I'm trying to produce
>>> _modular_ images. If you think of the two processes as vectors,
>>> they're _broadly_ in the same direction, but they're not parallel.
>>
>> Maybe you could help me understand -- what is the benefit of
>> "modularity" at the package level?
>>
>> We all grok the benefit of *functional* modularity -- where individual
>> methods do one and only one thing and individual classes embody a
>> coherent and limited group of related behaviors.  This allows programs
>> to be more understandable and upgradeable.
>>

WHAT ARE THE BENEFITS OF PACKAGE MODULARITY?

>> But what is the benefit of *package* modularity?  To me, it relates to
>> _image size_ and little else.  Less code is easier to understand than
>> more code, it takes up less memory, and probably runs faster.
>
> It relates to libraries. Think of a package as providing some kind of
> library, like openssl does. Do you care about openssl's internal
> architecture? Of course not. But without packages you can't even tell
> where one thing starts and another ends. Initially independent systems
> grow roots into each other until they become inseparable. Once they're
> inseparable, they're less useful, because you can't choose one or the
> other.

+1
And work on it independently.


>> But besides that, more packages complicates Assembly.  And Reduced
>> images are less capable of dealing with bugs due to lack of IDE tools.
>
> More packages complicates assembly? Maybe, but at a sublinear rate:
> you don't care about the parts that make up my package.
>
> I don't intend for people to _work_ in reduced images. That's why I've
> taken such pains to have a ReleaseSqueakTrunk so people still get the
> big box of toys. It's just that the toys are actually separable.
>
>> So, I guess I don't know what a "modular" image is or why I would want
>> one.  My use-cases are I want Rich for development, and Reduced for
>> production.  Both Spoon and your "modularisation-of-packages" work
>> seem equally aimed at the latter goal.  If not, then for what do I
>> want Modular?
>
> So perhaps an analogy. The Squeak image is a bowl of ramen. It has
> bits of pork (because that's my favourite kind of ramen), noodles,
> soup, leaves. How do you know where one noodle starts and another
> ends? They're tangled together. You pull on an ingredient, and hope
> (because this is a highly dynamic, highly reflective environment) that
> when you start pulling on that loose noodle end you don't end up
> trying to cram the entire bowlful of ramen in your mouth.
>
> Spoon's approach is to use a bunch of chopsticks, spear the pork, tape
> the chopsticks to the side of the bowl, and upend the bowl. Only the
> speared bits stay behind. You have a minimal bowl.
>
> What modularity does is not give you a bowl of ramen. It gives you a
> collection of bowls, each of which holds one of the ingredients. If
> you don't like pork, you don't put any pork in the bowl. (Perhaps a
> helpful restaurant will pre-assemble these ingredients into a
> selection of tasty meals!)
>
> Modularity lets you put fences (to switch analogies) around parts of
> the code such that you can understand the system as a whole that much
> more simply. "This uses Tools, and System, and Collections. And
> Kernel, of course."
>
> So modularity exposes the high level structure of the image. Knowing
> that is very useful in understanding the image!
>
>> Thanks.
>
> Sure! I hope I've shed some light on the issue.
>
> frank
>
>