environments vs. files

Daniel Vainsencher daniel.vainsencher at gmail.com
Wed Aug 17 19:49:31 UTC 2005


 >The file meme is certainly more entrenched, but I
 > don't think that makes it better.
The point of thinking of ideas as memes is the evolutionary point of 
view. So "better" in this case means likelier to reproduce. Files are 
likelier to reproduce at the moment because they are more adapted to the 
current environment, which happens to be receptive to files.

I am not saying that code files are intrinsically better than remote 
messaging *for us*, just that they are better adapted to current 
environment.

Craig Latta wrote:
>  > But of course... the solution is not to work like everyone else. I'm
>  > just saying that it is important to take practical sharing into
>  > account in shaping the way we work, and images are not the solution to
>  > that.
>     How are images impractical? It almost sounds like you're saying that 
> because they aren't already popular, we shouldn't advocate them.
Gods no. Everyone *should* have an image because of the single user 
benefits. And because it is great to be able to give someone an image as 
a way of passing lots of complicated state.

I'm saying everyone should have other solutions for sharing code, 
because images stink at *that*. We have other solutions for sharing code 
(change sets, MC), and we should make sure that we explain this to new 
comers, and we should improve them, a lot.

>  > If you're claiming objects talking to one another live can be more
>  > practical for sharing than files...
>     Yes. :)
>  > ...I'm saying that that has yet to be shown. I've seen compelling
>  > demos on occasion, but it hasn't become a permanent situation yet.
>     And if people just work on incremental improvements to file-based 
> concepts instead, that doesn't seem likely to change. :)
Well, I disagree. MC mostly improves the model of code, and the tools on 
top of that model. The fact that the models are stored in files is 
incidental. We could have instances of Squeak using remote messaging to 
negotiate what MC version models (or parts of the models) they should 
pass one another.

>  > I think the most immediately promising directions for sharing Squeak
>  > code at the moment are things that could be build on top of
>  > Monticello...
>     Fair enough, I'm just putting in a word for an approach which I 
> think is more worthwhile, despite taking longer to realize (because the 
> work is less incremental).
Less incremental is a pain in the rear.

What makes it less incremental? why couldn't/shouldn't it be done as 
incrementally as what I mentioned above (an alternative substrate for MC 
versioning)?

>     I must say, though, I'm continually surprised how the "everything 
> happens by sending messages" idea goes out the window at physical 
> machine boundaries. It's just weird. 
Well, a lot of nice assumptions go out the window at physical machine 
boundaries. I won't be surprised if when we all have multicore machines, 
we'll see objects constantly get flattened to move inside a machine, too.

> Pervasive remote messaging seems to 
> me like something that should have been done along with the rest of 
> Smalltalk-80; it was only as impractical as having a megapixel display 
> on your desk. :)  
:-)

Daniel



More information about the Squeak-dev mailing list