forgot to mention, I also regularly refer to the "Terse Guide to Squeak"
http://wiki.squeak.org/squeak/5699
Ben Coman wrote:
Frank Church wrote:
Hi Igor,
I am new to Smalltalk but not new to programming and I am into my
first 14 hrs into learning it with Pharo.
Good to have you on board Frank. It will be interesting to follow
your experience in becoming proficient in Smalltalk & Pharo. I am
just coming up on a year of using Smalltalk/Pharo. There are a lot of
hidden depths and I learn a lot watching the mail list for answers to
questions that I hadn't thought of asking yet. So fire away.
I'll just mention a few things that I have learned that make it easier
to plumb the system for examples.
Also see
http://marianopeck.wordpress.com/2012/05/19/pharo-tips-and-tricks/
As I was trying to work out the right syntax it brought to mind the
thoughts of Brendan Eich, Gilad Bracha and Lars Bak who said the
familar syntax (Algol/C style) of languages like Javascript, Go and
Dart was chosen to make it easier for programmers familiar with C,
Pascal etcetera to starting using. them, rather than learn a whole new
paradigm, even at the cost of complicated parsing and language
structure.
The flipside is that it makes it easier to continue operating with
your old paradigms in a hybrid manner, preventing you gaining the most
'stretch' most from a new paradigm.
That is a very personal choice depending on what you want to gain from
new learnings. However the main paradigm shift of Smalltalk is not
its syntax but its 'live environment'.
If I was using Eclipse IDE for instance, at every step I could use
auto-completion and the documentation to decide what follows from
what, even in a domain I had no familiarity with, but Smalltalk
doesn't lend itself to that approach.
I was going to just ask for some examples of what you particularly
liked in Eclipse. We can learn from other systems. However with a
quick browse I found [1]. Do you have anything to add to that?
[1] http://eclipse.org/recommenders/documentation/usr.html
A few thoughts in response...
_Intelligent Code Templates_ - "But code templates /really/ shine when
developers have to use APIs they are not very familiar with. Then,
code templates serve as additional documentation that quickly shows
how an API can be used and save developers lot of time otherwise
needed for reading API documentation. Eclipse maintains more than 70
of such Java code templates"
Within Smalltalk, rather than 70 templates you have the whole system.
If you are browsing a class and see a method which seems like what you
want, click <Senders> to get an idea of how to use them. Another way
to learn the system is to temporarily edit any method to insert a
'self haltOnce' then 'World-menu > System > Enable halt/inspect once'
which will bring up a debugger where you can explore the call chain to
see a live demonstration of how that method is used. The reason to
use #haltOnce rather than #halt is that method might be used by the
display system and you wold end up locking the image with cascading
halts as the display loop runs. Using halos, you can <Duplicate> that
menu item and leave it sitting on the background as a button for easy
access.
You can highlight any method and use <cmd-n> or <cmd-m> to get a list
of senders & implementors of that method. I often find myself
following several levels to understand a chain of calls.
Learn the difference in using the <Into> <Over>& <Through> buttons
when debugging (eg from the Workspace context menu) something like
'#(1 2 3 4) do: [ :x | Transcript crShow: x].' For quite a while I
had missed using <Through> properly which hamstrung me when tracing
code and not wanting to trace the machinery of how #do: worked.
_Intelligent Overrides Completion_ & _Subclassing Directives_ &
_Self-call Directives_
These look interesting, in particular if they bought up examples from
public repositories outside the image.
With spoken languages even without proper syntax or phrasing a person
who knows the language can deduce what you are trying to say but with
computers you either get it right or the computer stares back at you
blankly.
As an experienced programmer I am trying to accomplish something
non-trivial as hard and as fast as I can with Squeak, Pharo and their
supporting libraries and ecosystem and the only way is to bombard the
mailing lists and forums. You could say I am trying to understand how
the language constructs can support my intentions as fast as I can.
With respect to the above I can truthfully say that at this juncture I
don't know what it all means, from the theoretical view point, nor
from the practical perspective of what I am trying to accomplish,
which is why the questions are flying in so thick and fast.
Last of all - teachers please, I don't want to go to Smalltalk
kindergarten. I have done too much programming in my life to be put in
kindergarten when I start Smalltalk.
The problem here is although one can learn from reading examples, it
can be hard to understand the language constructs unless they are
derived from one's own use cases, and this is why my questions have
been coming in so thick and fast.
Even in light of that wanting to use your own use cases, there is one
example I would recommend [2] - since it is the best demonstration
I've seen of the paradigm shift of programming in Squeak/Pharo's live
environment. It is not entirely trivial - it took me a couple of days
to get through it - but the main reason I recommend it is that it is
more than a code example. It is a demonstration the power of the
system to refactor as the design evolves from concept to
deployment. The author exposes errors in design and how best to use
the debugger. Kind of a "this is how things are done in Smalltalk".
YMMV but I personally found it useful to help me change my approach
from previous programming languages. It is actually one of the main
things that mad me focus more on Smalltalk. You would need to
temporarily regress a few years to use Squeak 3.9 to match the
article, then come back to use the latest and greatest in current Pharo.
[2] http://squeak.preeminent.org/tut2007/html/index.html
cheers -ben
