More recently, he said "Smalltalk: Welcome to the Balkans." On Apr 20, 2011, at 7:01 PM, Reg Krock <[email protected]> wrote:
> I think it was Kent Beck who ended his email with: "Source code in files? How > 1970ish" > > Reg > > On 2011-04-20, at 4:17 PM, Norbert Hartl wrote: > >> Amen! >> >> Norbert >> >> Am 20.04.2011 um 18:01 schrieb Dale Henrichs: >> >>> 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 >> >> > >
