2011/4/20 Dale Henrichs <[email protected]>:
> Smalltalk is not file-based. For better or for worse.
>
> The fundamental problem with Smalltalk is that it is image-based.
>
> Removing a method from a file is not sufficient to remove the method from the 
> image.
>
> Change sets were invented to provide a file-based solution to the "how do I 
> remove a method from the image" problem.
>
> A filein (the one used to initialize your image) plus a series of change sets 
> applied in the right order is the file-based methodology for managing an 
> image.
>
> Change sets are integral to Smalltalk.
>
> Name another language that uses change sets ...
>
> I cannot distribute a fresh set of source files to _upgrade_ an already 
> installed application. I have to supply change sets and those change sets 
> have to specific to the version that is installed in the image ...
>
> Remember the problem is "how do I remove a method from the image".
>
> The image is a data base, not an executable program, when you load code you 
> also migrate/modify the objects in your "data base".
>
> Name another language that does this....
>
> Monticello was invented along the way ... I cannot speak to the original 
> motivation, but I can say that with Monticello I _can_ distribute a fresh set 
> of source files to _upgrade_ an already installed application.
>
> Monticello does this by having a meta model that describes the complete 
> application. The meta model is not a "source file" it is a serialized object 
> graph.
>
> Monticello dynamically creates a change set by comparing the meta model of 
> the loaded application with the meta model of the incoming "source code".
>
> Name another language that does this....
>
> So the meat and potatoes of a Monticello mcz file is a binary chunk of 
> data....
>
> What does git do with binary data? What do humans do with binary data?
>
> You need a tool that takes the binary data and makes it readable for the poor 
> developers who cannot unzip and deserialize a binary stream of bits on sight.
>
> Enter SqueakSource and SmalltalkHub....
>
> This is where we are today.
>
> Can Smalltalk development be based on files....certainly everyone was doing 
> file-based development in 1985, but the Smalltalk environments of the day 
> migrated away from files ...
>
> In 1985 I was writing tools to store files and change sets in RCS ... the 
> original ChangeSorter was based on my work back then...
>
> In 1993 I was working on tools that stored Smalltalk source meta data using 
> PKZIP ...
>
> ENVY stores source meta data into a custom data base....
>
> Store stores source meta data in an RDB...
>
> In 2011 I am working on tools that store Smalltalk source meta data using zip 
> ...
>
> Smalltalk is image-base and the "standard" development tools just don't fit 
> ... for better or for worse ...
>
> Sooooo, we can complain that we are not using git, but there are very good 
> reasons for not using git ... today.
>
> Just because 20 years of evolution has moved Smalltalk away from using files 
> in the traditional manner, doesn't mean that it won't evolve back to using 
> files, but until the evolution happens, we need tools like SqueakSource3 and 
> SmalltalkHub to support the _current_ model.
>
> Dale
>

Very very interesting summary Dale, Thanks by share.

Indeed a lot of things to consider and think about. May be as a
Smalltalker (and not using nor knowing Git) I assumed some wrong
things.

Germán.

Reply via email to