
Learning Smalltalk from “Pharo by Example” - sebastianconcpt
http://www.adamtornhill.com/reviews/pharobyexample.htm
======
rlander
As a diehard functional programmer (who used to shun OOP as a fad) who's been
dabbling with Pharo over the last few weeks, I must say I'm impressed. And,
like the article pointed out, I'm having the same "seeing the light"
experience that I first had with Lisp and Erlang.

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](http://simberon.blogspot.nl/2013/01/swimming-with-fish.html)

~~~
CyberDildonics
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).

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

~~~
crististm
"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.

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

------
iso-8859-1
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](http://book.seaside.st/book)

------
muraiki
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](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.

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

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

~~~
amarsahinovic
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/UpdatedPharoByExample)

~~~
mark_l_watson
I wish I could have given you +10 thanks!

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

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

~~~
echoless
Isn't that a big setback for adoption though? The world is moving to multiple-
cores, albeit slowly.

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

~~~
dragonwriter
> 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).

