bencoman71
A peculiar perspective of Smalltalk programmers is to consider that "code in files is dead code". External tools are needed to query it, modify it, compile it.
In Pharo you can evaluate... Integer methods first inspect
and in different tabs you can see this method's source code, the AST, the compiled bytecode.
Or in a similar way we can look at how PLUS is implemented by evaluating (Integer>>#+) inspect
Or look at all the methods that use PLUS
#+ senders inspect
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'.
MyClass methods asString > 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."Zinc" - It used to be an external package later integrated into Pharo. To check it out, download Pharo 5 from http://pharo.org/download
then try the tutorial... http://zn.stfx.eu/zn/build-and-deploy-1st-webapp/. Debug some of those examples and you'll get a look at Zinc's internals.
"Teapot" - I haven't used it but seen others in the mail list describe it as elegant. You can load it into Pharo 5 from Tools > Catalog Browser.
https://skrishnamachari.wordpress.com/2014/08/28/teapot-phar...
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBo...
Please ask questions in pharo-users if you get stuck. http://lists.pharo.org/mailman/listinfo/pharo-users_lists.ph...
With respect to other languages, many don't do OOP well ;] Indeed in the OP video Alan Kay said "Object oriented programming never made it outside of Xerox Parc - only the term did" (1:06:40)
> Smalltalk encourages an explosion of complexity
Smalltalk is a fantastic prototyping language. Its easy to explore a new domain and get something working fast. Such an exploratory process can lead to overly-complex software. I guess the trick is to have the discipline to go back and do the "science" to distil and refactor.
That's given you a false impression. The .st file is only an the export/transfer format to be loaded into another Smalltalk system. Smalltalk code is best read using its System Browser. Think of opening a .docx file in Notepad, and how clean you think it looks compared to editing the file from within MS Word.
Yet not being able to use your favourite text editor is one of the common arguments some people use against Smalltalk, but perhaps there's also an element of them trying cast something "new" (Smalltalk) to them, back into what they already know (as Alan Kay touches on after 1:04:00 in the OP video link)
Now you've probably heard that in Smalltalk everything is an object. Sure its an nice catch-phrase but hard to grasp its significance. Consider then, that classes and methods are live objects within the Image. You can operate on them as you work within the live Image and from your application program.
For example, the Pharo mail list was recently asked the following question... > I want to have many different object instances with different > behaviors picked at random from a list of available behaviors. What I had in mind was a functionality similar > to prototyped languages like Self and Javascript in which you > could change the behavior inside the object and not the class/prototype.
A way to achieve this is to define each behavior as a normal method. For convenience, we'll define two protocols, 'behaviors' and 'non-behaviors' in the system Browser to hold these. For the uninitiated here is a short intro to the Browser. Protocols show in the third pane. https://www.youtube.com/watch?v=zgQjcZ9SCCs
The class MyObject is defined with an instance variable to hold which behavior to invoke...
Object subclass: #MyObject
instanceVariableNames: 'behavior'
classVariableNames: ''
package: 'Example'
behavior1
Transcript show: '1'.
behavior2
Transcript show: '2'.
In the Browser, add these two methods to the 'non-behaviors' protocol...
initialize
| behaviors |
behaviors := self class methods select: [ :m | m protocol = #behaviors ].
behavior := behaviors atRandom selector.
perform
self perform: behavior.
To test this, from Playground (our REPL) evaluate... Transcript open. 10 timesRepeat: [ MyObject new perform ].
==> 2221212212
But how do I add new behavior at run-time you may ask? Now since classes are objects within the runtime Image, the application can ask the class to compile a new behavior. This is can be demonstrated by evaluating this code in the Playground...
newBehavior := 'behavior3
Transcript show: ''3'' '.
MyObject
compile: newBehavior
classified: #behaviors
notifying: nil.
Transcript clear.
10 timesRepeat: [ MyObject new perform ].
That flexibility is why I love Smalltalk.
Pharo By Example is being revised for Pharo 5. The first 13 chapters are done... https://github.com/SquareBracketAssociates/UpdatedPharoByExa...
The whole book can be downloaded from... https://ci.inria.fr/pharo-contribution/view/Books/job/Update...
That was likely Squeak, not Pharo. Pharo has muted a lot of the UI colours to be more appropriate for a business environment.
> How anyone could possibly be productive in such an environment. What is it that's so attractive about it to Smalltalkers?
Perhaps its useful to get some outsiders perspectives....
Avdi Grimm has written a few books about Ruby. He records his experience trying Pharo in "I make you hate Ruby in 7 minutes"
http://www.virtuouscode.com/2015/05/11/in-which-i-make-you-h...
Noel Rappin has written a few books about Ruby & Javascript. He provides an introduction to Smalltalk in "MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk"