Learning Smalltalk from “Pharo by Example”
adamtornhill.com
adamtornhill.com
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
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).
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.
It blows my mind that people don't see what an IDE should look like and what it should do.
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.
[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.
It ruined things for me, most everyday tools and languages look messy and inelegant next to Smalltalk.
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.
https://github.com/SquareBracketAssociates/UpdatedPharoByExa...
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.
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.
"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).