One of the guys on a robotics list I am on was interested in using Squeak
for his robot after I showed him what I had done with my RoboMagellan
controller:

http://www.huv.com/roboMagellan/MissionEditor.jpg

He's been playing with Squeak for a week or so, and he posted this reply to
someone who was asking him why Squeak (and I'm reposting it here with
permission):

==========================
"Robert F. Scheer" <RFScheer at speakeasy.net>

> Hello,
>
> tell me more about squeak please...

First, let me make it clear I am not yet advocating Squeak.  I'm into it 
now for almost a week.  I'm finding it very fun and it looks like it has 
a big chance of being my robot programming environment for the next 20 
years.  But it's possible that could change, obviously. 

Squeak is an open source evolution of Smalltalk-80.  I think it doesn't 
help to describe it as 100% object oriented and so forth.  What really 
attracts me is how you can build up applications from your own and 
others' collections of stuff written for other projects often in 
unrelated areas.  The unique integrated design environment is fun and 
powerful.  Apparently it is common to write code by first specifying 
verification procedures and then working backward.  It is often common 
to write code in the integrated debugger.  The code is compiled as you 
go and it is always live.  When you enter a line or a class, the IDE 
won't allow grammar errors or references to missing variables and so 
forth.  You spend no time on type declarations although types are quite 
rigid, but you don't have issues of different modules using common 
headers and cr.p like that.  Garbage collection is totally built in and 
needs no programmer attention. 

A squeak program (image) will run under all *nix's, Windows, Mac and on 
any machine that hosts those so you can write it on your desktop, test 
various stuff there and then file it out to your robot for ground 
testing.  Large robot control images can be adapted over time to 
different projects without rewriting huge portions of code.  The same 
image could be extended over many years to control new robot projects 
while still being backward compatible to older ones.  This way if you 
develop a brand new feature it might be available to an older robot with 
no further effort.  If early bots use simple subsumption architecture, 
that code can remain available while you add higher level techniques so 
it's easy to imagine testing a brand new robot first with the most basic 
subsumption behaviors and then adding the newer ones layer by layer as 
you test. 

Oh, the Squeak community on the web is really well organized and there's 
a huge degree of sharing.  Code is much easier than other languages to 
share.  I believe that even though not that many people seem to use it 
in my immediate circle (read zero), and I doubt a major fraction of the 
world's programmers use it, they make progress pretty quickly due to the 
community pool of knowledge. 

I may be misusing some concepts but I hope you get the idea.  I hope I 
still agree with this description a year from now.

The place to start is a fantastic (free) ebook at this site (Squeak by 
Example):

http://www.iam.unibe.ch/%7Escg/SBE/

I found that Ubuntu made it easy/instant to load version 3.9 sources 
from repository.

There are some downsides to Squeak of course.  Images tend to be much 
larger, meaning multi-MB, than programs in other languages and they're 
not as fast either but that's not something I'm qualified to amplify on 
atm.  Jon Hylands runs Squeak on Gumstix miniature computers so that 
tells you that a fast ARM processor is probably the minimal hardware 
environment.  You will not be running Squeak on a PIC or AVR or 
Propeller though. 

I am not sure but doubt you could write a vision processor in Squeak 
with reasonable performance for example.  It is most likely you need 
primitives written in a lower level language that do the grunt work.  
But I wouldn't be surprised to discover that those are  easily loaded 
from the web and require no effort on your part other than understanding 
what they are in the first place. 

> what widgets or GUI tools have found for it that correspond to robotics 
> type work for GUI design... knobs, meters, and such???
>
> inquiring minds want more info...pretty please...

I honestly haven't looked for widgets yet.  I see huge lists of all 
types of Squeak code for this and that on line ready to pull into your 
application.  Also, I'm still hazy on what the web pages actually are 
that the robot will serve to the remote monitor screen and control 
panel.  Just not there yet.  I did notice that Jon Hylands, who has been 
a great mentor btw (sorry Jon to let that slip) is thinking that 
George's point about remote browser based gui's is a good idea so he'll 
probably head in that direction. 

In conclusion, after one week of Squeak, I'd say it's a mind-warp.  It's 
not a linear way of thinking.  It requires a disciplined journey to a 
different reality.  One of the first programming exercises is to go 
through the steps to make a little game.  Going through the motions 
makes a lot of sense and you're done in about 15 minutes.  You realize 
to be able to think along the lines of the original designer would 
require a different you.

==========================

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      Jon at huv.com      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog