3 ms·
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 i
by rtpg 1y ago
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.
- mkfs 1y agoPharo 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.
- detaro 1y ago> 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)
- mkfs 1y ago> That seems odd, they seem easy enough to map to each other? Not unless you treat every method-level modification as a separate commit.
- TOGoS 1y agoWhy 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.
- igouy 1y agoNot 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/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... ~ workflow https://drcuis.github.io/TheCuisBook/Daily-Workflow.html https://drcuis.github.io/TheCuisBook/Daily-Workflow.html
- rtpg 1y agoAppreciate 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
- igouy 1y ago"Moldable Development: Programming Through Custom Tools" https://youtu.be/W8TSPED0alY https://youtu.be/W8TSPED0alY (No, I didn't watch it.)
- igouy 1y ago> 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" ?