The Path From eToys To Squeak To SmallTalk - Or The Other Way

I've been a would be programmer for many years.  I'm one of those people
who just "does not get it".  I understand things like eToys and other
visual "programming" environments but have much difficulty making the
transition to true programming languages, since they are not visual and
usually not very natural, (intuitive), to a visual thinker.

I know that learning SmallTalk would be the next step for me, but there
does not seem to be any documentation for the absolute beginner who
knows nothing about programming and programming terminology, (classes,
methods, functions, etc.).  Since SmallTalk makes its claim of being a
_/truly/_ object oriented language, and it is at the heart of Squeak, it
makes sense for me to move in that direction.

Where does the complete beginner begin with SmallTalk?  Too bad that
eToys doesn't take the exercise a step further and also take the user
from visual programmatic thinking into visual programmatic programming,
with learning SmallTalk as its goal.

Thank you,

Greg Smith
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Thanks

I hope to restart to work on the next one...
http://smallwiki.unibe.ch/botsinc/



On 6 nov. 06, at 00:13, Gene Venable wrote:

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi Greg,

Learning Smalltalk is definitely and experience.  There is a major "Ah-ha!"
moment prerequisite.  It is really amazing to see people hit that "Ah-ha!".
Some people do it quickly but most take some time.  I've seen it come after
even a years worth of practical hands on programming, so don't get
frustrated if it doesn't come right away.

The best I can do to help you is to give you some hints on how to get there
yourself.

1) Object message.  Programming in Smalltalk really doesn't get much harder
then this concept.  Object message.  

it := Consider theConcept.
you := Person new.
you live: it.
you breathe: it.
you sleepOn: it.

What is the Object?  (An instance of a class or class definition)
What is the message?

Everything is Smalltalk follows this pattern; there is an Object and a
message.  The message or method may have parameter.

2) Your code goes everywhere!  One of the first questions I'm always asked
is; "Where does my code go?"  The answer is EVERYWHERE!  In Smalltalk you
are building objects.  By that I mean you can model real things.  Pick
anything and think of it as a component of the rest of the system, and
consider what components make up this thing.  For example: aShoe.  

aShoe := Shoe new.
aShoe laces: ShoeLace greenLaces.
aShoe color: Color green.
aShoe price: (USDollars dollarValue: 12).
aShoe owner: aManufacturer

You can see that there are many different components or Objects that can
make up what you are modeling.  Relationships can be modeled, new components
can be added, you are free to model what ever you want.  So where does your
code go?  It goes where it is needed.  It goes in the object that needs that
code.  For example sell a shoe:

Manufacturer>>sell: aShoe to: aPerson
        "sell a shoe to aPerson collect price, update books and decrease
inventory"
        aPerson collectMoney: aShoe price.
        self updateMonthyBooks: (Sales item: aShoe price: aShoe price date:
Date today).
        hasInventory := self removeFromInventory: aShoe.
        hasInventory ifFalse: [
                self backOrder: aShoe
        ].

You can see lots of objects that are implied in this code but look at where
the code is.  aPerson which is an instance of Person is responsible for
paying so collectMoney: is on Person.  There could be lots of ways that a
person could pay so let the person object handle that.  The manufacturer has
its own account books so it should be able to updateMonthlyBooks: which
could be sent to an AccountingSystem instance.  

I also hear: "Once I make a really great shoe, how do I hook that into the
rest of the system?"  This really confuses some people.  Try to see your
program as more then just pieces, but instead as a whole entity.  When you
realize that your program could start like this:   ShoeStore open.  Or
MyWorld turn.  Or  MyWorldsTime start.  Or   Universe explode.   It's easy
to consider how a shoe might fit in your program.  

3. Polymorphism and Inheritance.  Do I need to understand these to
understand Smalltalk?  YES!!  But don't worry.  They are big words for
simple concepts.  

You are a child of your parents.  You inherit certain characteristics from
them, which make you like your parents, but you change some of the
characteristics to allow you to be more of yourself (polymorphism).
Polymorphism means having many forms.

So how does that help?  The concept of objects would be good enough and
still be very powerful without this functionality but when you add in
Inheritance and Polymorphism you really start to cook!  These concepts
really get things moving and allow you to do some fantastic programming.

Let's extend the shoe store example. What if we wanted to sell socks or shoe
polish, or custom shoe laces?  

What are the things that are similar that could be modeled as a superclass
so that our salesItems could inherit those behaviors?  

Object subclass: SalesItems
        instanceVariables: 'purchaseDate purchasePrice manufacturer'

SalesItem subclass: Shoe
       
SalesItem subclass: ShoePolish

SalesItem subclass: ShoeString

You can see from this example that subclasses of SalesItem inherits the
instanceVariables purchaseDate purchasePrice and manufacturer.  

We could implement methods on SalesItems that allow us to sell a general
item without having to implement these methods on every item.  That is the
power of inheritance.  

Now what things need to be different for each item?  Since I'm making this
up as I go let me apologize if this is not the best example.

Say that our store likes to make funky shoes by buying them from the
manufacturer, then changing the laces.  We also sell other funky laces, and
we allow people to change the laces before they leave the store if they want
too.  How are we going to keep track of all this?  

We want to be able to just sell and item without having to worry about this,
so

SalesItem>>removeFromInventory: anInventory
        "remove this item from anInventory"
        anInventory removeFromInventory: self.

Now if you call this method on ShoePolish then anInvetory will
removeFromInventory: self (self is an instance of ShoePolish since this
method is called from there).  This method is inherited.

Let's change things for Shoe

Shoe>>removeFromInventory: anInventory
        "remove this item and it's shoe laces from anInventory and replace
shoelace if necessary"
        | lacesWereChanged theShoesLaces |
        anInventory removeFromInventory: self.
        lacesWereChanged := self askUserIf: 'Were the laces changed?'.
        theShoesLaces := lacesWereChanged
                ifTrue: [self askUser: 'Please select laces from list'
forItemInList: anInventory shoeLacesList]
                ifFalse: [self laces].
        anInventory removeFromInventory: theShoesLaces.


Now this is polymorphism.  When you remove an item from inventory it will do
what you want since it inherits a method from SalesItems.  If it doesn't do
what you want you can give your object its own personality by changing what
it does.  This is polymorphism.

Go forth and Smalltalk, and if you have questions feel free to ask!  This is
the place to do it.

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
[hidden email]
       

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners