I've had the same experience myself.  And now that I'm starting to introduce
& teach Pharo to some of my colleagues (to build a users group where I
work), I realize this can be a significant deterrent or stumbling block for
newcomers.  That's gotten me to think a bit about how to best address this
issue, for myself and others.

Now, as part of my introductions, I emphasize that "one of the hardest
things about learning any object-oriented language is learning the base
classes and methods -- because that's what you build */your/* application
code on top of -- so you need to be familiar with it."

Then I point out that you cannot learn the whole thing at once, but
fortunately /you do not need to/.  Adopting Pharo after a career of using
other programming languages & environments can be a lot like changing
operating systems (e.g., Windows -> Linux or Mac): You'll need to learn the
basics to get started, then you add to your knowledge of what's there and
how it works bit by bit as you realize there's something you need to know. 
You learn it incrementally.  But there's already a lot there that's familiar
in principle; the names, apperance, and locations are of course different. 
But "you know what /should/ be there... what's it called? where's it
located?"  The answers to these questions can usually be quickly found -- if
you know the questions.  ("What you know you don't know" versus "What you
don't know you don't know'.)

You can also pick something each day to research in Pharo, gradually getting
more & more familiar.  Experiment or watch videos, etc.

Then I point out that Pharo has several tools & techniques to help with
exploring and discovering classes and methods:
* The Spotter, for quickly drilling down to what you need, or to reach a
good starting place to begin exploring.
* The Finder, including the ability to search by example.
* 'Code search...' in the context pop-up menu (especially senders and
implementers of).
* The Playground: Provides a great way you can experiment with code snippets
to see how things work; coupled with inspecting the results of
expressions/statements, you can quickly get many starting points for further
ideas.

(If any readers can expand on this list, or phrase things better, please
do!)

One thing I did recently to experiment with the "explorable nature" of Pharo
was inspired by noticing that in the Playground, if you "Print it" on an
expression, the result appears in an ephemeral text widget; it disappears
when you next click.  But in other windows (most noticeably 'ProfStef'), the
result is automatically pasted into the source's window.  This can be
useful, but sometimes it can be unwanted.  (Yes, there is the option of
"Inspect it", but "Print it" is quick and simple: "show me, then go away".)

I wanted to know why it was different, and how...  So I set off exploring,
with the challenge of drilling down to the specific lines of source code
deep within the base classes that produced each result, so I could see the
difference in rendering "Print it" for these two cases.

It was intimidating at first, but using the techniques I listed above (and
two sessions, after the first one was "going off the rails" a little), I
found both methods in a couple of hours.  And it increased my understanding
of "how it works".  But it did something else, something a little intangible
by comparison: It took away some of the mystery of "how Pharo works
internally" (while boosting my appreciation of Pharo's brilliance in design
and execution).  Along the way I learned a bit about how some of these
classes work, where they are in the hierarchy, and how they link together.

Ultimately, my initial goal turned out be a much bigger challenge than I
originally thought it would be: I wanted to see if I could mod ProfStef to
*not* paste the "Print it" results into its own presentation window, and
behave instead like the Playground.  I found that the "column of classes"
that lead to these two different behaviors are well-separated, and it seems
to require the duplication of a lot of code to even begin do this; a simple
override or extension to one or two base classes won't work.

But it was satisfying to prove I can do this -- without help, on my own --
and boosted my confidence that I can "disassemble Pharo" whenever I need to,
to answer these kinds of questions, find things, and learn the finer points
of how they work & interoperate.

-Ted



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply via email to