>>> usly mentioned)) that are the abomination. >>> >> in smalltalk code & data is the same - it just objects. >> why you think "changing your brain" should stop you from doing something >> else? >> When you coding in browser, you alsos changing systems brain. > > Yes, there is no difference between loading a package and entering the > same code through the browser... except that in the former case > (without the abominatory modal progress dialogs stopping your) you > might ALSO be adding code, or be running something, or or or. > > So you start loading some package. That package sadly has a bug in its > replacement of Object >> #printString which accidentally kills the > image. You're busy debugging something while that package loads. > You're inspecting something. You inspect it again... and your image > dies! You know you weren't doing anything crazy, so this time it's not > your fault. But was it a VM bug? Some weird edge case in the base > image noone's run into before? Monticello? The package being loaded?
that can even happen without monticello being blocking... > While that package is loading - while you are busy hacking away - the > image is changing under your feet. That is _never_ safe. Now, in happy > land, we'd have sandboxes and isolation and atomic loading and all > sorts of fun stuff so, in happy land, this wouldn't be a problem. But > _today_ it would be a problem. sure it could be, but let's say we make a setting. Cause most of the time I know exactly what I load in Monticello and still wan to be able to work on something else. It's like having a #become: around, nobody stops you from doing silly things with it :). - Most of the UI stuff should be written non-blocking, adding blocking support on top is mostly easy. (in MC the only thing that makes sense to be run in blocking mode is indeed loading, but even that necessarily) - add Options/Settings (maybe with some warnings) so everybody is happy
