[Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

Craig Latta craig at netjam.org
Fri Apr 22 22:55:29 CEST 2011


Hi Dale and everyone--

     I think traditional Smalltalk is just file-based enough to cause
major annoyance for everyone. :)

     This seems like yet another good moment to read Ingalls' "Design
Principles Behind Smalltalk"[1]. What resonates most for me are the
"messages" and "uniformity" principles. In Smalltalk's first several
development cycles in the 1970s, key technologies which could enable the
realization of those principles (and which have since become
commonplace) were still nascent.

     Specifically, establishing network connections between arbitrary
computers was relatively difficult, and the connections themselves were
relatively slow and expensive. In that situation, it seems more
attractive to use files to communicate changes, rather than using remote
messaging, even though that's a retreat from uniform application of the
communicating-objects idea. Perhaps remote messaging wasn't even
considered then (hm, if only there were people from that time who could
tell us... :).

     Anyway, once you've decided to use files to communicate changes,
you establish several conventions which are hard to drop. These include:

-    It's normal to express an application as a set of differences from
some known object memory state, or one that is "close enough"... except
when it isn't.

-    It's normal to express those differences as source code, to be
compiled by an object memory which is again "close enough".

-    Conveying changes from one Smalltalk system to another is not an
interactive process. If the changes in a file are wrong, you need to
fiddle with the file yourself, or change the system that made the file
and recreate it. The dependency relationship between multiple files of
changes is even more problematic.

     Change sets and fileouts are a result of these unfortunate
conventions, but they need not be integral to Smalltalk. However, this
is all independent of the external interfaces we can provide to an
object memory.

     Another thing we can do with today's easy/fast/cheap network
connections, and the web services that have grown around them, is
provide WebDAV access to object memories. A Smalltalk WebDAV server
could provide a virtual filesystem, suitable for use with anyone's
Favorite Text Editor. It could present whatever file content and
file/directory structure it likes (e.g., a mapping to classes and
methods in some useful way, like Casey mentioned), and perform whatever
side effects it likes when those virtual files are changed by the
Favorite Text Editors.

     People would be free to copy those virtual files and put them into
whatever other system they like (e.g. git), but the interesting stuff
happens when the files make their way back into the virtual filesystem,
through those WebDAV server side effects. I suspect one could integrate
writes to the virtual filesystem with commits to another system.

     (Despite that, I agree with Steven that it's the "social coding"
affordances of git that are really interesting, not git's mechanisms per
se.)


-C

[1] http://tinyurl.com/3wyxavt (archive.org)

--
Craig Latta
www.netjam.org/resume
+31  06 2757 7177
+ 1 415  287 3547






More information about the Pharo-project mailing list