[bencoman71]

> * Tests are now common and considered a good thing. A new contributor can write code without worrying about breaking rarely-used functionality.

btw, xUnit testing originated with Smalltalk. https://en.wikipedia.org/wiki/SUnit

> * Many languages have package managers. Using latest third-party library is now simple

Metacello is Pharo's tool for defining dependencies between libraries [1][2]. [1] http://sleepycoders.blogspot.com.au/2013/10/dead-simple-intr... [2] http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late...

> * We have great deployment mechanisms -- one-command deployments are common, containers and version pinning help reproducibility.

Pharo Catalog provides a GUI one click installer of Metacello configurations https://pbs.twimg.com/media/CHajfSAWUAEpCBM.png

You can also load Metacello configurations from the command line per last snippet of [1]

Metacello provides version pinning.

You might consider every Smalltalk Image to be a container. Its like a uni sports tour. What happens in the Image, stays in the Image ;)

> * Some languages come with support for interactive REPL -- you can evaluate arbitrary commands inside running processes.

As you say, Smalltalk has a super REPL. How easy is it for other REPLs to modify and query the code of the system? For example in Pharo if I define a class and methods like this...

    Object subclass: #MyClass
	instanceVariableNames: 'count'
	classVariableNames: ''
	package: 'Demo'.

    MyClass compile: 'setCount: anInteger
         count := anInteger'.

    MyClass compile: 'getPlusFive
         ^count + 5'.

I can do this... obj := MyClass new. obj setCount: 3. obj getPlusFive inspect. ==> 8

    MyClass methods asString 

==> '{MyClass>>#getPlusFive. MyClass>>#setCount:}'

> What can smalltalk offer? Obviously it has great REPL. Anything else? > What is the cool new 'software development process' feature that you are referring to?

For me, the greatest thing about Smalltalk is the very tight code/compile/debug loop. Indeed, its common to "code from within the debugger" where you compile your first method calling methods that don't exist yet, and when execution hits them, the system asks you to define that method and then continues execution. This is great for protoyping and (purely subjective) I feel program architecture ends up being closer to how a "user" of the library would like it layered.

A video by someone outside the Pharo community (Avdi has published several books on Ruby) shows a bit of this [3] https://www.youtube.com/watch?v=HOuZyOKa91o&t

Now this is not "cool and new" for Smalltalk. It has had this since 1980. But its a "blub" [4] feature that not many people get exposed to. The saying goes "the only languages worth learning are those that change how you think about programming". And for me, this is what changed how I thought about programming. [4] http://paulgraham.com/avg.html

> For example, I have found exactly one sentence about version control and sharing in the article you have linked: "We may even see Pharo 7, which promises a Git-integration tool called Iceberg for source code version control." . Is this what you wanted to show me? Because my takeaway is that the only way to work on Smalltalk software as a team is to use file-based tools (git). I see no improvements in software development process here.

Git interaction is not what Pharo is selling a better development process. But its an important thing for the Pharo community to make it easier to participate in polygot projects. Historically one of the common criticisms that Smalltalk was insular and didn't play well with others. Monticello had three-way merge for a long time so we were able to live a long time without external version control. Monticello works well for small teams, but doesn't scale well to Internet size teams. We've now recognized those other advances and fixing those reasons "not to use Pharo."

The advantage of Pharo is not so much inter-developer processes. Its simliar to other languages, especially now we are integrating. Pharo's benefit is improving the "flow" of moving thoughts into code. The very tight code/compile/debug loop and minimal syntax reduces the friction of coding.

I heard of a few projects where clients initially resistant to the use of "new" technology like Pharo, but accepted using Pharo to prototype with - but in the end were very happy to leave it all in Pharo.

> The other commenter mentioned Monticello and Smalltalk Hub. Ok, this looks like a decent version control system. > It is interesting how without files, you have to add a prefix to a name of every class and tag each function which you want checked in. Still, I could not find which features it has that git does not.

This prefixing of class names has nothing to do with sans-files. It is just that Pharo does not have namespaces. This does leave the potential for name classes, but in practice the prefixing works well. btw, as another minor demonstration of Pharo REPL, you can change every reference to the class in one line like this...

    MyClass rename: 'OtherClass'.

    obj := OtherClass new.
    obj setCount: 5.
    obj getPlusFive inspect.

==> 10