[Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)
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
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@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
-- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
2011/4/20 Serge Stinckwich <serge.stinckwich@gmail.com>:
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
SmalltalkHub is Squeak, Pharo, GNU ST? It will be open source? There are several persistence options? Thanks.
Le mercredi 20 avril 2011 à 13:47 -0300, Germán Arduino a écrit :
2011/4/20 Serge Stinckwich <serge.stinckwich@gmail.com>:
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
SmalltalkHub is Squeak, Pharo, GNU ST? It hosts MC repositories & projects. So not GNU Smalltalk for now :)
It will be open source?
Sure, it will be released under MIT.
There are several persistence options?
Currently it uses Sandstone, so a it's file based serialization. The demo uses Sandstone + GOODS. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr
Thanks by the comments Nico. 2011/4/20 Nicolas Petton <petton.nicolas@gmail.com>:
Le mercredi 20 avril 2011 à 13:47 -0300, Germán Arduino a écrit :
2011/4/20 Serge Stinckwich <serge.stinckwich@gmail.com>:
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
SmalltalkHub is Squeak, Pharo, GNU ST? It hosts MC repositories & projects. So not GNU Smalltalk for now :)
It will be open source?
Sure, it will be released under MIT.
There are several persistence options?
Currently it uses Sandstone, so a it's file based serialization. The demo uses Sandstone + GOODS.
Cheers, Nico
-- Nicolas Petton http://www.nicolas-petton.fr
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 <dhenrich@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
El mié, 20-04-2011 a las 18:51 +0200, Camillo Bruni escribió:
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 ;).
+10
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@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
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
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 <dhenrich@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
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 <dhenrich@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
On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni <camillo.bruni@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@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
2011/4/20 Eliot Miranda <eliot.miranda@gmail.com>:
On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni <camillo.bruni@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.
I full agree, as like to say a well know Smalltalker here, Smalltalk is an objects environment who has a language (between other things).
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
Even if metacello solves a different problem than Monticello, metacelloBrowser should reach a stage where the ui is intuitive and cover the workflows that are commonly used. We are not there yet, but we are working on it. Alexandre
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 <dhenrich@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
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.
Agreed. Git can easily be used as a storage system for our tools.
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.
Monticello may have a poor UI, but Git has the worst possible UI, encourages awful practices, and just doesn't do the job well. Can we stop making this about Git, and actually make it about solving real problems? The real problems, as I see them, are: 1) We would like good UIs for interacting with our version control system, and 2) We would like an online tool for collaboration and sharing. Neither of these problems are solved by Git, so I would ask that people stop talking about Git as though it solves either one of them. GitHub solves the latter, an lots of the former, and perhaps that's where we should start looking.
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.
I disagree here; version control is an invaluable part of development, it should be part of the environment. How is using a system that is older than Git (Monticello) reinventing the wheel? -Steven
On 21 Apr 2011, at 04:47, Steven Baker wrote:
Monticello may have a poor UI, but Git has the worst possible UI, encourages awful practices, and just doesn't do the job well.
+10 Most people find git hard to use, indeed. Monticello is not harder to use, you just have to understand what it is (a distributed version control system). It has limitations like any other system.
2011/4/20 Dale Henrichs <dhenrich@vmware.com>:
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
Very very interesting summary Dale, Thanks by share. Indeed a lot of things to consider and think about. May be as a Smalltalker (and not using nor knowing Git) I assumed some wrong things. Germán.
I want to comment. As already Camillo said, git has nothing intrinsic with files. It only stores bytestrings and the commit id is the sha1 of that bytestring. When comparing a version with other it just compares the content of the object (bytestring). This is marvelous explained here with ruby and the unix command line: http://progit.org/book/ch9-2.html So the ideal would be that the SCM of Smalltalk it just used blobs to store method source code (because as beatiful that the image is all objects and turtles all the way down, at the end of the day when we program and write classes and methos we are writing text, just text, that the image behind the scene transform in live objects). In an example: I modify my package that is stored in git somehow. I modify 3 class and 15 methods from those three classes so my package is dirty. Now I want to commit my changes, so my hypothetical git-enabled-SCM visit each modified class and stores the string representation of each method (and class) modified (or just parses the changes file and convert each chunk in a blog) in a git blob. See, it just takes each source code string I entered into the image and convert it to blob. Then creates a tree git object grouping all those commits and finally creates a commit git object with the metadata and the pointer to the ancestry as required. All of this is stored locally in my local git repository. Finally a push will well, push, the changes to github for all to use. When I want to update my image with the new version of Seaside for example (that supposedly is already on github) I just pull the objects that aren't in my local repository and then merge them with my local changes if any. Then my git-enabled-SCM will just load the git objects (commit, tree and blob) in the image and on the fly extract the bytstring and applies the changes to the image (merging as needed so that the image is the live object representation of the git objects that we are loading). Of course the devil is in the details but I can't see the impossibility (other than the man-hours, time and money resources required) of using git (and something like github) for Pharo and Squeak. Cheers El mié, 20-04-2011 a las 09:01 -0700, Dale Henrichs escribió:
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
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
I think MC is working out really well for Squeak: development has been unstuck ever since we started using the workflow from Pharo;) I really enjoyed reading the historical info in your post. I hope it's okay to throw out a couple of counter arguments, just for fun. In particular, files don't work for us because: - the change sets are ugly and no one would want to work with them directly unless they had to. + solution: make the file out format human-friendly by getting the ordering, doits, and other metadata out to a metadata file. - the image has no way to detect that you've changed something in a file. + solution: make the image check timestamps, or implement a push of some sort that notifies the image that you've changed a method or class def. If the image isn't running, it can just pick up the all of the changes and use timestamps to suss out the ordering. Most (all?) SCM tools can *easily* be queried to see which files have changed since the last commit. Post commit hooks can integrate the changes into a running image. I agree that the problems with living in file-land won't go away by themselves. What I worry about, though, is that we're creating the "Smalltalk doesn't play well with others" myth, which keeps lots of perfectly interesting people away from our community, by refusing to use anything that isn't written in Smalltalk. One thing I've thought of trying is actually mapping each method and class def to a hierarchical file structure that mirrors the system organization. This way, the image can just dump the source of all changed methods and defs to the disk and check the result into the SCM. This has the advantage of "everything in its place" that we like so much about the way the system keeps it's code in a database. It isn't an RDBMS: it's tree shaped, not table shaped. The metaphor really isn't that different from an hierarchical file system, if you really think about it. The only thing I see missing is a file out format that takes this stuff into account, and a way to detect changes. It seems like both of these things, while non-trivial, are sort of almost-trivial:) The hard part would be rejiggering all of the tools (as usual,) I think. It seems like the problem here is really analogous to the discussions that have happened around namespaces. The actual problems are a) some people don't want namespaces, and b) we can argue for days about what color the bike shed should be without ever arriving upon a shed that you can keep a bike in. There are already implementations of this stuff... Both namespaces and Git integration. There's a Git-like system that stores Smalltalk objects in files. There's another that actually integrates with Git. To be clear, I want to repeat that I agree: this stuff won't integrate itself! And MC is working well enough for now (even though most people sort of hate it, or at least the vocal ones.) On Apr 20, 2011, at 9:01 AM, Dale Henrichs <dhenrich@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
Casey and Miguel, I agree that there are alternative approaches to SCMs that could give us Smaltalkers what we already have in Monticello .... with the added benefit that we could play nicely with the traditional tools, but keep in mind that we are making the problem harder for ourselves:) It's like the ORM problem in reverse ... it's just as hard to map the "object graph editor" paradiigm used by Smalltalk onto the traditional file-based systems as it is to map arbitrary object graphs into an RDB ... there is an impedance mismatch. It is the impedance mismatch that has kept Smalltalkers from expending the extra effort to make tools that play well in an image-based environment WHILE playing well in the file-based world. It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:) I think that this is a problem that does need to be solved (along with others:) so I'm not claiming that "all is lost, we'll never be file-based" I just think it is a tough problem that would have been solved by now, if it was easy:) Until then, long live SqueakSource3 and SmalltalkHub:) Dale On Apr 20, 2011, at 11:02 AM, Casey Ransberger wrote:
I think MC is working out really well for Squeak: development has been unstuck ever since we started using the workflow from Pharo;)
I really enjoyed reading the historical info in your post. I hope it's okay to throw out a couple of counter arguments, just for fun.
In particular, files don't work for us because:
- the change sets are ugly and no one would want to work with them directly unless they had to. + solution: make the file out format human-friendly by getting the ordering, doits, and other metadata out to a metadata file.
- the image has no way to detect that you've changed something in a file. + solution: make the image check timestamps, or implement a push of some sort that notifies the image that you've changed a method or class def. If the image isn't running, it can just pick up the all of the changes and use timestamps to suss out the ordering.
Most (all?) SCM tools can *easily* be queried to see which files have changed since the last commit. Post commit hooks can integrate the changes into a running image.
I agree that the problems with living in file-land won't go away by themselves. What I worry about, though, is that we're creating the "Smalltalk doesn't play well with others" myth, which keeps lots of perfectly interesting people away from our community, by refusing to use anything that isn't written in Smalltalk.
One thing I've thought of trying is actually mapping each method and class def to a hierarchical file structure that mirrors the system organization. This way, the image can just dump the source of all changed methods and defs to the disk and check the result into the SCM. This has the advantage of "everything in its place" that we like so much about the way the system keeps it's code in a database.
It isn't an RDBMS: it's tree shaped, not table shaped. The metaphor really isn't that different from an hierarchical file system, if you really think about it. The only thing I see missing is a file out format that takes this stuff into account, and a way to detect changes. It seems like both of these things, while non-trivial, are sort of almost-trivial:) The hard part would be rejiggering all of the tools (as usual,) I think.
It seems like the problem here is really analogous to the discussions that have happened around namespaces. The actual problems are a) some people don't want namespaces, and b) we can argue for days about what color the bike shed should be without ever arriving upon a shed that you can keep a bike in.
There are already implementations of this stuff... Both namespaces and Git integration. There's a Git-like system that stores Smalltalk objects in files. There's another that actually integrates with Git.
To be clear, I want to repeat that I agree: this stuff won't integrate itself! And MC is working well enough for now (even though most people sort of hate it, or at least the vocal ones.)
On Apr 20, 2011, at 9:01 AM, Dale Henrichs <dhenrich@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
2011/4/20 Dale Henrichs <dhenrich@vmware.com>:
It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:)
I think that this is a problem that does need to be solved (along with others:) so I'm not claiming that "all is lost, we'll never be file-based" I just think it is a tough problem that would have been solved by now, if it was easy:)
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)?
Until then, long live SqueakSource3 and SmalltalkHub:)
Sure! But, (I'm only asking) we couldn't using Git with objects? It's only curiosity, not that I would like Git, eheh, I knew Github only today! Germán.
Inline and abridged. On Apr 20, 2011, at 2:00 PM, Germán Arduino <garduino@gmail.com> wrote:
2011/4/20 Dale Henrichs <dhenrich@vmware.com>:
It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:)
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)? There are a number of reasons. One is better interop with existing tools: many professionals will be parted from their tools only in death, and this is a barrier to using Smalltalk at work outside of niches where it was adopted early on.
I would like a job with my Smalltalk, please and thank you:)
Sure! But, (I'm only asking) we couldn't using Git with objects? It's only curiosity, not that I would like Git, eheh, I knew Github only today! Well, we could do that. Git can version blobs. It just can't diff or merge them. And if you would also (as many professionals do) like to keep using your preferred text editor, you're out of luck.
The Git (read: Linux kernel) model depends on merging code from the wild successively up through more and more trusted repositories until it makes it to Linus and the kernel. You can't do that unless you can merge changes from downstream seamlessly. So ultimately we would need a textual representation for code that plays better with the merge logic in popular SCM tools (e.g. the ordering in changesets is semantic, which doesn't work well when you merge, so load order and doits would have to be captured as metadata or specified explicitly in a manifest.) Does this help to describe the landscape a bit?
Germán.
On Apr 20, 2011, at 2:00 PM, Germán Arduino wrote:
2011/4/20 Dale Henrichs <dhenrich@vmware.com>:
It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:)
I think that this is a problem that does need to be solved (along with others:) so I'm not claiming that "all is lost, we'll never be file-based" I just think it is a tough problem that would have been solved by now, if it was easy:)
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)?
The folks that would like to see Smalltalk be more file-based have very good points ... Smalltalk would be more accessible to other developers, it would be easier for folks to learn Smalltalk if they didn't have to learn new tools along with a new language, etc.... So it would be really nice if we could keep our object orientation while providing a development environment that was familiar to developers from other languages .... we'd have our cake and eat it too:)
Until then, long live SqueakSource3 and SmalltalkHub:)
Sure! But, (I'm only asking) we couldn't using Git with objects? It's only curiosity, not that I would like Git, eheh, I knew Github only today!
At the moment I don't think that a transition to to Git would be transparent ... If it were that easy, I would think that it would be done by now:). I'd love to be wrong:) Dale
On 20. 04. 2011 23:26, Dale Henrichs wrote:
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)?
The folks that would like to see Smalltalk be more file-based have very good points ... Smalltalk would be more accessible to other developers, it would be easier for folks to learn Smalltalk if they didn't have to learn new tools along with a new language, etc....
So it would be really nice if we could keep our object orientation while providing a development environment that was familiar to developers from other languages ....
Here is the point - familiarity! And we don't need to adopt GitHub completely for that, just visual familiarity of SmalltalkHub will help us to come closer to GitHub communities, that's I'm pretty sure. So, let we stop thinking about "file-based" integration with GitHub, let we talk about social aspects (as familiarity also is) and as Sebastian is trying to tell us. As you seen on SmalltalkHub, we will actually got quite some "social" infrastructure now, which is very similar to GitHub. Nico as GNU Smalltalker is namely a daily user of GitHub (where Iliad and Jtalk resides), so he has quite some experience of social aspects there. Next thing, let we rather start integrating different Smalltalk code on all our dialects first and using SmalltalkHub for socializing in Smalltalk community as a whole. First, and before socializing with others! Here SmalltalkHub again promise a lot and we can actually achieve a goal of *one*, only one entry point to *all* Smalltalk code, in *all* dialects! Best regards Janko -- Janko Mivšek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si
On 21 Apr 2011, at 00:09, Janko Mivšek wrote:
Here is the point - familiarity! And we don't need to adopt GitHub completely for that, just visual familiarity of SmalltalkHub will help us to come closer to GitHub communities, that's I'm pretty sure.
So, let we stop thinking about "file-based" integration with GitHub, let we talk about social aspects (as familiarity also is) and as Sebastian is trying to tell us. As you seen on SmalltalkHub, we will actually got quite some "social" infrastructure now, which is very similar to GitHub. Nico as GNU Smalltalker is namely a daily user of GitHub (where Iliad and Jtalk resides), so he has quite some experience of social aspects there.
Next thing, let we rather start integrating different Smalltalk code on all our dialects first and using SmalltalkHub for socializing in Smalltalk community as a whole. First, and before socializing with others! Here SmalltalkHub again promise a lot and we can actually achieve a goal of *one*, only one entry point to *all* Smalltalk code, in *all* dialects!
+1
2011/4/20 Janko Mivšek <janko.mivsek@eranova.si>:
Next thing, let we rather start integrating different Smalltalk code on all our dialects first and using SmalltalkHub for socializing in Smalltalk community as a whole. First, and before socializing with others! Here SmalltalkHub again promise a lot and we can actually achieve a goal of *one*, only one entry point to *all* Smalltalk code, in *all* dialects!
This is an interesting point also. Would be nice to have some sort of common things between all the smalltalks.
I have been using a DVCS since at least 2005 and live by it for Perl (as well as other things) development. It is frustrating for me to use anything else. Because I have to jump between tasks, and because I am so scatter brained, I need it in order to simply keep track of all my projects and the changes that I have made. A DVCS fits to my workflow no matter how I need to do my work. However, though I am very new to Smalltalk and while I am used to the tools that I have been using for years I still do not feel compelled to use a DVCS that I am so used to. Monticello could use some improvements perhaps, but I currently do not see a compelling reason to change it for something else. I appreciate what an object system has to offer instead of just flat files. Things are radically different for me now. Instead of dealing with a combination of a RDBMS, Perl applications, and shell scripts I have a complete system with more than just a language (thanks Eliot for the clarity). All the time I am used to using UNIX commands, SQL commands, editor features just to do my work. With Smalltalk I have all of that with a consistent language that reduces all of the ways I need to consider to slice and dice the things I am looking to accomplish. And all of this in just an image file! I do still struggle hard with Smalltalk (it is so new and so radically different for me - yet the code is so much cleaner and easier when done right) but I still do not see a compelling reason to use Git for my development. I know this discussion tends to come up ever so often. What am I missing? Is it perhaps because I am coming from the outside in? If you use Git what benefit would you have by using binary files? Or if you were to use some sort of text file, what benefit would you have by removing them from the system in which they exist? Thanks! Scott Gibson On Apr 20, 2011, at 5:26 PM, Dale Henrichs wrote:
On Apr 20, 2011, at 2:00 PM, Germán Arduino wrote:
2011/4/20 Dale Henrichs <dhenrich@vmware.com>:
It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:)
I think that this is a problem that does need to be solved (along with others:) so I'm not claiming that "all is lost, we'll never be file-based" I just think it is a tough problem that would have been solved by now, if it was easy:)
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)?
The folks that would like to see Smalltalk be more file-based have very good points ... Smalltalk would be more accessible to other developers, it would be easier for folks to learn Smalltalk if they didn't have to learn new tools along with a new language, etc....
So it would be really nice if we could keep our object orientation while providing a development environment that was familiar to developers from other languages ....
we'd have our cake and eat it too:)
Until then, long live SqueakSource3 and SmalltalkHub:)
Sure! But, (I'm only asking) we couldn't using Git with objects? It's only curiosity, not that I would like Git, eheh, I knew Github only today!
At the moment I don't think that a transition to to Git would be transparent ... If it were that easy, I would think that it would be done by now:).
I'd love to be wrong:)
Dale
-- Scott Gibson wsgibson@windstream.net
El mié, 20-04-2011 a las 18:17 -0400, Scott Gibson escribió:
I have been using a DVCS since at least 2005 and live by it for Perl (as well as other things) development. It is frustrating for me to use anything else. Because I have to jump between tasks, and because I am so scatter brained, I need it in order to simply keep track of all my projects and the changes that I have made. A DVCS fits to my workflow no matter how I need to do my work.
However, though I am very new to Smalltalk and while I am used to the tools that I have been using for years I still do not feel compelled to use a DVCS that I am so used to. Monticello could use some improvements perhaps, but I currently do not see a compelling reason to change it for something else. I appreciate what an object system has to offer instead of just flat files. Things are radically different for me now. Instead of dealing with a combination of a RDBMS, Perl applications, and shell scripts I have a complete system with more than just a language (thanks Eliot for the clarity). All the time I am used to using UNIX commands, SQL commands, editor features just to do my work. With Smalltalk I have all of that with a consistent language that reduces all of the ways I need to consider to slice and dice the things I am looking to accomplish. And all of this in just an image file!
I do still struggle hard with Smalltalk (it is so new and so radically different for me - yet the code is so much cleaner and easier when done right) but I still do not see a compelling reason to use Git for my development.
I know this discussion tends to come up ever so often. What am I missing? Is it perhaps because I am coming from the outside in? If you use Git what benefit would you have by using binary files? Or if you were to use some sort of text file, what benefit would you have by removing them from the system in which they exist?
A couple of things, - Squeak/Pharo already use files, that is a fact and is unavoidable (changes files, image files, sources files, etc) so the thing is not if using or not files. They are used and they have killed anyone by themselves. - The point is not use files to store the source code but integrate Squeak/Pharo with infrastructure that building on the capabilities given by git to the developers (mainly cheap and fast branching) added a social ingredient that is revolutioning the way that projects are being developed in the open source world. That is what github is doing. Has nothing to do with if git versioning files or blobs or objects. It is that enables people to show, publish, fork, contribute back and advertise its open source project in a way that is visible to a lot more people that ever before. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
I would had responded to Casey, Dale and more, but selected this mail to write my response! 2011/4/20 Scott Gibson <wsgibson@windstream.net>:
I have been using a DVCS since at least 2005 and live by it for Perl (as well as other things) development. Â It is frustrating for me to use anything else. Â Because I have to jump between tasks, and because I am so scatter brained, I need it in order to simply keep track of all my projects and the changes that I have made. Â A DVCS fits to my workflow no matter how I need to do my work.
However, though I am very new to Smalltalk and while I am used to the tools that I have been using for years I still do not feel compelled to use a DVCS that I am so used to. Â Monticello could use some improvements perhaps, but I currently do not see a compelling reason to change it for something else. Â I appreciate what an object system has to offer instead of just flat files. Â Things are radically different for me now. Â Instead of dealing with a combination of a RDBMS, Perl applications, and shell scripts I have a complete system with more than just a language (thanks Eliot for the clarity). Â All the time I am used to using UNIX commands, SQL commands, editor features just to do my work. Â With Smalltalk I have all of that with a consistent language that reduces all of the ways I need to consider to slice and dice the things I am looking to accomplish. Â And all of this in just an image file!
A big big big agreement with you. And is of a great value that a new smalltalker (as you are telling about yourself) put the finger on this topic: the image! The image is the environment (the ecosystem as one of my teachers says) were the objects live. To me, a Smalltalk without image is not a Smalltalk and really never will like a no-image Smalltalk because is not Smalltalk, may be is other thing, but not Smalltalk. Then I'm totally against the flat-files if their use means loss the image. Smalltalk is about objects, and objects live in the image as the fishes live in the tank. No tank, no water, then only dead fishes, not alive fishes. To not mention the other relationships in a live ecosystem. Germán.
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)?
The folks that would like to see Smalltalk be more file-based have very good points ... Smalltalk would be more accessible to other developers, it would be easier for folks to learn Smalltalk if they didn't have to learn new tools along with a new language, etc....
They already have GNU Smalltalk. GNU Smalltalk is a nice in-between for this. I find I lose a lot, though.
So it would be really nice if we could keep our object orientation while providing a development environment that was familiar to developers from other languages ....
we'd have our cake and eat it too:)
Until then, long live SqueakSource3 and SmalltalkHub:)
Sure! But, (I'm only asking) we couldn't using Git with objects? It's only curiosity, not that I would like Git, eheh, I knew Github only today!
At the moment I don't think that a transition to to Git would be transparent ... If it were that easy, I would think that it would be done by now:).
Not only that, but by storing Smalltalk code in Git, we'd lose most of the features that you want from version control anyways, since Git tools only work with text files. -Steven
I don't think that the issue is the file-ness of the subject, but the easiness that other opensource projects enjoy in part because of their tool, even if they aren't as pure in their object-ness as the ones Smalltalk have. As someone said, the UI of Monticello is very, umm, unintiuitive, has bad support for branching, avoiding some effect that the git users (and in particular github has contributed to popularize) that nobody has to ask for permission for modifying some project and then contributing back the changes to the main project. This is notorious difficult with MC/Squeaksource combo when the repo is only read, when the maintainer has to do a not minor effort to track contributions and integrating them back. And of course, the visibility that those tools have is no even in the reach of squeaksource (with those ugly urls that include session data that from time to time appears in mails refering to projects in squeaksource). In that respect git/github no matter if file-based or not are the clear example to emule and even to use for smalltalk open source projects. Cheers El mié, 20-04-2011 a las 18:00 -0300, Germán Arduino escribió:
2011/4/20 Dale Henrichs <dhenrich@vmware.com>:
It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:)
I think that this is a problem that does need to be solved (along with others:) so I'm not claiming that "all is lost, we'll never be file-based" I just think it is a tough problem that would have been solved by now, if it was easy:)
A thing I not understand is why we need to go "file-based" if we are already object based (several steps ahead)?
Until then, long live SqueakSource3 and SmalltalkHub:)
Sure! But, (I'm only asking) we couldn't using Git with objects? It's only curiosity, not that I would like Git, eheh, I knew Github only today!
Germán.
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
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
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
More recently, he said "Smalltalk: Welcome to the Balkans." On Apr 20, 2011, at 7:01 PM, Reg Krock <rkrock3@yahoo.ca> 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
Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today.
First: anyone complaining that we can't use git, hasn't used great version control tools. I think what people want is GitHub, which is great. We can have GitHub and base it on Monticello. And I'm happy to work on this. But not alone. -Steven
Just a meta question that each of us can try to answer when looking at himself in the mirror. What do we do to get a better system? If everybody would do something simple everyday we would be more than busy. So yes MC UI is funky, now who tried to develop a new widget? Don't tell me that morphic is bad, it is not that bad so you can take UITheme examples and get started and do something. Everyday I like to see the updates working and this is a good feeling for me. Stef
Hi Dale and everyone-- I think traditional Smalltalk is just file-based enough to cause major annoyance for everyone. :) This seems like yet another good moment to read Ingalls' "Design Principles Behind Smalltalk"[1]. What resonates most for me are the "messages" and "uniformity" principles. In Smalltalk's first several development cycles in the 1970s, key technologies which could enable the realization of those principles (and which have since become commonplace) were still nascent. Specifically, establishing network connections between arbitrary computers was relatively difficult, and the connections themselves were relatively slow and expensive. In that situation, it seems more attractive to use files to communicate changes, rather than using remote messaging, even though that's a retreat from uniform application of the communicating-objects idea. Perhaps remote messaging wasn't even considered then (hm, if only there were people from that time who could tell us... :). Anyway, once you've decided to use files to communicate changes, you establish several conventions which are hard to drop. These include: - It's normal to express an application as a set of differences from some known object memory state, or one that is "close enough"... except when it isn't. - It's normal to express those differences as source code, to be compiled by an object memory which is again "close enough". - Conveying changes from one Smalltalk system to another is not an interactive process. If the changes in a file are wrong, you need to fiddle with the file yourself, or change the system that made the file and recreate it. The dependency relationship between multiple files of changes is even more problematic. Change sets and fileouts are a result of these unfortunate conventions, but they need not be integral to Smalltalk. However, this is all independent of the external interfaces we can provide to an object memory. Another thing we can do with today's easy/fast/cheap network connections, and the web services that have grown around them, is provide WebDAV access to object memories. A Smalltalk WebDAV server could provide a virtual filesystem, suitable for use with anyone's Favorite Text Editor. It could present whatever file content and file/directory structure it likes (e.g., a mapping to classes and methods in some useful way, like Casey mentioned), and perform whatever side effects it likes when those virtual files are changed by the Favorite Text Editors. People would be free to copy those virtual files and put them into whatever other system they like (e.g. git), but the interesting stuff happens when the files make their way back into the virtual filesystem, through those WebDAV server side effects. I suspect one could integrate writes to the virtual filesystem with commits to another system. (Despite that, I agree with Steven that it's the "social coding" affordances of git that are really interesting, not git's mechanisms per se.) -C [1] http://tinyurl.com/3wyxavt (archive.org) -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547
participants (17)
-
Alexandre Bergel -
Camillo Bruni -
Casey Ransberger -
Craig Latta -
Dale Henrichs -
Eliot Miranda -
Germán Arduino -
Janko Mivšek -
Miguel Cobá -
Nicolas Petton -
Norbert Hartl -
Reg Krock -
Scott Gibson -
Serge Stinckwich -
Steven Baker -
Stéphane Ducasse -
Sven Van Caekenberghe