He got the point didn't he?
cheers!
Sebastian
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Jon Hylands Enviado el: Miércoles, 31 de Octubre de 2007 09:36 Para: squeak-dev@lists.squeakfoundation.org Asunto: Squeak from a newcomer's perspective
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@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@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog