Newbie to the Group

Hi All,
 I want to introduce myself to this wonderful group and get some
guidance from
 all of you over here. This is Mallik. I'm a software
programmer/developer for the last 8 years working for a company which
builds business applications for the Oil And Gas Industry in US.

The reason why I was trying to learn smalltalk is due to the fact that
I have failed a number of times trying to learn Oo Programming starting
with java. I don't think there is any problem with java, but for some
reason I could not take a business problem and break it into meaningful
object oriented system and build it. The same problem I can solve it in
the available scripting languages or some other tools which would let
you build things in procedural way. Finally I was thinking that java
may not be conducive for someone who has a barrier for transitioning
from a procedural to object oriented paradigm.Moreover building even a
small app in java is no longer trivial.

Now i was able to get a community edition of dolphin, but still not
sure how to explore the system and move forward in the correct
direction.
Please provide me some valuable advice from your experience and let me
a part of this
wonderful group of people.

Hi Mallik,

welcome in the wonderful world of Dolphin.

Just go to the http://l.webring.com/hub?ring=dolphinsmalltalk (the
dolphin pages of the "gurus" and you will find a wealth of information.

All the best,
Janos

Mallik wrote:

> Now i was able to get a community edition of dolphin, but still not
> sure how to explore the system and move forward in the correct
> direction.

Welcome !

Some pieces of advice I'd give to a newcomer to Smalltalk, especially someone
coming from the Java world (which I also inhabit[*], BTW).

First: (this would apply to anyone new to any new language)  You have to
/practise/. Choose something fun, or trivial, or at least (pray God!) not
mission-critical, and write it.  Then write something else.  And again.  And
again...

By-and-large, if you are building whole applications at all, then Dolphin is
happiest writing ones with a GUI.  You can certainly write other kinds of
application, but they tend to require a bit more knowledge of the system,
rather than less.  (Unlike Java where you'd be well advised to start with
command line programs and only commence your life-long battle with Swing later
on).  Expect it to take a little while to get into the MVP framework.  There
are some good MVP tutorials around, but I can't remember the URLs offhand.

Of course, the vast bulk of your code won't be GUIs.  It'll be classes that
provide functionality that you want.  Get used to using the workspaces.  In a
workspace you can create an instance of the class you are working on, and
interact directly with that object.  I don't know about you, but I found that
doing that crystallised OO thinking in a way that nothing else could possibly
have done.  (I don't know how long it took, I /noticed/ it after a year or so,
but it must have happened much earlier).  Working directly with objects in
workspaces is also a massive productivity aid, and it'll probably help clarify
your designs too.

(BTW, it quite often happens to me that I'll create a bunch of classes to be
the meat of some tool I want, intending to put a GUI on them once they are
more-or-less finished.  But then find that just driving them from the workspace
and/or an inspector provides all the GUI that I need, so the tool never
materialises as an independent program.)

As a Java programmer, you are probably not used to the idea of reading the code
for the classes that you use (the classes that come with the system, for
instance).  That is not the Smalltalk way ;-)  The image is full of good
examples (and a few bad ones).  Getting into the habit of reading the system
code there will: (A) give you a lot of information that is not available
anywhere else.  (B) give you some very good examples of how to structure
Smalltalk code.  (C) give you a lot of practise in /reading/ code -- something
that most programmers are not very good at (I was very bad at it before I
started with Dolphin, I have improved /immensely/).  I recommend that you make
very liberal use of the browsing operations (usually bound to F12 and
Shift-F12) to look at definitions of, and references to, classes and methods.

The debugger is your friend !  Don't regard a visit to the debugger as a
"mistake", as something to be avoided.  The debugger is one of the most useful
tools available to you.  Think of it more as a tool for investigating the
runtime behaviour of code.  (You might say that the debugger is to a UML
interaction diagram what the class browser is to a UML class diagram).   Some
people prefer to create their code on-the-fly using the debugger to follow the
execution, and only implementing a method once the code has actually entered
it.  I don't like coding-in-the-debugger myself, but that's just personal
taste.  It's certainly worth trying to see how you like it (and it'll give you
a taste of what a /dynamic/ environment Smalltalk is).

Reverting to the subject of workspaces.  You may, at first, be tempted to write
/programs/ in them -- to try to treat them as you would a scripting language
like Ruby or Python.  That is a /big/ mistake (at least until you know what you
are dong).  In the first place, a Smalltalk script written in a workspace is
not a very effective way to write code (there are no functions for instance).
Much more importantly, it will distract you from the central thing in Smalltalk
which is creating objects to do some job.  So I /strongly/ recommend getting
into the habit of, whenever you have a new task that you want to implement in
Smalltalk, /start/ by creating a classes (or classes).  The workspaces are a
great way of testing and exploring those classes (as I said above), they are
not a /substitute/ for classes/.

Anyway, good luck, and have fun!

    -- chris

([*] "infest" might be a better word ;-)

Mallik,

There are problems with all languages, and IMHO, Java falls flat on
several areas.  However, I applaud you for not blaming the language.
Smalltalk has problems too, but we'll get to those later.

You will find that one of Smalltalk's great strengths is its dynamic typing.

I have some minor disagreement with (or is it discomfort from??) Chris'
statement that Dolphin is happiest with GUI apps.  I know what he means,
and I wish I had some magic words to protect you from (no offense to
Chris - you'll discover he's brilliant) tunnel vision that leads people
to start with a GUI.

