[Cuis] Why not just kill changesets?

[Casey Ransberger]

Juan, you've made some interesting points here. I see some of your
reasoning more clearly now. I think the problem with the warnings had to do
with my not understanding some design constraints clearly, and this
clarifies; also, sorry if I offended, that was definitely not my intent.
Sometimes I come off as ranty when I don't mean to: mea culpa.

Comments inline.

On Wed, Jan 2, 2013 at 7:07 AM, Juan Vuletich <juan at jvuletich.org> wrote:

> Ok. This will be long :)


 Yep:)

Casey Ransberger wrote:
>
>> Now that I've wrapped my head around the new Git Cuis dev model, I would
>> recommend grabbing a healthy supply of torches and pitchforks, because I
>> think I'm reaching for a Third Option here. So we're all on the same page
>> about what that means:
>>
>> http://tvtropes.org/pmwiki/**pmwiki.php/Main/**TakeAThirdOption<http://tvtropes.org/pmwiki/pmwiki.php/Main/TakeAThirdOption>
>>
>
> Thanks for the link. Sometimes I have trouble following the stuff you
> quote.


I should work on that. I use too much slang at times.

 I thought about sending this straight to Juan, but why not, whole list. I
>> expect that Juan's arguments will be interesting in this case.
>>
>> Alright! What do we really need changesets for then? Why not make
>> developing the core the same as developing anything else? So if we killed
>> changesets:
>>
>
> Ok. It is a good question. I'll interleave some comments on your
> Cons/Pros, and then add mine.
>
>
>  Cons:
>>
>> - We'd have to engineer our way around the "breaking the update stream"
>> problem. This is work, but I'm sure it's doable. I did it once:) and
>> ContentPack happened because I needed to do a spot of time travel to fix
>> the update stream after I broke it. If I can travel through time, I'm
>> pretty sure we can handle a bootstrapping problem. Especially given that we
>> have the computational equivalent of a TARDIS at our disposal.
>>
>> - Cuis now depends completely on Git. Note: Git is *extremely popular,*
>> not likely to go the way of the dodo any time soon, and maintained like the
>> Linux kernel matters to Linus. Also, switching to another SCM should be
>> relatively trivial when necessary, if not painless. And: Git presently runs
>> most places where Cuis runs.
>>
>
> Ehhh. No. Cuis doesn't depend on Git at all. We use Git as a shared,
> universally accessible repository. We also use it to version files, and to
> ease teamwork. But Cuis is not tied to Git. All Cuis needs is a local file
> system to store files (obviously, a local clone of a Git repository works).


This makes sense.

 - Stuff I've missed.
>>
>
> I add some cons. But before that, I see two ways here. One is to have a
> really small kernel, and load stuff to build images (the Pavel way). The
> other one is to have a bigger image, with packages always loaded, and load
> new versions of packages on top of old ones to update the images (the
> Squeak way). So:
>

Ahh, I hadn't thought about that in this context. It seems to have been a
prominent question in recent times. Monolithic vs. minimal. I favor the
latter, though I'll admit that I don't have a clear idea about how to
arrive there. Fortunately, Cuis is already very small, so it's less of a
pressing concern than it is in e.g., Squeak.


> === Cons (a) miniKernel + loadable packages. Pavel's way:
>
> - The artefact is no longer a Smalltalk-80 system. This is very important
> to me. Smalltalk-80 is a huge landmark in the history of computing. One of
> the main reasons I do Cuis is to preserve and spread this legacy. This is
> the best tribute I can do to Smalltalk-80 and its developers.
>

:) And a fine tribute it is! I don't think I follow this completely though.
It's still the same system which came from PARC. To my mind, if you unload
the system browser, and then load it back in, it's still the same system --
kind of like when the image was run through the tracer to get a 64-bit
image: it's a different representation of the object memory, but still the
same system in spirit.

So I also think maybe I ought to talk about *why* I'd like to be able to
unload things like the UI: mainly for headless web servers, or REST
services in the backend of some big iron system. When you're e.g.
whitepages.com, the sheer amount of traffic means you end up with a fleet
of servers, and there start to be arguments about how to squeeze the best
performance out of them. This has a nasty way of ending in Java. Morphic
does stuff: and stuff takes time and electricity. In applications that
don't need it, there are arguments for and against having it there. For: I
can grab the image from the borked server and have the debugger open and
waiting for me. Against: expensive compute resources that I probably don't
need to be spending on.


> - Not having the dev tools in the image makes modifying it harder.
>

Ah! Okay *now* I think I see where you're coming from. Right! I mean I
wouldn't recommend programming in bytecode or anything:) and I'm not saying
that we should develop in what's basically an OS kernel. Definitely our
development images should have the same set of great tools we've got in
there right now. But I *would* honestly prefer to build the image up from
its component parts when we ship.


> - We're not showing newcomers the beauty of the Smalltalk system, but just
> a bunch of files they need to 'make' in order to have something useful.
>

Again, this isn't my intent. I very much want folks to see the whole system
when they come to it.


> - The mini-kernel will also need modifications from time to time. How do
> we do that? With ChangeSets?
>

I knew you were going to go there:) and I'm pretty sure there's a way to
bootstrap around that using purely git; this is the hypothetical
"dependence" on git that I was talking about originally.


> - Maintenance will take more work. We'd need procedures to update or
> re-create the kernel, build the distributions, QA them, etc.
>

