On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni <[email protected]>wrote:
> Objection! ;) > > Using git has nothing to do with a file based system. The approach would be > to use git as a storage backend for monticello. Git just stores 3 types of > objects: commit, tree, blob. > There are no files involved!! So this would be perfectly compatible with > and image based system such as smalltalk. > > see: http://book.git-scm.com/1_the_git_object_model.html > > > personal rant from here on >>> > > However I see that smalltalkers tend to ignore the fact that there are > other tools not written in smalltalk which are widely used and they actually > work! For instance monticello. Although the model works perfectly fine, the > UI is just plain crap, it does not provide a nice workflow nor is it > readable... Git on the other hand might be too complex, but it lets do more > stuff on the command line, in an easier fashion than the mc tool. > > Smalltalkers tend to reinvent the wheel, which is sometimes nice, if its > well designed and actually works, but many times its rather a waste of time, > than just relying on existing working infrastructure that people outside > smalltalk build. > > What I see in Pharo is a good move towards making these tools work again, > most of them are just old and ignore common UI principles. > > > And Smalltalk is not the holy grail, its just yet another programming > language, which has nice syntax ;). > You're joking right? Smalltalk is not a programming language, it is an object system, including a programming language, a library, tools etc. Please, let's not completely misunderstand what Smalltalk is in this community. > > > On 2011-04-20, at 18:10, Serge Stinckwich wrote: > > Even if SmalltalkHub looks like GitHub, its still based on Monticello. > > Another aspect also important in github and similar tools is social > coding. > > This is very easy to follow your favorite developpers and to > > participate by cloning his/her repository. > > > > Regards > > > > On Wed, Apr 20, 2011 at 11:01 PM, Dale Henrichs <[email protected]> > wrote: > >> 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 > > > >
