[igouy]

> unless one does the mistake of redefining some core class and corrupts the entire image

In which case, one does not save that image ;-)

Or if one chose to save a broken image, one goes back to a previous image and reloads all the more recent logged changes up-to and excluding the change that broke things.

https://cuis-smalltalk.github.io/TheCuisBook/The-Change-Log....

[cess11]

Right, so that was about me having changed something in a Pharo image that was fundamental to the system as such, hence the menus and keyboard shortcuts stopped working. I had to kill -9 from the operating system, and at that point debugging whatever I was debugging didn't feel like a breeze.

But it should be very rare, and besides the change log and similar facilities it's also easy to just make timestamped copies of the image and pushing packages to git.

[igouy]

And that was about me being tired of the bogus Smalltalk's so fragile meme.

So how would we explore fundamental changes that break the debugger? Would the dumbest workable thing be create subclasses without changing the originals?

I have come across someone who genuinely seemed to think that making copies of just the image was a viable approach to version control. Their project failed badly; and they were absolutely convinced the problem had been Smalltalk, when the problem was not understanding how they could use Smalltalk.

[cess11]

I didn't say it was fragile.

[igouy]

> corrupts the entire image

Epitome of fragility.

A different story if you'd gone-on to explain recovery.

[cess11]

Maybe find someone who actually thinks this environment is fragile and bring this hang-up there?