Note that Chris also says you should learn to use workspaces - that's
where one is freed from the tunnel.  Where possible, do as much as you
can w/o a user interface.  Part of the GUI tunnel begins in C* where one
needs to "start a project" to do much of anything, and must compile and
run "the program" in order to test anything.  A GUI is a common goal, so
one invariable starts with a GUI.

I am not saying GUIs are bad, nor am I saying that Dolphin does a less
than excellent job of creating them.  Only that you should try to make
you code, where appropriate, independent of any user interface.

Enter unit tests.  Write them, use them.  As Chris said, the debugger is
your friend.  Search the archives of this group for #prod and #prod: -
use the most recent version of it.  In short, I advocate adding a
comment to your test cases, allowing you to invoke the test case from a
browser.  With #prod:, no news is good news, and a problem takes you
straight to a walkback.  I recommend using the SUnitBrowser for getting
an overview and/or when you have reason to think lots of things are
going to pass.  Use a #prod: comment to re-run a failing test as you
work on it, and/or when you have reason to think a particular test will
fail.

If it sounds like I advocate eXtreme Programming, guess again.  I agree
with many of its pillars, but think it is too much of a good thing when
taken as a whole.  In particular, comments are VERY valuable.  Most
valuable are those with a month-year stamp; they pile up over time and I
cannot tell you how many times 12, 6, and 3 month old comments have
pointed to a trouble spot, and often to the solution to a problem.

You will read about test driven development.  IMHO, it's great when "you
know the answer"; use it when it makes sense.  Even when it does not,
you do not loose much by having a test case that starts things rolling.

Note that automated tests accumulate over time, and become a valuable
tool for finding problems.





> , but for some
> reason I could not take a business problem and break it into meaningful
> object oriented system and build it. The same problem I can solve it in
> the available scripting languages or some other tools which would let
> you build things in procedural way.

Just a guess, but it sounds like a mix of getting hung up by static
typing (which often interferes with problem solving), and poor OO
skills.  Smalltalk can help you with both.



 >  Finally I was thinking that java
> may not be conducive for someone who has a barrier for transitioning
> from a procedural to object oriented paradigm.Moreover building even a
> small app in java is no longer trivial.

The secret is that it never was trivial.


Welcome aboard!

Bill


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

Once again I want to thank you all for your valuable suggestions.
So far I have been moving in this direction.
Using dolphin companion (Ted Bracht) for exploring and navigating the
dolphin system
Chamond liu book for general oo understanding

Please keep posting more guidelines and suggestions, so that it helps
newbie like me
and also if we can create another topic with guidelines for newbies and
keep adding to that topic as you
come across something useful and also pointing to that topic whenever
someone like me comes over,
that should relieve you also from repeating

Mallik,

> Once again I want to thank you all for your valuable suggestions.
> So far I have been moving in this direction.
> Using dolphin companion (Ted Bracht) for exploring and navigating the
> dolphin system
> Chamond liu book for general oo understanding

When you exhaust tutorials and becoming able to get Dolphin to do what
you want (perhaps now or a month from now), you will want to read Simon
Lewis' "Art and Science of Smalltalk".  Read "The Blue Book" too, but I
recommend waiting; you will get more out of it (and appreciate just how
smart the PARC gang was and is) if you are comfortable with blocks and
have started to use them creatively.

 From your posts so far, I doubt you will, but please do not take
offense at the above.  You will see what I mean in a year or two.


> Please keep posting more guidelines and suggestions, so that it helps
> newbie like me
> and also if we can create another topic with guidelines for newbies and
> keep adding to that topic as you
> come across something useful and also pointing to that topic whenever
> someone like me comes over,
> that should relieve you also from repeating

It is easier to help when we know what is bothering you at the moment.
Feel free to post questions as you learn.  The things you need to learn
(and unlearn!) will be somewhat unique to you, so tell us when you get
stuck.

If you do a Google search on

        Dolphin wiki AdviceToBeginners
        Dolphin wiki MaintainingAnImage

or just

        Dolphin wiki

and choose the _cached_ links, you will be able to find some good
information.  OA is working on bringing the wiki back to life, but the
snapshots should be of some help to you.

Have a good one,

Bill

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

Bill,
      I will definitely keep in mind what ever you are saying.
      As said earlier I was using ted bracht book, so far I didn't had
any trouble
      following the book, but having some difficulty to explore and
understand
      the classes in the system(i mean why they are structured that way
and
      what behaviour the subclasses are inheriting and overriding from
super classes etc)
     
Thanks,
Mallik.

Mallik,

>       As said earlier I was using ted bracht book, so far I didn't had
> any trouble
>       following the book, but having some difficulty to explore and
> understand
>       the classes in the system(i mean why they are structured that way
> and
>       what behaviour the subclasses are inheriting and overriding from
> super classes etc)

Some of that will come fairly easily, and other parts (some uses of
blocks, meta classes, etc.) are more subtle and will take time to
appreciate.  The good news is that much of it won't matter very much.
You will simply find that with time, you will write better code, often
less of it that does more than an equivalent number of lines you write now.

Do you have any specific questions?

When you tire of following examples, pick a simple problem and try to
solve it.  That will give you a source of questions.  Be sure to write
some tests, and use them as you make changes.

Have a good one,

Bill

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