Yeah. And maybe that actually doesn't make sense. To me, this sounds like
the "right" way to do it, but some of that may just be dogma that I've been
indoctrinated with. I definitely *don't* want to create painful,
unnecessary human process. This is an excellent point, Juan.


> - As the only way to update an image is to rebuild it from scratch, people
> wouldn't be able to update their own images. To allow for this, we also
> introduce the Cons of (b), below.
>

There's one that I didn't think of.

=== Cons (b) Packages always loaded. Squeak's way:
>
> - We'd need a package loader with atomic loading. Squeak doesn't yet have
> it, after a decade of using Monticello.
>

Wait -- for some reason I don't think this is true any more. I thought they
added atomic loading in Squeak's MC implementation a bit ago. I could be
wrong, though. Anyhow, good point. There's a pile of work there.


> - We'd need version, dependency, and version dependency control.
> Otherwise, it is not just optional package loading that becomes fragile,
> but the base system itself.
>

We get the versioning part from Git right? And I think the dependency
control part might be undecidable with dynamic typing. I think that part is
a problem with all dynamic languages. There's no way to know for sure what
depends on what, but I definitely see your point. And destabilizing the
base unnecessarily is a bad plan. Point taken.


> - It would be difficult and dangerous to update the Kernel and
> PackageLoader packages.
>

Until we found a way to do it safely. Big pile of work. Totally.


> - In Squeak, we end having package postcripts, and strict load ordering of
> package version. Loading intermediate versions is required. There is, after
> all an update stream, but instead of a small set of changes, each update
> includes all the code. It becomes an huge monster that nobody can audit.
>

Git changes are deltas.


> - Updating an image becomes muuuuuuch sloooooweeer.
>

Agreed.


> - When updating an image it is much harder to understand what happened, to
> adapt our code.
>
>
>  Pros:
>>
>> - No more confusing dichotomy between what's core and what isn't;
>> everything becomes a package, and lives in whatever repository is
>> appropriate. Symmetry. Exactly one way to manage code. Kernel can be
>> reduced to a bloody stump which has the singular ability to load in other
>> packages (attach limbs.) Epic win for modularity.
>>
>> - No more annoying dialogs about unsaved changes in core when there
>> aren't actually any. Everything is a package, so there isn't a distinction.
>> We don't need a special method to determine what's part of core and what
>> isn't WRT the warnings about unsaved changed. Elegance, symmetry, less
>> blivet to worry about.
>>
>
> This is unfair. I answered (I believe twice) about your concerns with
> those warnings, but didn't get a response from you! Please, let's discuss
> those warnings in a separate thread. If we have some use case(s) and some
> discussion, I believe we'll clarify any doubts and come up with something
> that works well for everybody.


I thought I replied to that, but it's in my drafts. Oops. Also, I'm sorry
about the way I phrased that. The short version of what I said was "I get
it now, and yes, the change you suggested does make sense." If I'd sent
that, I think this statement might have made a bit more sense. I brought it
up here because what I was suggesting seemed to obviate that work.


>  - We can completely unload (at least a lot) of the changeset handling
>> machinery*
>>
>> - Smalltalk effectively becomes a peer to kernels which manage code in
>> files, which makes us a lot less of a scary monster to newcomers.
>>
>> - Stuff I've missed.
>>
>> *Actually, I could be wrong about this part. Probably the Git stuff is
>> using a lot of it. But I'll bet a single US dollar against the first of you
>> who says killing changesets won't eliminate some net (as opposed to
>> "gross") code, even if I might lose a dollar for dreaming too hard.
>>
>
> We can see Squeak's experience with eliminating ChangeSets, and Pharo's
> experiments with Pharo-Core. Let's learn from them.


Totally!

 I mean, why do anything halfway;) ?
>>
>> Okay, so I'm totally locking the doors. It's always raining in Seattle,
>> so rebooting the Frankenstein monster shouldn't be hard, I just have to
>> wait for some lightning. If you try creeping up on me, I'll be able to see
>> your torches, so that's not gonna work. Email is the best plan!
>>
>> I can't wait to see what people think about this. Really, it's about
>> whether or not managing code is or is not Smalltalk's problem in the modern
>> world: and that's a hell of a question to talk about, or I think so. I
>> think it's genuinely an important, and open question, specifically in this
>> small community.
>>
>
> Sure.
>
>
>  At this point, we're almost more of a quorum than a community, and so: if
>> we want to do this, we might be able to tackle it, if we as a group found
>> it sensible, before senseless convention takes over and becomes effectively
>> permanent, rigid.
>>
>
> I agree. This is the best time to evaluate all possible options.
>
>
>  Okay now's the time to use your torches and pitchforks. I'll be hiding
>> under the couch. In an unspecified apartment in Seattle. Go.
>>
>
> :) I hope tolerance and respect for everybody's freedom wins.
>

 I was joking about the torches and pitchforks!

Cheers,
> Juan Vuletich
>
>
>  P.S.
>>
>> I presently have low confidence that ContentPack still works right
>> presently:( and I'm okay with that, but either I've got to fix it or we
>> should unload it and move on.
>>
>> --
>> Casey Ransberger
>>
>
>
> ______________________________**_________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/**listinfo/cuis_jvuletich.org<http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org>
>



-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130102/4f12e3f4/attachment-0002.html>