[cess11]

Smalltalk-style tooling is mostly used in small businesses selling to either small or niche businesses. Things like custom ERP in manufacturing, custom CRM in insurance. Some military projects have also been done.

The Pharo folks insist on trying to adapt to industry, and that's also the focus of a lot of their published material, though there's still an academic legacy in there.

For me the tricky thing is to find enough time to study the API:s, the programming language is easy to learn the basics of and then one has to figure out the flow in creating a package and adding code to it, but then it's a slog searching and reading the code for hundreds of classes to figure out where the thing one wants resides. On the other hand, when things break it's usually a breeze, the inspection and debugging is great, unless one does the mistake of redefining some core class and corrupts the entire image.

[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?