Learning Smalltalk from “Pharo by Example”(adamtornhill.com)
adamtornhill.com
Learning Smalltalk from “Pharo by Example”
http://www.adamtornhill.com/reviews/pharobyexample.htm
7 comments
I would say Smalltalk is really two concepts that people don't often encounter rolled in to one term. OOP in the Smalltalk sense is message passing and is a fantastic way to structure larger programs if possible. If you think about the internet as one large system, you can see that software complexity can scale with message passing methodologies separating components, especially if you don't care about latency and ultimate performance between them.
The live environment is another extremely powerful and useful aspect, but I wouldn't say that it is OOP. Smalltalk may have pioneered it but it is something that is just good in it's own right from a tools standpoint.
I actually think the more pure a programming language is in one concept the more academic it becomes. I see functional programming as being useful at a different complexity layer than Smalltalk style OOP (and of course Smalltalk does have many functional programming features).
The live environment is another extremely powerful and useful aspect, but I wouldn't say that it is OOP. Smalltalk may have pioneered it but it is something that is just good in it's own right from a tools standpoint.
I actually think the more pure a programming language is in one concept the more academic it becomes. I see functional programming as being useful at a different complexity layer than Smalltalk style OOP (and of course Smalltalk does have many functional programming features).
Last year I added a touch of programming to my 9 year old son's home school activities. We tried several learning tools, starting with Scratch. I don't have anything negative to say about the various options we tried. However, the most positive exercise was him going through the "Prof Stef" tutorial built into Pharo. He really got into exploring and interacting with objects using tradition Smalltalk inspectors and workspaces (Do it, Show it, Inspect it). He loved that he could close the environment and open it the next day with all his play right where it was.
As a father, I loved that I didn't feel like a fraud as I could easily help him dig around and answer just about any question on what's really going on.
As a father, I loved that I didn't feel like a fraud as I could easily help him dig around and answer just about any question on what's really going on.
"He loved that he could close the environment and open it the next day with all his play right where it was." - I can't understand how such a basic functionality is missing from all the popular IDEs and text-editors-turned-IDEs.
It blows my mind that people don't see what an IDE should look like and what it should do.
It blows my mind that people don't see what an IDE should look like and what it should do.
It's all tradeoffs.
There are clear benefits to your IDE remaining unaffected regardless of how badly your program messes up.
Not to mention being able to get your code out of the IDE easily (for versioning, backup, deployment and whatever else). Or having code that is readable/understandable and deployable without an IDE.
There are clear benefits to your IDE remaining unaffected regardless of how badly your program messes up.
Not to mention being able to get your code out of the IDE easily (for versioning, backup, deployment and whatever else). Or having code that is readable/understandable and deployable without an IDE.
It is worth noting that there is also a book on Seaside, a continuation-based web framework that runs in Pharo: http://book.seaside.st/book
Going through Pharo By Example, and especially the similar book "Dynamic Web Development with Seaside"[0] (a smalltalk web framework), really helped me to understand many concepts in OOP. Seaside is worth checking out simply for how differently it does things (the author describes it as a "heterodox" framework). As others have said, once you experience the joy of the flow of programming in Smalltalk with a great environment, it's difficult to not miss it when using other languages.
[0] http://book.seaside.st/book
Edit: Actually, I guess some of the things done in Seaside are now more common, such as building up a webapp from reusable components that have code and some local state coupled with a view.
[0] http://book.seaside.st/book
Edit: Actually, I guess some of the things done in Seaside are now more common, such as building up a webapp from reusable components that have code and some local state coupled with a view.
I didn't really get oop until I learned Smalltalk, working through this book, and subsequently through the Seaside one, was a revelation.
It ruined things for me, most everyday tools and languages look messy and inelegant next to Smalltalk.
It ruined things for me, most everyday tools and languages look messy and inelegant next to Smalltalk.
Good article. I was at first taken aback though by the negative comment in the second to last paragraph about the book being out of date. But, the book is a little out of date.
I am mostly programming my current passion project in Clojure and Clojurescript, but, I shadow my project with a version in Pharo. I love the environment for experimenting and the visibility to what is going on in a computation is a refreshing change from trying to figure out when something goes wrong in my Clojurescript code.
I am mostly programming my current passion project in Clojure and Clojurescript, but, I shadow my project with a version in Pharo. I love the environment for experimenting and the visibility to what is going on in a computation is a refreshing change from trying to figure out when something goes wrong in my Clojurescript code.
There seems to be an updated version of the book, now I just need to find the time to read it :)
https://github.com/SquareBracketAssociates/UpdatedPharoByExa...
https://github.com/SquareBracketAssociates/UpdatedPharoByExa...
I wish I could have given you +10 thanks!
Can Pharo/Squeak programs utilize multiple cores? Last I checked, they used green threads and there weren't any plans to add true multi-threading.
Check out the work on roar vm https://github.com/smarr/RoarVM if you are interested in such things. There are rad videos here too: http://stefan-marr.de/renaissance/
> Last I checked, they used green threads and there weren't any plans to add true multi-threading.
That is correct. My understanding is that supporting multiple hardware threads would require major work in the VM and the development of a memory model. There's some quite critical code in there relies on certain things not being a point for a possible context switch.
That is correct. My understanding is that supporting multiple hardware threads would require major work in the VM and the development of a memory model. There's some quite critical code in there relies on certain things not being a point for a possible context switch.
Isn't that a big setback for adoption though? The world is moving to multiple-cores, albeit slowly.
It's hard to tell. If you compare yourself with traditional scripting languages like CRuby, CPython, JavaScript, Perl, PHP, Lua, … — they all use green threads as well. If you compare yourself to C++, C#, Java then things look differently.
It's probably a bigger issue for the commercial Smalltalk vendors. I would assume for a free, open source project this can be "forgiven" more easily.
It's probably a bigger issue for the commercial Smalltalk vendors. I would assume for a free, open source project this can be "forgiven" more easily.
> It's hard to tell. If you compare yourself with traditional scripting languages like CRuby, CPython, JavaScript, Perl, PHP, Lua, … — they all use green threads as well.
"CRuby" (MRI) since 1.9 and "CPython" (forever, as far as I know) use native threads with a global runtime lock so only one thread running Ruby/Python code (but possibly more running native code in the same process) runs at any given time.
AFAIK, most JS environments don't provide threads (green or otherwise).
"CRuby" (MRI) since 1.9 and "CPython" (forever, as far as I know) use native threads with a global runtime lock so only one thread running Ruby/Python code (but possibly more running native code in the same process) runs at any given time.
AFAIK, most JS environments don't provide threads (green or otherwise).
Smalltalk uses multiple cores by forking processes and passing messages, just like JavaScript, Ruby, Python, etc...
It is true that you can fork in Smalltalk. It is not true that such a fork results in multiple cores being used by the same VM concurrently. At least not in any of the "mainstream" Smalltalk implementations I know (which would be Squeak, Pharo and VisualWorks).
After experiencing what OOP is really all about, an interactive environment with live objects sending messages to each other, readily available to be inspected and manipulated [0], I find it a drag to go back to Python and Clojure (less so) on my day job.
I now feel like every other OOP implementation (without the live environment) is just a horrific bastardized version of Smalltalk.
[0] http://simberon.blogspot.nl/2013/01/swimming-with-fish.html