Understanding Object Systems

There are some regular discussions on programming that are quite boring, but from time to time you can find new thoughts lurking there. Using ideas from Theory of Constraints we can model conflicts in a way that the apparent dichotomy evaporates and a better way presents itself.

The particular dilemma I was looking at was the Smalltalk's image problem, actually not any of the problems described there but the usual spiel about how images are against the Unix way and such. The essence of the argument boils down to "I want to manipulate Smalltalk code as source files like everything is done in the Unix way" (many times people just talk about how Vim or Emacs is much better than the image, but the problem goes a little deeper than that) which is an enormous flag indicating that the person probably doesn't understand how Smalltalk works ("Source code in files? How quaint." -- Kent Beck). OTOH the Unix way is also a cornerstone of software engineering so this isn't a worse is better scenario but a true indicative that something very important is missing.

It occurred to me a way to solve this dilemma, just expose the image as a mount point (e.g. using FUSE), with methods as files inside classes (directories) with categories and protocols as directories with links to the methods/classes and special links like super also provided. As it happens with all good ideas there should be already something on the internet, so I used my google-fu and found exactly what I wanted on a FUSE based Smalltalk description (which unfortunately didn't lead me to actual software to play with). It even described the kind of integration with the live image I was thinking about (e.g. changing a method file and reflecting the change in the image) which is really cool. It's interesting to see this concept isn't used by all Smalltalkers around the globe to respond to these complaints so either is fundamentally flawed or there is something missing. Looking through the search results I also found many pointers to Smalltalk shells or shells in Smalltalk which are the same underlying idea presented in a different way (the Stash idea is also very close to this).

In Unix we have (or should have, Plan 9 got this right, but I digress) everything as a file, so we can see processes as files and such. In Smalltalk everything is an object so it should be just a matter of changing the UI to bridge the two concepts. Going further, having every object as an executable file and being able to send messages directly to it (e.g. #12ab76e9 at: 1 put: 'Hello World' would send the at:put: message to the object identified by the hash #12ab76e9. With a proper mount and some path extensions we could do almost everything in Unix, without having to reinvent the shell in Smalltalk.

This solves the source code in files problem, as you can mount your image and use VI, sed, git, etc., to manipulate the definitions. You can even manipulate the image from the shell, implementing a polymorphic mkdir that does the right thing when it's a class or a category. It looks like a wonderful idea, or isn't? Is it too good to be true?

In software I believe there are two problems that every idea should solve before becoming something useful:

1. Does it work in theory? You need to really think things through, many times there are theoretical barriers that make a nice idea fail badly in practice.
2. Is it feasible in practice? How much effort you need to make it work? Measure this in yaks.

It seems to be workable in theory so I fear it's unfeasible in practice, after all the Smalltalk images are built around the GUI, so it may require some serious yak shaving to untangle some bits (probably like all software projects it'll work almost right and then become almost impossible). But I think it's a worthwhile project and it would help greatly on explaining how object systems actually work.