Newbie Questions Regarding Best Books etc. for Dolphin & Smalltalk

Hello out there!

I'm just starting out as a Smalltalker, though I do have 23+ years as
a mainframe coder and also have background in Java too, and I'm
searching around for the best learning materials regarding Smalltalk
and Dolphin.  There doesn't appear to be a whole-heck-of-allot out
there and I'd like to make sure I don't waste time and money going in
the wrong direction.

I'm running the most recent release of Dolpin (standard edition) but
haven't a clue and would like to get some direction from those in the
know.

You know, best books to read, websites to visit, tutorials to guide me
through the mess, etc.

I'd just like to get off on the right foot and not pickup any nasty
(coding) habits (if you catch my drift).

Any help from you guys and gals would be greatly appreciated.

Steve

Ted Bracht's _The Dolphin Smalltalk Companion_ is the only Dolphin
specific book that I know, and is useful IMHO, especially for its
coverage of the MVP framework (which is slightly different from the
MVC framework common in other Smalltalks).  It doesn't have that much
very basic material, though.  A book I liked for that was Chamond
Liu's _Smalltalk, Objects, and Design_. As always, YMMV.

--
Howard Ding
<[hidden email]>
http://math.sunysb.edu/~hading  http://thunder.prohosting.com/~hading

If you're looking for free ST books, Stephane Ducasse just posted this
link on the french squeak mailing list

http://www.iam.unibe.ch/~ducasse/WebPages/FreeBooks.html

Not dolphin specific, but it seems like a solid ST list.

Eric

Steve Campisano wrote:

Steve,

> I'm just starting out as a Smalltalker

"Welcome to the real world"  ;-)

> though I do have 23+ years as
> a mainframe coder and also have background in Java too, and I'm
> searching around for the best learning materials regarding Smalltalk
> and Dolphin.  There doesn't appear to be a whole-heck-of-allot out
> there and I'd like to make sure I don't waste time and money going in
> the wrong direction.

I'd second both of Howard's two book recommendations.  I'd add the "GoF"
book ("Design Patterns", by Gamma, Helm, Johnson, and Vlissides) which you
may well already have read.  And I think I'd leave it at that for books (in
particular, I don't think that the Smalltalk companion to the GoF book is
worth the time).  Possibly add Kent Beck's "Smalltalk Best Practice
Patterns" if you enjoy reading.

As far as web material goes, there's the wiki:
    http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
There's Ian's tutorial:
    http://www.idb.me.uk/tutorials.html
There's Louis's much extended version of the OA "Personal Money" tutorial:
    http://www.mindspring.com/~lsumberg/PersonalMoney/

The best resource (apart from the image itself) for the nuts-and-bolts of
Dolphin programming is undoubtedly this newsgroup. Ian maintains an archive
at:
    http://www.idb.me.uk/news.html
and I'd strongly recommend that you pick up a copy and one of the readers
for it (links at the above page).

