On 12/06/2011, at 1:00 PM, BGB wrote: > image-based systems have their own sets of drawbacks though... > > dynamic reload could be a "good enough" compromise IMO, if done well...
I don't follow this train of thought. Everything runs in "an image". That's to say, the source code directly relates to some piece of running code in the system at some point. Smalltalk, Self and the like simply let you interact with the running code in the same place as the artefacts that create the running code. It's akin to programming in a debugger that saves the contents of memory constantly as "the source". As it's 2011, surely we can come to a point where we can synthesise these two "apparently" orthogonal concerns? I think the main issue with smalltalk-like "image" systems is that the system doesn't as easily let you "start from blank" like text-file source-code style coding does... thats to say, yes, it's possible to start new worlds, but it's not very easy to reference "bits" of your worlds from each other... and essentially, that's what text-file coding (ie editing "offline" code) does for us... because things are in files, it's easy to "include" a file as one packaged unit, or a group of file, or a "package"... and then that "package" can be referred to... separately, and even maintained by someone else, and it's not a COPY of the package, it's a reference to it... you know? This is incredibly powerful. The equivalent in a smalltalk system would need to be some kind of amazing version control system that can version worlds at certain points, and package code in a recursive encapsulation process. Having a "global namespace" is kind of retarded... because context is everything... ... that's to say, when and as context yields meaning (as I believe it does from my fairly deep ponderings), no "token" that yields meaning in a given context holds its meaning when decontextualised in the same way, therefore names (as these "tokens") are deeply important IN CONTEXT. What kind of relevance, therefore, has a global namespace got? Julian. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
