Side note. One of the cooler things I ever saw Claus Gittinger do with his innovative Smalltalk/X was implement a user space file system interface to the Small

Side note. One of the cooler things I ever saw Claus Gittinger do with his innovative Smalltalk/X was implement a user space file system interface to the Smalltalk image/object memory. You fired up a Smalltalk virtual machine, and then did a mount. The root Smalltalk namespace became the mount root. Classes were directories, subclasses sub directories I think?. Methods showed up as files, meta data (like class properties) showed up as special files (dot files maybe? It’s been too long). Because Smalltalk/X had private (or scoped) classes, Namespaces wet just classes themselves. It was pretty cool. You could grep, ls, navigate. But it wasn’t just for viewing! If you vim’ed a method/file and saved it, it changed the method. Of the live system? Want to rename the class? Just mv it. Also useful for changing class hierarchies. And because Smalltalk, was this crazy navel gazing virtual machine with turtles all the way down… you could cd to the very objects that molementuaons of the live user space file driver! I think the author of the original article is naive though. While this was cool and meta, it actually demonstrated one of the problems that the Smalltalk Browser with its direct integration to live object memory of code objects was trying to solve. A rich full self hosted all-objects system was not small. In these years, you could get a cool poster from Microsoft showing the class framework for MFC C++. It was like 300 classes. A full up VisualWorks or Smalltalk/X image might have 2,000. When I would do meta analysis on Smalltalk method ASTs, it was not uncommon to traverse 20,000 methods. Today, I don’t do Smalltalk, haven’t for nearly 10 years now. I still find programming with files very quaint. It’s like we’re stuck in a world where VHS beat Beta…