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

'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.

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.  

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 :
--
Dr. Geo
http://drgeo.eu

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 <[hidden email]>:

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

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

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



--
Using Opera's mail client: http://www.opera.com/mail/

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.

agreed!


--
Using Opera's mail client: http://www.opera.com/mail/

2017-02-18 8:53 GMT+01:00 [hidden email] <[hidden email]>:

 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

Von meinem iPad gesendet
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

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