I watched the video when this was last submitted and he makes some interesting points with many of which I disagree.

Images as illustrations in the code:

Yeah, sure, it would be nice to have the Vitruvian Man in the code, but it's also nice to be able to re-open your text file in 5 years, when development on the IDE has stopped and it no longer runs on current operating systems. Also, animations would be hugely distracting.

Code cells:

With jupyter and spyder I have been bitten by lingering obsolete state from re-running cells or code blocks various time. I find the program much easier to debug if it runs on a clean slate and builds all the state from scratch. If building state takes long, I try to cache, save it to disk, and go from there.

Nonetheless, an interesting perspective.

> With jupyter and spyder I have been bitten by lingering obsolete state from re-running cells or code blocks various time. I find the program much easier to debug if it runs on a clean slate and builds all the state from scratch.

Hm, reading this just made my brain connect the reasons I don't like Jupyter with the reason I am baffled by people who like Smalltalk. An image that you can't fully restart just... doesn't seem like a pleasant development environment.

Exactly. How are you supposed to code review something that lives in RAM?

I'm guessing you have never tried these things but image based Smalltalk implementations have supported VCS for decades now, literally. In Pharo this is with git using Iceberg:

https://github.com/pharo-vcs/iceberg

They even wrote a tutorial to make it easier: https://github.com/pharo-vcs/iceberg/wiki/Tutorial

It's not magic, it's not even a problem, because the problem you're imagining doesn't actually exist. So long as the user of the system has at least half a brain (and maybe less) they will be capable of distributing their code with git these days.