Il peut être utile d'ajouter une petite leçon d'histoire : Smalltalk a été créé dans les années 1970 au Palo Alto Research Center (PARC) de Xerox. Au même moment, au même endroit, l'informatique personnelle a été inventée. C'est également au même moment, au même endroit, que l'Ethernet a été inventé.
Smalltalk était un système intégré unique, c'était à la fois l'IDE, l'interface graphique, le shell, le noyau, le système d'exploitation, même le microcode de l'unité centrale faisait partie du système Smalltalk. Smalltalk n'avait pas à gérer des ressources non-Smalltalk provenant de l'extérieur de l'image, parce qu'à toutes fins utiles, il n'y avait pas d'autres ressources que Smalltalk. n'était pas "extérieur" . Il était possible de recréer l'état exact de la machine, puisqu'il n'y avait pas vraiment de frontière entre la machine virtuelle et la machine. (La quasi-totalité du système était implémentée en Smalltalk. Il n'y avait que quelques petits bouts de microcode, d'assemblage et de Mesa. Même ce que nous considérerions aujourd'hui comme des pilotes de périphériques était écrit en Smalltalk).
Il n'était pas nécessaire de maintenir des connexions réseau avec d'autres ordinateurs, car personne, en dehors de quelques laboratoires, n'avait besoin d'une connexion réseau. avait des réseaux. En fait, presque aucune organisation ne possédait plus d'un ordinateur. Il n'était pas nécessaire d'interagir avec le système d'exploitation hôte car les machines Smalltalk n'avaient pas de système d'exploitation ; Smalltalk était le système d'exploitation. (Vous connaissez sans doute la célèbre citation de Les principes de conception de Dan Ingalls derrière Smalltalk : "Un système d'exploitation est un ensemble de choses qui ne s'intègrent pas dans un langage. Il ne devrait pas y en avoir.") Smalltalk étant le système d'exploitation, il n'y avait pas besoin de système de fichiers, toutes les données étaient simplement des objets.
Smalltalk ne peut pas contrôler ce qui se trouve en dehors de Smalltalk. Il s'agit d'une propriété générale qui n'est pas propre à Smalltalk. Vous pouvez rompre l'encapsulation en Java en modifiant le bytecode compilé. Vous pouvez rompre la sécurité des types en Haskell en modifiant le code machine compilé. Vous pouvez créer une fuite de mémoire en Rust en modifiant le code machine compilé.
Ainsi, toutes les garanties, caractéristiques et propriétés de Smalltalk ne sont disponibles que tant que vous ne quittez pas Smalltalk.
Voici un exemple encore plus simple qui n'implique pas la mise en réseau ou le déplacement de l'image sur une autre machine : ouvrez un fichier dans le système de fichiers de l'hôte. Suspendre l'image. Supprimez le fichier. Reprendre l'image. Il n'y a pas de moyen possible pour reprendre l'image dans le même état.
Tout ce que Smalltalk peut faire, c'est approximatif l'état des ressources externes aussi bon que possible. Il peut tenter de rouvrir le fichier. Si le fichier a disparu, il peut éventuellement tenter d'en créer un avec le même nom. Il peut essayer de reprendre une connexion réseau. En cas d'échec, il peut essayer de rétablir la connexion, de créer une nouvelle connexion à la même adresse.
Mais en fin de compte, tout ce qui se trouve en dehors de l'image échappe au contrôle de Smalltalk, et Smalltalk ne peut rien y faire.
Il convient de noter que cette discordance d'impédance entre l'intérieur de l'image et le "monde extérieur" est l'une des principales critiques formulées à l'encontre de Smalltalk. Et si vous regardez les systèmes Smalltalk qui essaient de s'intégrer profondément dans le monde extérieur, ils doivent souvent faire des compromis. Par exemple, GNU Smalltalk, qui est spécifiquement conçu pour s'intégrer profondément dans un système Unix, renonce en fait à l'image et à la persistance.
