[Vm-dev] bootstrapping (was "Support for OpenBSD (#413)")

Craig Latta craig at blackpagedigital.com
Thu Aug 15 14:12:49 UTC 2019


Hi Norbert--

> > > Pharo since version 7.0 is bootstrapped on every build. And it is
> > > surely the best way to get a reliable artifact.
> >
> > The approach you cited uses a plethora of external tools processing
> > source code. That's composition, but not bootstrapping (something
> > building itself, or "pulling itself up by its own bootstraps“).
>
> You are of course welcome to put your own definition of bootstrapping.

     Heh; unsurprisingly, I assert that it's your usage that departs
from the traditional meaning. :)

> But why is this better?

     Something building itself is better because it minimizes the
cognitive load on the human attempting to understand it, by not
involving so many external tools whose compositions and interactions
must also be understood. It presents a more concise statement of what
the system is.

     For me, this makes working on the system more fun, faster, and
easier to teach. I also find the resulting systems are less brittle,
because there are fewer independently evolving components which can
break things.

> So bootstrapping should mean no operating system, no interpreter (like
> a shell) in between? Where is the defined border?

     As much as possible, sure. In this case I'd use an operating system
only as much as I needed to run a virtual machine. (Bootstrapping the
virtual machine is a large area of this conversation, as yet unentered. :)

> I’ve never compiled a C compiler without having an assembler and C
> compiler, a shell and shell scripts at hand. So I’m really interested
> where it is defined exactly.

     I think the nature of the resulting artifact influences how
relevant bootstrapping is. When building a C compiler, you probably
don't care how it was that the existing C compiler you're using came to
be. And developers using the built C compiler are usually much less
concerned with dynamic behavior and self-reflection than Smalltalk
developers are.

     The example I would use is of a germinating seed. I think it's
appropriate to allow special behavior earlier, leading to the existence
of seeds, that is repeated less often later. We should minimize that
part. Most of the work is then done by the seed operating upon itself,
not by outside things operating upon it.

> Pharo constructs in an image another image from nothing, then it loads
> some binary packages until the point it has a compiler. I’m not sure
> at the moment if the compiler recompiles everything again. I think you
> can call that bootstrapping.

     I don't. That's one Pharo system composing another one, according
to a plan which exists in the union of the first system and a bunch of
external scripts fed to external tools. The plan is the interesting
thing, and it's far from nothing.

> I agree that the set of external tools should be small. By using the
> term „reliable“ it was regarding the artifact produced a.k.a the
> image. In the sense of being able to produce a bit-identical artifact
> you can reason about.

     Right, that's what I understood you to mean.

> Maybe I should have used reproducible to make it more clear.

     I think reproducible composition is actually what you're
discussing. One can achieve it with bootstrapping, and also with what
Pharo is doing. :)  The two are not synonymous, so I don't think it's a
matter of being more clear, or which natural language we're using here.

     Certainly reproducibility is a crucial quality; reflectivity and
minimalism are as well. The object memory composition Pharo does is a
very useful step, but there's more to do before achieving bootstrapping,
and the specification and comprehension benefits that come with it.


-C

--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
craig at blackpagedigital.com
+31   6 2757 7177
+ 1 415  287 3547



More information about the Vm-dev mailing list