Hacker News Reader

Comment by rtpg | Hacker News Reader

The "modifiable image" model to me poses a huge problem of just not knowing what has changed and what is going on. I believe that things like Pharoh integrate into version control, but just on a fundamental level being able to throw away everything and go back to some notion of a clean state is very helpful when working on a mutable system.

Distributed version control and CI makes it way more tractable to work on even a small team IMO.

I would be very curious to see someone stream a "real" workflow using something like Pharoh or other smalltalk-like envs though. There's a bunch of short clips showing "beginner" demos but for such a visual system I would expect there to be more detailed presentations of the actual workflow.

View on HN

Pharo and Squeak had a DVCS called Monticello that integrated with the system much better than git, but they abandoned it in favor of git, primarily so they could use github, expecting it would raise their profile amongst developers (also the VM was already developed there). The end result was the method-level modification history, including timestamps and authorship info, was lost, since it didn't fit into git's model of treating everything as text files or blobs.

Git is also much more confusing than Monticello.

> The end result was the method-level modification history, including timestamps and authorship info, was lost, since it didn't fit into git's model of treating everything as text files or blobs.

That seems odd, they seem easy enough to map to each other?

> Git is also much more confusing than Monticello.

Not my experience. Uni had us use Smalltalk for a bunch of courses, and Monticello was universally hated (and people caused their to-be-expected number of messes with Git too, but still got on with that much better)

> That seems odd, they seem easy enough to map to each other?

Not unless you treat every method-level modification as a separate commit.

Why not? Git should handle this just fine. And you can always make details-in-second-parent merge commits or squash them down later, if you don't like the whole history having that level of detail.

Not just a "modifiable image".

1984 "Smalltalk-80 The Interactive Programming Environment" page 46

"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

    ~ workflow

https://drcuis.github.io/TheCuisBook/Daily-Workflow.html

Appreciate the extra context there!

The workflow link is v interesting. I will repeat my big ask: I want to see people recording themselves using the system! For visual systems often it's in movement that I realize how people actually take advantage of all the tiny components

"Moldable Development: Programming Through Custom Tools"

https://youtu.be/W8TSPED0alY

(No, I didn't watch it.)

> throw away everything and go back to some notion of a clean state

So throw away the modified image and go back to the original image (and sources file and change log file) which you still have "unmodified" ?

Reply on news.ycombinator.com