Thank you! It bothers me slightly that we're actually having this discussion. Trying to divorce Smalltalk from the image loses a great deal of flexibility that we have all come to know and love. Divorcing Smalltalk from the image so we can use great tools might be a reasonable thing to do, but Git is not a great tool.
-Steven On 2011-04-20, at 11:15 AM, Dale Henrichs wrote: > Camillo, > > I understand that folks don't understand why Smalltalkers "don't just start > using files like everyone else". I have tried to explain ... it is not > arrogance nor ignorance. The image is the difference ... > > The image makes it possible for developers to debug and explore the "live > object model" in the image ... it is what makes me productive ... I don't > care about the syntax either... > > As a Smalltalker I need to _make changes to the source code in a live image_ > and when I make those changes I need to be able to manage the changes I make > in some sort of source code management system... that's why change sets were > invented and you can read the rest of the story below... > > Smalltalkers don't use the traditional tools, because the traditional tools > aren't designed to work with Smalltalk images ... it's not arrogance ... the > Smaltalk tools operate on the image not a set of files ... > > It's a different paradigm, so Smalltalkers aren't reinventing the wheel, they > are building a wheel that rolls in the image... > > Dale > > On Apr 20, 2011, at 9:51 AM, Camillo Bruni 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 ;). >> >> >> 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 >> >> >> > >
