Excellent point!  One of Smalltalk's many benefits is its ability to
effectively deal with complexity.  Why not leverage the power of Smalltalk
to help deal with the complexities of the very platform on which it runs?
This stuff should not be in the VM, but rather in Smalltalk.  The VM should
provide a basic object engine, and very basic call in and call out protocols
for interacting with the host environment.  Then, things such as the Win32
or X Windows APIs could modeled in Smalltalk, and effectively wrappered.
Platform independence could be achieved 100% in Smalltalk (with full access
to platform specifics) with all of the abstractions completely accessible.
This of course opens up the possibility of crashes, but it also buys you a
great deal of power.

In addition, managing external resources is something that the Smalltalk
garbage collectors do extremely well when given the necessary hooks from
within Smalltalk (i.e. finalization, weak references, etc).  I've wrapped a
number of APIs to create higher level abstractions and leveraged GC to
manage the external resources created during API interaction...and once
debugged, the stuff is rock solid and much safer to use than trying to do
the same from other environments (like C++).

I never realized that one of the design goals for VMs was to protect a
Smalltalker from crashing the image.  Try executing "[true] whileTrue: []".
Assuming that user breaks are disabled and single threadedness, isn't that
just as bad as a crash (or even worse)?

- Stephen

> -----Original Message-----
> From: Paul Fernhout [mailto:pdfernhout at kurtz-fernhout.com]
> Sent: Monday, December 14, 1998 9:09 PM
> To: squeak at cs.uiuc.edu
> Subject: Squeak: who's afraid of the big bad "crash"?
>
>
> The expression: "SystemDictionary become: nil" crashes the 2.2 Squeak
> Windows VM under NT 4.0. Now, admittedly, I was intentionally looking
> for the smallest expression that will crash a Squeak system... To fix
> this may require extra checks which would slow down the VM. I did this
> to raise an important philosophical point about Smalltalk and "crashes".
>
> When I got interested in implementing VMs about fifteen years ago, it
> was in large part to prevent bad pointer related crashes so common from
> C or Forth or Assembler. (Of course VMs have other benefits like
> portability...)
>
> Yet, I see now that I was misguided in thinking a VM would be the magic
> bullet to avoiding "crashes". The reason is, that no matter what careful
> structure I build on top of a VM, I can make some mistake and have that
> structure come "crashing" down upon itself. And even if the VM has not
> crashed, the thing I care about has. And the thing I care about may be
> difficult to debug in its own terms due to internal complexity -- even
> if written in Smalltalk.
>
> You can't make a typical open Smalltalk system bulletproof from a
> user. Someone once said, "Create a system that even an idiot can use,
> and only an idiot would want to use it". Yet, I think Smalltalk loses
> something by attempts to try to be idiot proof and crash proof (in the
> VM sense). The VM, for example, provides a guise of safety - yet, one
> can always mess up the system above the VM, so what is being protected?
> While a well crafted VM may prevent obvious crashes from bad pointers,
> it can't prevent the user damaging their own internal system (or other
> systems through network or file calls).
>
> Certainly, most users most of the time want a version of Smalltalk that
> is as uncrashable as possible. This could be by creating a level which
> the user cannot (easily) modify, for example, by having the development
> tools in one VM which debug a program running in another. In practice,
> languages like BASIC provide great idiot proofing (at a cost of no or
> little self reflection). I think the Smalltalk way should not be to
> idiot proof -- but instead be to make it easy to do good things
> (preempting time otherwise spent doing foolish things).
>
> Likewise, if you admit that anyone with a smidgen of experience can
> crash the system above the VM (intentionally or not -- how many times
> have you put a "self halt" in key display code invoked by a debugger?),
> why not go all the way, and make the entire VM transparent, so that
> every primitive is a recompilable bit of code referenced by the system,
> and allow Smalltalk to handle native pointers? While dangerous, this is
> no more so than doing such by indirect means (recompiling the VM or
> using the Squeak equivalent of VW's "DLL/C Connect").
>
> One reason not to run native code is worrying about the sanctity of the
> image. If that image gets corrupted, you'll never track it down. Phooey
> on that concept. Images should be rebuildable from scratch, and key
> information should be storable in a sturdy way external to a specific
> image. Another (better) reason not to do this is to run untrusted
> portable code on a web server -- this certainly justifies the VM concept
> for those situations.
>
> Once Smalltalk breaks out of the VM mindset and Smalltalk images contain
> information about real world hardware and tools to generate native
> code and native data structures, Smalltalk will become a much more
> powerful and flexible system (finally surpassing Forth in the sense of
> working at any level from assembler to AI).  When one wants safety and
> coziness, one avoids the low level stuff. When one wants speed, for
> example, translating restricted Smalltalk to machine code, one messes
> with the near-the-metal parts of the system (and risks crashes).
>
> Native code tools would also make possible other tools in turn
> that would allow one to use Squeak to create fast machine-dependent
> applets that were independent of Smalltalk once they were finished (like
> sparks thrown off from a fire). Compiler developers have an increasingly
> difficult time keeping up with generating code to take advantage of
> complex processor architectures; Squeak/Smalltalk is a natural
> environment for developing such sophisticated compilation systems.
>
> Using the notion of a meta-system and meta-compiling, one can still
> think of an image/knowledge-base as living above the specific VM
> implementation, even though the image may contain knowledge of how to
> compile VMs that will support that image on various hardware
> architectures. That Smalltalk image/knowledge-base would be like a
> monkey that swings (recompiles itself) from one branch (hardware
> architecture) to another.
>
> People with C compilers live dangerously every day, but somehow survive.
> Can some way be found to have Smalltalk provide the best of both worlds
> (native/VM)? I feel putting machine dependencies in C files and not in
> the image is a violation of the spirit of what Squeak/Smalltalk
> wants to be. I feel having Smalltalk rely on intermediate C code and C
> compilers is a violation of what Squeak/Smalltalk wants to be. C users
> should file their C code through a Smalltalk image with a compiler
> written in Smalltalk to get nice, tight object code, not vice versa.
> Perhaps implementing GCC in Squeak is a beginning (or somehow
> inter-linking Squeak to GCC)?
>
> In any case, my vote for a key Squeak project is to have Squeak able to
> generate, call, and debug Assembler/Machine code for multiple platforms
> (especially for its VM). This is an embracing of the "crash". For
> contrast, people crash Forth systems all the time -- Forth programmers
> do not fear this because restarting Forth is so easy, usually it is just
> a "warm boot" with work left intact. I think that once Squeak/Smalltalk
> implementors put the fear of the crash behind them, we will see amazing
> things -- things that will make Assembler/Forth/C/C++/Java gurus' jaws
> drop -- for performance, for functionality and for time-to-market.
>
> In this regard, Hans-Martin Mosner's <hmm at heeg.de> work on compiling
> primitives directly to native code from within Squeak is leading the
> way.
>
> Similarly, the flip side of "embracing the crash without fear" is that
> one needs better tools for avoiding crashes, dealing with crashes, and
> understanding crashes (perhaps by simulation and tracing and testing?)
> -- no matter what the level of abstraction at which the "crash" happens.
> For example, one could simulate machine code on a virtual CPU written in
> Smalltalk until one felt confident of it, before trying that code out on
> a real CPU. Similarly, while the "halting problem" defines limits, one
> can still use multiple communicating (perhaps nested) VMs to make
> regular system development easier. Smalltalk has always excelled at
> dealing with crashes, and yet it feels to me like it could be even
> better at this, such as by integrating development tools with tools for
> bug reports, testing strategies, code traces, and error logs.
>
> -Paul Fernhout
> Kurtz-Fernhout Software
> =========================================================
> Developers of custom software and educational simulations
> Creators of the GPL Garden with Insight(TM) garden simulator
> http://www.kurtz-fernhout.com
>