BTW, my implied comment that the *best* source of information, examples, and
guidance is the image was serious.  I don't know about you, but for me when
I started Smalltalk (coming mostly from the C-family) it didn't feel
natural, in fact it felt like cheating, to go off looking at the
implementation's of the classes I was using.  But that's not how it's
supposed to work -- the source is there to be used, read, and (possibly
even) pondered over.  (As an aside, I feel that the quality of the Dolphin
image has declined since OA started using the refactoring browser -- too
many uncommented methods, to much intention-revealing layout thrown away.
It's still pretty good for the most part though, just patchier than it was.)

    -- chris

Steve Campisano wrote:

> You know, best books to read, websites to visit, tutorials to guide me
> through the mess, etc.

If you download the non commercial release of VisualWorks (and it's a
huge download, I'm afraid) it comes with pretty good documentation. This
is how I originally learnt Smalltalk, and I'm happy it happened that
way. I know this seems odd advice for learning Dolphin, but the core
language parts will still be relevant, and it explains a lot of what's
happening under the hood.

I'd also put in a good word for _The Art and Science of Smalltalk_ by
Simon Lewis, and not quite as good but still worthwhile, _Smalltalk by
Example_ by Alec Sharp.

> Steve


                            Steve

[hidden email] (Steve Campisano) writes:

I started at the Education Centre at www.object-arts.com. The
beginners tutorial there guides you through the absolute basics of the
language which I felt that I needed given that the syntax of Smalltalk
is very different from more mainstream C like languages.



--

Vennlig hilsen

Syver Enstad

"Steve Campisano" <[hidden email]> wrote in message
news:[hidden email]...
> Hello out there!
>
> Any help from you guys and gals would be greatly appreciated.

Dave's Smalltalk FAQ (http://www.dnsmith.com/SmallFAQ/) is not Dolphin
specific, but I have found it to be very usefull.

rush

Hello all,

> As far as web material goes, there's the wiki:
>     http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm

<shamelessPlug>See AdviceToBeginners in particular</shamelessPlug>.


> BTW, my implied comment that the *best* source of information, examples,
and
> guidance is the image was serious.  I don't know about you, but for me
when
> I started Smalltalk (coming mostly from the C-family) it didn't feel
> natural, in fact it felt like cheating, to go off looking at the
> implementation's of the classes I was using.  But that's not how it's
> supposed to work -- the source is there to be used, read, and (possibly
> even) pondered over.

Well said, all except the "possibly" :)


> (As an aside, I feel that the quality of the Dolphin
> image has declined since OA started using the refactoring browser -- too
> many uncommented methods, to much intention-revealing layout thrown away.
> It's still pretty good for the most part though, just patchier than it
was.)

I would say the _helpfulness_ of the image has declined somewhat, and you
are spot on associating it with the RB, and more to the point, to the
inability of the formatters to use clues from the source given to them.
With that said, I'll admit that there is a good argument for "less helpful"
leading to lower quality, especially for newbies.  How can we tell people to
"look at the code" when the code has been formatted by a machine that has no
sense of phrasing (to steal a musical concept), and the coode has NO
comments.  Selling Smalltalk is an uphill battle even with a carefully
fomatted and commented class library.  As harsh as it might sound, I fear
that after a few years of XP, we will have systems that even we don't
understand.

This problem is not unique to Dolphin; I see the same thing happening in
Squeak.  I spent an unpleasant few hours deciphering some Squeak VM code
that had even two of the ten or so lines been commented, would have made
sense to me in a matter of seconds.  Being a relative newbie when it comes
to Squeak, I've been frustrated by a lack of comments in Morphic.  I'm not
advocating that we go back to two comments for every line of code<g>, but
we've gone much too far the other way, and the costs will take time to
reveal themselves.

My own RB experience has been as follows:

(1) D5's ability to scope refactorings was **very** helpful to me in fixing
some problems with overly generic selectors.  Some formatting that I find
quite important was destroyed, but I was willing to put it all back later
(long since done) after the refactorings.  The code works very differently
now, but the initial refactorings were a crucial step, and would have been
very difficult to make manually.

(2) I eagerly use the RB on new code, and moving variables and methods up
and down seems harmless with respect to formatting.  With "old code", the RB
becomes a judgement call.  In the past week, I revised some code in which
comments dated 6 to 18 months ago were quite helpful.  Many such comments
appear in cascades, and the RB leaves them unrecognizable if not misleading.
I added parameters manually as a result.

(3) My one complaint re Dolphin's RB integration (which is masterful!!) is
the absense of a non-refomatting class rename.  I utilize the RB (not all
the time, and only after considering tradeoffs mentioned above), so I have
no desire to uninstall it, and I'm certainly not willing to
uninstall/reinstall it just to rename a class.  The result is that I've
sometimes created a class with the desired new name, dragged a lot of
methods to it, and then changed references to the old name.  With that said,
most renaming occurs in newer code where I'm less worried about formatting;
still, I'd like to have an obvious alternative to the RB for renaming
classes.

The recent STB bug hunt is an excellent example of how a small piece of
commented code (would not XP have mandated removal of the commented code -
the tests passed, right?) can be a life saver.  Had that not been fixed, I
would have had to remove the binary filer from my apps.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> > (As an aside, I feel that the quality of the Dolphin
> > image has declined since OA started using the refactoring browser -- too
> > many uncommented methods, to much intention-revealing layout thrown away.
> > It's still pretty good for the most part though, just patchier than it
> was.)
>
> I would say the _helpfulness_ of the image has declined somewhat

That's a fair distinction.  The factoring, etc, is fine (and OA keep improving
it), its just the details of the expression that aren't getting enough
attention.

> formatted by a machine that has no
> sense of phrasing (to steal a musical concept)

A very nice phrase, um, expression.  I'm going to steal it ;-)

> My own RB experience has been as follows:

I don't use it myself.  I'm too fussy about formatting, or -- more precisely --
about when to break the "mechanical" rules of my preferred layout.  In fact I
remove the RB from my image as a matter of course.

> My one complaint re Dolphin's RB integration (which is masterful!!)

Agreed.  I wish I didn't have to disable it.

> is the absense of a non-refomatting class rename.

I agree with that too :-(

> Bill

    -- chris

Bill,

> The recent STB bug hunt is an excellent example of how a small piece of
> commented code (would not XP have mandated removal of the commented code -
> the tests passed, right?) can be a life saver.  Had that not been fixed, I
> would have had to remove the binary filer from my apps.

No, XP says to remove meaningless comments. Or to use the presence of
comments inside a long method to provide a code smell that the method should
be split up and meaningful names be used for the new methods. Most times
these method names can replace the original comments at the calling
location.

The particular comment you are talking about was really something left in by
accident and should probably have been removed by the original coder when
the change had been validated. That it wasn't is just good fortune and
nothing to so with XP or refactoring.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---