Team programming with Smalltalk

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Team programming with Smalltalk

horrido
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.
Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

kilon.alios
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

Brad Selfridge
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
Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

HilaireFernandes
In reply to this post by horrido
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


Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

Esteban A. Maringolo
In reply to this post by Brad Selfridge
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]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

Dale Henrichs-3
In reply to this post by horrido


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

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

itlists@schrievkrom.de
In reply to this post by Esteban A. Maringolo
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

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

Pierce Ng-3
In reply to this post by HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

HilaireFernandes
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


Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

stepharong
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/

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

stepharong
In reply to this post by itlists@schrievkrom.de
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

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

stepharong
In reply to this post by itlists@schrievkrom.de
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.

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

stepharong
In reply to this post by Dale Henrichs-3

>
> 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/

Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

Denis Kudriashov
In reply to this post by itlists@schrievkrom.de

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. 
Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

Dale Henrichs-3



On 02/20/2017 03:58 AM, Denis Kudriashov wrote:

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
Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

NorbertHartl
In reply to this post by HilaireFernandes


Von meinem iPad gesendet

> Am 17.02.2017 um 18:27 schrieb Hilaire <[hidden email]>:
>
> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Team programming with Smalltalk

HilaireFernandes
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