[Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

Eliot Miranda eliot.miranda at gmail.com
Wed Apr 20 20:21:25 CEST 2011


On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni <camillo.bruni at inria.fr>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 <dhenrich at vmware.com>
> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110420/312f5297/attachment.htm>


More information about the Pharo-project mailing list