On Wed, Nov 11, 2009 at 10:58 AM, Andreas Raab <andreas.raab@gmx.de> wrote:

Eliot Miranda wrote:

Andreas counters that implementing the abstractions in the VM keeps them well-defined and free from meddling. But that runs counter to the philosophy of an open system and preventing inadvertent meddling is something Smalltalk has to do anyway (e.g. "Process should not be redefined, proceed to store over it"). The nice things about shooting oneself in the foot by meddling with a Smalltalk system are that a) it doesn't really do any harm and b) the debugging of it can be a great learning experience.

I disagree with both of these statements 100%. First, once you have passed the first invalid pointer to some C function you will find out the hard way that "not really doing any harm" means, oh well it'll crash your image instead of raising a debugger. The consequence of this is that for any serious development you will no longer want to do in-image development; consider writing C code inside the running C app and then have it core-dump every time you misspell something. Not exactly my definition of "not really doing any harm". Secondly, wading through gobs of platform specific code is only a great learning experience if you are trying to learn platform specific stuff. Otherwise it's a useless distraction that only gets into your way of seeing (and using) the abstractions.

I'm saying the opposite. I'm saying one should implement these cross-platform abstractions up in the image. I'm saying that shooting one's self in the foot in Smalltalk is doing something like

Smalltalk := nil

and learning from the result.

The crash on misspellings is a straw man. We've both been in the situation where we've had to debug VM crashes, for a number of reasons, both VM bugs and invalid FFI calls. None of that has made us any the less keen on in-image development.

Attempting to implement cross-platform abstractions is a good learning experience if that's what you're into. Implementing them in a high-level language with good facilities is IMO better than implementing them in C in a context where its very hard to improve them because one can't easily experiment.

If one is in the situation of causing crashes in FFI calls one can always run the VM under a debugger, in which case one is in much the same situation as running in C. It's not much worse. And an FFI can use e.g. exception handling around a call to catch crashes and report them back to the image without exiting the image. This isn't particularly helpful because there's no stack backtrace, simply an exception code, but it at least allows the system to report the bug rather than just crash. To debug it one either has to scratch one's head or fire up that low-level debugger. Giving up on image-based development is a rather extreme reaction.

best

Eliot

Cheers,
- Andreas