Team programming with Smalltalk
There's a debate at Hacker News about how Smalltalk is used collaboratively in team programming: https://news.ycombinator.com/item?id=13642947 <https://news.ycombinator.com/item?id=13642947> 'theamk' says: Sorry, I am at work right now and don't have time to watch videos. Can you tell me more about "Smalltalk's own tooling for collaboration and version control"? Are you referring to Monticello? I am not insisting on git, but Monticello seems pretty limited in term of collaboration. I see commit, diff, checkout, and remote pull/push. Specifically, let's imagine this scenario: we have team of tens of programmers working on a project. A new team member joins and accidentally breaks the code in non-obvious way. He pushes the code to main repository. Next time, everyone else checks out the latest version of the code and starts having weird problems. If you had 20 people on team, and they each wasted 2 hours because the code was broken, well, you just wasted a week of programmer time. How do you prevent it? In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this. ----- How would you respond? I know Smalltalk can be used in large team programming, but since I personally have no experience with this, I cannot respond intelligently. Thanks. -- View this message in context: http://forum.world.st/Team-programming-with-Smalltalk-tp4934508.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Pharo in particular, I cannot speak about other Smalltalks I have not used, when it comes to VCS its very similar to git actually. It uses source code files, it distributes them via zip files, it works locally instead of centralised , it support merges etc. Pharo works well also with usual VCS because it can export code into source code files. The image plays no role in VCS whatsoever because VCS is about code not data and image is mostly about live data and lesser about live code . So any tool will and does work with pharo outside the image. Problem arises with a majority of people that unlike me prefer to stay in the image in that case you gain more control because you have more pharo code to play with but you lose a lot of power because we are a small community not able to compete with behemorth projects like git. Another interesting thing which Pharo does emphasize is remote debugging , though not a Pharo monopoly by a long shot we do have several libraries that can achieve this and because the image format retains live state and live code execution its easy to resolve issues. Besides the image format , the fuel format has the advantage of storing only fraction of the image. You can email this or share it via git or dropbox . Like an image a fuel file is a binary file and like the image it can store live state and live code execution. This way you can isolate live bugs and share them with your team , each one in its own fuel file . Ston is also another alternative format which feels familiar for those that have worked with JSON. In the end there is nothing really special about Smalltalk , you can emulate these features in other programming language especially dynamic pure object orientated ones like Pharo . The difference is that with Pharo you avoid the custom setup, the extra download of tools and libraries and the extra glue code required. Of course the fact that those tool have been around for decades make them more polished and reliable , contrary to modern that promise the sky and the moon and deilvery very little. So overall I will say because of live coding features Pharo is ideal for teams that love to experiment and try ideas on the spot. Especially for bugs that are hard to catch because they appear in random having the ability to debug the live code and live state on the spot can really boost the performance on the team and at the same time utilize all the tool that coders in other languages can use too. On Thu, Feb 16, 2017 at 12:48 AM horrido <horrido.hobbies@gmail.com> wrote:
There's a debate at Hacker News about how Smalltalk is used collaboratively in team programming: https://news.ycombinator.com/item?id=13642947 <https://news.ycombinator.com/item?id=13642947>
'theamk' says:
Sorry, I am at work right now and don't have time to watch videos. Can you tell me more about "Smalltalk's own tooling for collaboration and version control"? Are you referring to Monticello? I am not insisting on git, but Monticello seems pretty limited in term of collaboration. I see commit, diff, checkout, and remote pull/push.
Specifically, let's imagine this scenario: we have team of tens of programmers working on a project. A new team member joins and accidentally breaks the code in non-obvious way. He pushes the code to main repository. Next time, everyone else checks out the latest version of the code and starts having weird problems. If you had 20 people on team, and they each wasted 2 hours because the code was broken, well, you just wasted a week of programmer time. How do you prevent it?
In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
-----
How would you respond? I know Smalltalk can be used in large team programming, but since I personally have no experience with this, I cannot respond intelligently.
Thanks.
-- View this message in context: http://forum.world.st/Team-programming-with-Smalltalk-tp4934508.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I have worked with VASmalltalk for 20 years and this included projects utilizing 10-15 developers. VASmalltalk uses Envy Manager as its VCS. Envy, in my opinion, is far superior to anything on the market today where it concerns code management. It has open editions, scratch editions, versions, application packages, sub-application packages, merges, and doffs. However, it was built to be used in an internal organization. It is not usable for open source Smalltalk VCS projects such as Git. I believe that Visualworks uses a RDBMS product called Store that is similar to Envy. Both of these are commercial Smalltalks, however. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Team-programming-with-Smalltalk-tp4934508p4934514.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I've used ENVY for a couple of years, and marginally used Store. Store is nothing compared with ENVY, ENVY is far superior. Store is like Monticello, but as such it lacks the "Configuration Map" part of it, that is offered by Metacello in Pharo/Squeak/GemStone. However I find ENVY to be too cumbersome for an agile way of working. I found Dolphin Smalltalk X6/7 using PAX source format which is file based VCS friendly working with Git to be a very good fit, and we used it in a team of up to 10 commiters to the same repository. Monticello together with Metacello offers a very good balance, with integrated tools that enables you to merge and understand the changes. I haven't used Iceberg yet. Esteban A. Maringolo 2017-02-15 20:53 GMT-03:00 Brad Selfridge <bsselfridge@gmail.com>:
I have worked with VASmalltalk for 20 years and this included projects utilizing 10-15 developers. VASmalltalk uses Envy Manager as its VCS. Envy, in my opinion, is far superior to anything on the market today where it concerns code management. It has open editions, scratch editions, versions, application packages, sub-application packages, merges, and doffs. However, it was built to be used in an internal organization. It is not usable for open source Smalltalk VCS projects such as Git. I believe that Visualworks uses a RDBMS product called Store that is similar to Envy. Both of these are commercial Smalltalks, however.
----- Brad Selfridge -- View this message in context: http://forum.world.st/Team-programming-with-Smalltalk-tp4934508p4934514.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Am 17.02.2017 um 18:51 schrieb Esteban A. Maringolo:
I've used ENVY for a couple of years, and marginally used Store. Store is nothing compared with ENVY, ENVY is far superior. Store is like Monticello, but as such it lacks the "Configuration Map" part of it, that is offered by Metacello in Pharo/Squeak/GemStone.
However I find ENVY to be too cumbersome for an agile way of working.
And another point is, that the way of ENVYs thinking is also available in the tools they offer for the developer (let it be VW 2.5.2 or VASmalltalk). Same tools on all platforms. This way of thinking is also introduced in the kind of browsers you have - which offers different ways of views on your projects. For me the most and strongest point in the ENVY-Browsers area is the ApplicationBrowser. Its shows you only the part of the image of a specific application (package) , which are new classes introduced by you in this application (package) - but also all the extension methods you added in this application (package) to classes. That means - programmers can stay for the whole life of a project - in only this kind of browsers. A wonderful way of viewing the image. Sadly this is gone or simply only badly implemented. E.g. in Pharo you can select a package - fine, but to know, what has been extended in this package ?. The name of the method categories also define in which package this method is located in. Make a type error and the method goes into a different package and you will not recognize it. Solutions born by the idea: how can we make it simple to have a solution this evening - and these solutions survive over the years. ENVY for the first time used ? Well I remember, that I was crazy about this tool - all this versioning, prerequisites etc ... but now after 20 years ? I'm used to the tools available on the Smalltalk market - but really nice versioning (with several platforms): ENVY is the way to go. And the original version had several user interactions implemented - which have been defined by VASmalltalk (e.g. change the developer role and make this or that in one click). ENVY is also the tool, where I have so much confidence with, because over the last 20 years I've never seen crashes and data losses. A strong point for a closed-source software repository. Marten -- Marten Feldtmann
You see. Pharo is free. Give me money and you will get something much better. For me closed and proprietary tools do not exist anymore. You see I'm moving from Keynote for my lecture slides because they decided that they do not want to load my old lectures :). Tx apple. I worked with Envy. Now Envy is not good to work in the train and deconnected. I run a local envy base on my machine but it was a bit heavy. Pharo is moving to git and this is really cool because we do not just save files in git but will offer a process and tools around. Then we will get the associate exposure :) Stef
For the record I never lost code with MC. We are managing Pharo since 2008 with MC and it works. Now I cannot open my old code stored in Envy on my current mac. While I can dezip MC files. So you see the devil is in the details.
2017-02-18 8:53 GMT+01:00 itlists@schrievkrom.de <itlists@schrievkrom.de>:
Sadly this is gone or simply only badly implemented. E.g. in Pharo you can select a package - fine, but to know, what has been extended in this package ?. The name of the method categories also define in which package this method is located in. Make a type error and the method goes into a different package and you will not recognize it. Solutions born by the idea: how can we make it simple to have a solution this evening - and these solutions survive over the years.
It will be changed in Pharo 7 with Calypso. It already shows packages instead of categories with start convension.
On 02/20/2017 03:58 AM, Denis Kudriashov wrote:
2017-02-18 8:53 GMT+01:00 itlists@schrievkrom.de <mailto:itlists@schrievkrom.de> <itlists@schrievkrom.de <mailto:itlists@schrievkrom.de>>:
Sadly this is gone or simply only badly implemented. E.g. in Pharo you can select a package - fine, but to know, what has been extended in this package ?. The name of the method categories also define in which package this method is located in. Make a type error and the method goes into a different package and you will not recognize it. Solutions born by the idea: how can we make it simple to have a solution this evening - and these solutions survive over the years.
It will be changed in Pharo 7 with Calypso. It already shows packages instead of categories with start convension.
You guys should really be thinking in terms of projects not packages especially for Pharo7... browse project lets you see all classes involved in a project, save project saves all dirty packages in project, diff project shows all changes for a project ... etc. etc. ... Dale
You have a very strong point. The problem you emphasised, without explicitly naming it, comes from the image. Because the image preserves state it is also a great receptacle and accumulator for entropies, and as we know entropies only increase, never decrease! The direct consequence is that, at some time, after some interactions, installing code in some order, or installing broken code, an image breaks, hit the ground and becomes unusable. The image limit is always the chaos (as long as it is used as a living thing and its evolving state is preserved, saved), Entropies always comes with interacting 'living' system. So Smalltalk image comes with this downside of entropies. I don't see how you can bring argument against that to developer team, because it is the Smalltalk weakness, as well its strong point. Very funny. Of course you can try to limit entropies. Versioning your image is probably what to do, for example host task could save version of your image every two hours, daily, etc. GNU Smalltalk took an original approach: it ships a minimal image you don't modify and you install code on top of it. So really you never save your image, entropies remains constant over time. This approach is not really possible with Pharo. Best wishes Hilaire Le 15/02/2017 à 23:43, horrido a écrit :
In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
-----
How would you respond? I know Smalltalk can be used in large team programming, but since I personally have no experience with this, I cannot respond intelligently.
-- Dr. Geo http://drgeo.eu
On Fri, Feb 17, 2017 at 06:27:59PM +0100, Hilaire wrote:
Entropies always comes with interacting 'living' system.
Good point. I just tried loading GitFileTree into a Pharo 5 image that I've been using for a while. The image had, to use your term, collected enough entropy such that the loading failed and the VM hung.
GNU Smalltalk took an original approach: it ships a minimal image you don't modify and you install code on top of it. So really you never save your image, entropies remains constant over time. This approach is not really possible with Pharo.
Nowadays we are encouraging building images from configs from the CLI or programmatically, no? Some have mentioned starting with a freshly baked image every day. In my case, I took a fresh image, into which GitFileTree loaded cleanly, then loaded my working stuff through their configs that I've been maintaining. Pierce
Building the image from the shell is what I do for DrGeo release. For development environment it is more in flux but likely should be done. Any recommended reading on that specific point? Hilaire Le 18/02/2017 à 12:54, Pierce Ng a écrit :
Nowadays we are encouraging building images from configs from the CLI or programmatically, no? Some have mentioned starting with a freshly baked image every day. In my case, I took a fresh image, into which GitFileTree loaded cleanly, then loaded my working stuff through their configs that I've been maintaining.
-- Dr. Geo http://drgeo.eu
Hilaire What we do and it is working for a lot of projects. I used the launcher to grab an image built from a CI based on a release Pharo image and a configuration of my project so that I do not have to wait. Pharo50 + ConfigurationOf/BaselineOf + jenkins => image PharoLauncher + click => download image For example for Pillar Jenkins builds 40 stable / dev 50 stable / dev 60 stable / dev based on my configuration and I pick the ones I want to work. When I commit..... bingo the CI sees it and create a new ones with the tests run :) Stef
Building the image from the shell is what I do for DrGeo release. For development environment it is more in flux but likely should be done. Any recommended reading on that specific point?
Hilaire
Le 18/02/2017 à 12:54, Pierce Ng a écrit :
Nowadays we are encouraging building images from configs from the CLI or programmatically, no? Some have mentioned starting with a freshly baked image every day. In my case, I took a fresh image, into which GitFileTree loaded cleanly, then loaded my working stuff through their configs that I've been maintaining.
-- Using Opera's mail client: http://www.opera.com/mail/
Von meinem iPad gesendet
Am 17.02.2017 um 18:27 schrieb Hilaire <hilaire@drgeo.eu>:
You have a very strong point. The problem you emphasised, without explicitly naming it, comes from the image. Because the image preserves state it is also a great receptacle and accumulator for entropies, and as we know entropies only increase, never decrease! The direct consequence is that, at some time, after some interactions, installing code in some order, or installing broken code, an image breaks, hit the ground and becomes unusable. The image limit is always the chaos (as long as it is used as a living thing and its evolving state is preserved, saved),
I do not understand why we should keep entropy low. There are a lot of side effects that occur in a program. It is not only code changes, it is also creating objects, load external data, etc. Is it possible to draw a clear boundary? If not the side effects collect in every image that does something. So having an image that collects huge amounts of side effects and still runs as expected could be seen as robust system, no? Software does not need to fail immediately, it can also when side effects collect. This you cannot easily catch with tests. Trying to keep side effects low could also mean that you should restart your images often in order to get rid of side effects. So keep an image running and operate with it can be seen as stress test for the software. A usual workflow is to commit code changes, having something like jenkins building your image from scratch. You then copy the built image to server and never save it again. To me it has to do with reproducibility that you need in order to have deployment process. To me it is important to have a working image that collects side effects as well as having a process that builds an image from scratch. Norbert
Entropies always comes with interacting 'living' system.
So Smalltalk image comes with this downside of entropies. I don't see how you can bring argument against that to developer team, because it is the Smalltalk weakness, as well its strong point. Very funny.
Of course you can try to limit entropies. Versioning your image is probably what to do, for example host task could save version of your image every two hours, daily, etc.
GNU Smalltalk took an original approach: it ships a minimal image you don't modify and you install code on top of it. So really you never save your image, entropies remains constant over time. This approach is not really possible with Pharo.
Best wishes
Hilaire
Le 15/02/2017 à 23:43, horrido a écrit : In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
-----
How would you respond? I know Smalltalk can be used in large team programming, but since I personally have no experience with this, I cannot respond intelligently.
-- Dr. Geo http://drgeo.eu
The best of the two worlds ;) Le 25/02/2017 à 12:37, Norbert Hartl a écrit :
To me it is important to have a working image that collects side effects as well as having a process that builds an image from scratch.
-- Dr. Geo http://drgeo.eu
On 02/15/2017 02:43 PM, horrido wrote:
In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
----- Well I think that being able to use git (disk based SCMS) for managing Smalltalk code is one step towards making it practical for large teams to work together ...
The major piece that I think is still missing is the ability to have a declarative formula/specification for the contents of an image ... The declarative build formula/specification must be something that can be shared and versioned. Today, the closest we can come to this is an ad hoc Smalltalk script and that really isn't a good answer.... I think that some of the missing building blocks for an image-level declarative formula specification are covered in my "Dangerous Liaisons: Smalltalk, files, and git "[1] talk, but I really think that there is additional work that needs to be done to make it really practical for large teams to be able work together on large projects. Dale [1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git
On 02/15/2017 02:43 PM, horrido wrote:
In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
----- Well I think that being able to use git (disk based SCMS) for managing Smalltalk code is one step towards making it practical for large teams to work together ...
The major piece that I think is still missing is the ability to have a declarative formula/specification for the contents of an image ...
agreed!
The declarative build formula/specification must be something that can be shared and versioned.
Today, the closest we can come to this is an ad hoc Smalltalk script and that really isn't a good answer....
I think that some of the missing building blocks for an image-level declarative formula specification are covered in my "Dangerous Liaisons: Smalltalk, files, and git "[1] talk, but I really think that there is additional work that needs to be done to make it really practical for large teams to be able work together on large projects.
Dale
[1] http://fast.org.ar/talks/dangerous-liaisons-smalltalk-files-and-git
-- Using Opera's mail client: http://www.opera.com/mail/
participants (11)
-
Brad Selfridge -
Dale Henrichs -
Denis Kudriashov -
Dimitris Chloupis -
Esteban A. Maringolo -
Hilaire -
horrido -
itlists＠schrievkrom.de -
Norbert Hartl -
Pierce Ng -
stepharong