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 > >
