Promoting Squeak/Smalltalk

> I have been wondering how to make smalltalk a more "popular"  
> language, because i think it is excellent, and i think it would be  
> good to try to get other people to use it, because, i don't notice  
> to many younger programmers, like myself, using smalltalk, though, i  
> may be wrong.  One of the first thing i would think of to promote  
> smalltalk would be writing programs in smalltalk instead of just  
> making smalltalk better, i am not trying to discourage improvement  
> on smalltalk, but if all you are developing is a language for people  
> to continue to develop a language in, it seems like a waste of  
> time.  The only program I know about, as in big, large scale  
> programs, written in smalltalk is PetroVR, i may be wrong there to,  
> but i see smalltalk as an excellent development environment and  
> language, but, nothing big is written in it, and it will never grow  
> if the community is focused entirely on making smalltalk better.  I  
> might be completely wrong, but that is what i have seen, but, i have  
> only really payed attention for a couple of months, and i think it  
> would be good to see some growth in smalltalk's popularity. :)
>

>
>
> On Jan 29, 2008 6:51 PM, Colin Putney <[hidden email]> wrote:
>
> On 29-Jan-08, at 3:42 PM, Joshua Gargus wrote:
>
> > The benefits of popularity seem clear.  There would be more smart
> > people with more spare time to contribute good ideas and code.
> > There would be more jobs and a better chance of making a living
> > using the language.  The second benefit would feed into the first,
> > and vice-versa.
>
> Well, I agree that smart people contributing to the community would be
> a good thing. But popularity doesn't necessarily imply smart people,
> it just means *more* people. I think the community we have today is
> actually quite good. The "unpopularity" of Smalltalk acts as a filter.
> To be a Smalltalker you've got to be smart enough to recognize the
> benefits, confident enough to leave the mainstream, and resourceful
> enough to overcome the obstacles that working in an "unpopular"
> language entails. If Smalltalk were more popular, I doubt we would
> actually get all that many more "smart people" than we have now.
>
> Now, making a living using the language. Popularity would probably
> bring more jobs, but it would also bring more programmers to compete
> for those jobs. It would probably also lower the average salary of
> Smalltalk jobs. That might or might not be a good thing.
>
> > The question is whether the benefits outweigh the costs.  Since the
> > benefits seem obvious to me, I'll assume that you're really
> > expressing skepticism about whether the benefits outweigh the
> > costs.  What do you think the costs are? (I can think of a few, but
> > I'm curious about what others think)
>
>
> I guess there are two costs. One is the effort and sacrifices required
> to make Smalltalk popular. For example, we might try creating a Ruby-
> on-Rails clone in Smalltalk, in order to take advantage of the current
> vogue in web apps. That would be a fair amount of work, presumably
> done by people who might otherwise be working on things that benefit
> the existing community. Or perhaps Seaside could be "dumbed down" so
> it could be marketed to the kind of developer that doesn't like the
> "magic" of continuations. That makes Seaside worse for the rest of us.
>
> The other cost is all the noise that would get introduced into the
> community. Sure, Java has more libraries than Smalltalk, but most of
> them are just crap. All they do is make it harder to find the good
> stuff, and diffuse the energy of the community.
>
> In general, I think we'd be better to focus not on popularity, but on
> community. Yes, a certain size is required for the community to
> function well, but beyond that there are diminishing returns from
> further growth. As long as the VM gets maintained, libraries written,
> bugs fixed, questions answered, newbies encouraged - as long as the
> community is functioning - Smalltalk is sufficiently popular.
>
> Colin
>
>
>

> Hi,
>
> On Jan 29, 2008 11:45 PM, David Zmick <[hidden email]> wrote:
>> I have been wondering how to make smalltalk a more "popular"  
>> language,
>
> I can find different options:
>
> - distribute flyers (http://damien.cassou.free.fr/)
> - present Smalltalk/Squeak/Seaside
> (https://svn.squeak.org/Advertisement/presentations/squeak_jm2l_en/)
> - help people working on the Smalltalk entry point (the dev-images,
> the documentation...)
> - live on #squeak irc and answer questions
> - develop programs with Smalltalk/Seaside and advertise
>
> --
> Damien Cassou
>
>

> - If you choose an Smalltalk, you can't migrate easily to another one.
>
> The "core" framework is more or less the same for all Smalltalks  
> (collections, streams, exceptions, SUnit).
> But when you start using another things like networking, databases,  
> UI... porting from one Smalltalk to another still requires a lot of  
> work.
>
> Another issue on porting are tools for  "source code packages". For  
> example the code of Aconcagua (the unit framework created at  
> Mercap), is very portable: it was created on VisualAge, and them  
> ported to work on GemStone, Squeak and VisualWorks.
> Camp Smalltalk Rosseta was used to port the initial version from  
> VAST to Squeak and VW, but the required work was not trivial, and  
> maintaing "source code packages" for each Smalltalk flavor is really  
> tedious.
>
> I know that there is a Monticello package loader con VW Public  
> Store, but having an open source package format with multiple  
> smalltalks in mind would be nice. (Even more nice would be having an  
> open source multi smalltalk versioning system... imagine how nice  
> would be if SqueakSource packages, and VW Public Store packages are  
> accessible from the same public repository and versioning system).
>
> - The integration with other tools could be really difficult
>
> In VisualWorks you have  tools to integrate an smalltalk application  
> with the rest of the enterprise: webservices, ActiveX, JNIport.
> But in Squeak, no :(
> The webservices package seems to be unmaintained, and you have a  
> great FFI support, but compared to Ruby or Python, the communication  
> with systems in Java or C# requires a lot of work.
> For example, a lot of enterprises  (Banks, travel agencies, etc)  
> uses JavaEE for the middle tier. But there this is a potential  
> market for Seaside in the web tier: the framework is superior and  
> more flexible than JSP, Ruby On Rails or PHP.  But is not easy to  
> communicate your Seaside front end to the Java/C# backend. You can  
> use and ad-hoc HTTP or plain socket messages, or buy a license of VW  
> and use WebServices or RMI. But the immediate cost of this compared  
> to just develop the web application in Java or JRuby, is difficult  
> to justify.
>
> Also integration from other applications to Smalltalk is difficult  
> (a nice thing of GNU Smalltalk is that you could use the VM as a  
> library in C -the people in VW is working in something similar, and  
> I think that St/X also have something like this).
> Thanks to this Python became more popular: Python is used as  
> scripting language in a lot of games because is really easy to  
> integrate from  C/C++. (for example in Linux you could make an  
> filesystem driver using Python and FUSE!)
>
>
> Well that are to me aspects that we as developers can resolve, and  
> can have impact on the whole community: with better integration with  
> other systems, an small consultant could sell a Seaside based  
> solution more easily. With tools to work on multiple smalltalks I  
> think it would be less duplicated work, and more shared packages  
> between smalltalk implementations.
>
>
>
> On Jan 30, 2008, at 4:16 AM, Damien Cassou wrote:
>
>> Hi,
>>
>> On Jan 29, 2008 11:45 PM, David Zmick <[hidden email]> wrote:
>>> I have been wondering how to make smalltalk a more "popular"  
>>> language,
>>
>> I can find different options:
>>
>> - distribute flyers (http://damien.cassou.free.fr/)
>> - present Smalltalk/Squeak/Seaside
>> (https://svn.squeak.org/Advertisement/presentations/squeak_jm2l_en/)
>> - help people working on the Smalltalk entry point (the dev-images,
>> the documentation...)
>> - live on #squeak irc and answer questions
>> - develop programs with Smalltalk/Seaside and advertise
>>
>> --
>> Damien Cassou
>>
>
>
>

> Somebody should work on that nd I uderstand your point.
>
> On Jan 30, 2008, at 12:31 AM, Robert F. Scheer wrote:
>
>> I've only been using Squeak a very short time (for robot main program)
>> and would like to continue, however a rather serious limitation for
>> robotics is computer vision and numerical methods used for things like
>> Kalman and particle filters.  Python, for example, has PIL (Python
>> Imaging Library), numPy (numerical methods) and sciPy (scientific
>> methods), among others.
>>
>> http://www.pythonware.com/products/pil/
>> http://www.scipy.org/
>> http://numpy.scipy.org/
>>
>> These libraries greatly enhance Python for use in technology fields.
>>
>> I'm too much a novice to venture any opinions on how this point of
>> distinction should or could be considered by the Smalltalk community,
>> but it's definitely something that will affect me personally and must
>> similarly affect others working on robots, electronic instruments,
>> scientific experiments and so forth.
>>
>> - Robert
>>
>> On Tue, 2008-01-29 at 16:45 -0600, David Zmick wrote:
>>> I have been wondering how to make smalltalk a more "popular" language,
>>> because i think it is excellent, and i think it would be good to try
>>> to get other people to use it, because, i don't notice to many younger
>>> programmers, like myself, using smalltalk, though, i may be wrong.
>>> One of the first thing i would think of to promote smalltalk would be
>>> writing programs in smalltalk instead of just making smalltalk better,
>>> i am not trying to discourage improvement on smalltalk, but if all you
>>> are developing is a language for people to continue to develop a
>>> language in, it seems like a waste of time.  The only program I know
>>> about, as in big, large scale programs, written in smalltalk is
>>> PetroVR, i may be wrong there to, but i see smalltalk as an excellent
>>> development environment and language, but, nothing big is written in
>>> it, and it will never grow if the community is focused entirely on
>>> making smalltalk better.  I might be completely wrong, but that is
>>> what i have seen, but, i have only really payed attention for a couple
>>> of months, and i think it would be good to see some growth in
>>> smalltalk's popularity. :)
>>
>>
>>
>
>
>
>

> 2008/1/31, Diego Fernández <[hidden email]>:
>> To me one of the issues that we have to attack to make Smalltalk more
>> popular in the business arena is: isolation.
>>
>> I mean, currently Smalltalk developments are "isolated" in two ways:
>>
>> - If you choose an Smalltalk, you can't migrate easily to another  
>> one.
>>
>> The "core" framework is more or less the same for all Smalltalks
>> (collections, streams, exceptions, SUnit).
>
> That's not my experience from working on Seaside. At the end of the
> day we had to define our own string conversion methods, everything
> else would not fly. We probably will also have to the same for number
> conversions. Strings beyond ASCII are inherently unportable, this of
> course includes conversion from bytes to Strings. There is a subset of
> collections that is portable, it's just unclear what it is. And this
> is only the case if you don't target GemStone, then you might actually
> want specialized collections. Then there are also the places where you
> have to work around bugs in the Squeak weak array finalization and
> closure implementation. The same goes for exceptions and streams and a
> lot of other things like chronology and object initialization and
> other stuff that I consider "core". All IO in inherently unportable. A
> lot of reflection is unportable. And worst thing is there is now way
> of telling whether or not your code is portable

>
> To sum it up: writing portable Smalltalk code is not trivial. Years
> have been invested into increasing the portability of Seaside and
> there still is a very long way to go.
>
>> But when you start using another things like networking, databases,
>> UI... porting from one Smalltalk to another still requires a lot of
>> work.
>>
>> Another issue on porting are tools for  "source code packages". For
>> example the code of Aconcagua (the unit framework created at Mercap),
>> is very portable: it was created on VisualAge, and them ported to  
>> work
>> on GemStone, Squeak and VisualWorks.
>> Camp Smalltalk Rosseta was used to port the initial version from VAST
>> to Squeak and VW, but the required work was not trivial, and  
>> maintaing
>> "source code packages" for each Smalltalk flavor is really tedious.
>>
>> I know that there is a Monticello package loader con VW Public Store,
>> but having an open source package format with multiple smalltalks in
>> mind would be nice. (Even more nice would be having an open source
>> multi smalltalk versioning system... imagine how nice would be if
>> SqueakSource packages, and VW Public Store packages are accessible
>> from the same public repository and versioning system).
>>
>> - The integration with other tools could be really difficult
>>
>> In VisualWorks you have  tools to integrate an smalltalk application
>> with the rest of the enterprise: webservices, ActiveX, JNIport.
>
> Do you mean webservices or WS-*? WS-* interoperability is a problem
> with every implementation. But that has to do with WS-*. What in
> general is a problem with Smalltalk is calling Smalltalk from C (from
> a non-Smalltalk thread). I don't know if the callback patches from
> Andreas fix this.
>

> Cheers
> Philippe
>
>> But in Squeak, no :(
>> The webservices package seems to be unmaintained, and you have a  
>> great
>> FFI support, but compared to Ruby or Python, the communication with
>> systems in Java or C# requires a lot of work.
>> For example, a lot of enterprises  (Banks, travel agencies, etc) uses
>> JavaEE for the middle tier. But there this is a potential market for
>> Seaside in the web tier: the framework is superior and more flexible
>> than JSP, Ruby On Rails or PHP.  But is not easy to communicate your
>> Seaside front end to the Java/C# backend. You can use and ad-hoc HTTP
>> or plain socket messages, or buy a license of VW and use WebServices
>> or RMI. But the immediate cost of this compared to just develop the
>> web application in Java or JRuby, is difficult to justify.
>>
>> Also integration from other applications to Smalltalk is difficult (a
>> nice thing of GNU Smalltalk is that you could use the VM as a library
>> in C -the people in VW is working in something similar, and I think
>> that St/X also have something like this).
>> Thanks to this Python became more popular: Python is used as  
>> scripting
>> language in a lot of games because is really easy to integrate  
>> from  C/
>> C++. (for example in Linux you could make an filesystem driver using
>> Python and FUSE!)
>>
>>
>> Well that are to me aspects that we as developers can resolve, and  
>> can
>> have impact on the whole community: with better integration with  
>> other
>> systems, an small consultant could sell a Seaside based solution more
>> easily. With tools to work on multiple smalltalks I think it would be
>> less duplicated work, and more shared packages between smalltalk
>> implementations.
>>
>>
>>
>> On Jan 30, 2008, at 4:16 AM, Damien Cassou wrote:
>>
>>> Hi,
>>>
>>> On Jan 29, 2008 11:45 PM, David Zmick <[hidden email]> wrote:
>>>> I have been wondering how to make smalltalk a more "popular"
>>>> language,
>>>
>>> I can find different options:
>>>
>>> - distribute flyers (http://damien.cassou.free.fr/)
>>> - present Smalltalk/Squeak/Seaside
>>> (https://svn.squeak.org/Advertisement/presentations/squeak_jm2l_en/)
>>> - help people working on the Smalltalk entry point (the dev-images,
>>> the documentation...)
>>> - live on #squeak irc and answer questions
>>> - develop programs with Smalltalk/Seaside and advertise
>>>
>>> --
>>> Damien Cassou
>>>
>>
>>
>>
>

> I agree
> Now we need people helping on that.
>
>
>> - If you choose an Smalltalk, you can't migrate easily to another  
>> one.
>>
>> The "core" framework is more or less the same for all Smalltalks  
>> (collections, streams, exceptions, SUnit).
>> But when you start using another things like networking, databases,  
>> UI... porting from one Smalltalk to another still requires a lot of  
>> work.
>>
>> Another issue on porting are tools for  "source code packages". For  
>> example the code of Aconcagua (the unit framework created at  
>> Mercap), is very portable: it was created on VisualAge, and them  
>> ported to work on GemStone, Squeak and VisualWorks.
>> Camp Smalltalk Rosseta was used to port the initial version from  
>> VAST to Squeak and VW, but the required work was not trivial, and  
>> maintaing "source code packages" for each Smalltalk flavor is  
>> really tedious.
>>
>> I know that there is a Monticello package loader con VW Public  
>> Store, but having an open source package format with multiple  
>> smalltalks in mind would be nice. (Even more nice would be having  
>> an open source multi smalltalk versioning system... imagine how  
>> nice would be if SqueakSource packages, and VW Public Store  
>> packages are accessible from the same public repository and  
>> versioning system).
>>
>> - The integration with other tools could be really difficult
>>
>> In VisualWorks you have  tools to integrate an smalltalk  
>> application with the rest of the enterprise: webservices, ActiveX,  
>> JNIport.
>> But in Squeak, no :(
>> The webservices package seems to be unmaintained, and you have a  
>> great FFI support, but compared to Ruby or Python, the  
>> communication with systems in Java or C# requires a lot of work.
>> For example, a lot of enterprises  (Banks, travel agencies, etc)  
>> uses JavaEE for the middle tier. But there this is a potential  
>> market for Seaside in the web tier: the framework is superior and  
>> more flexible than JSP, Ruby On Rails or PHP.  But is not easy to  
>> communicate your Seaside front end to the Java/C# backend. You can  
>> use and ad-hoc HTTP or plain socket messages, or buy a license of  
>> VW and use WebServices or RMI. But the immediate cost of this  
>> compared to just develop the web application in Java or JRuby, is  
>> difficult to justify.
>>
>> Also integration from other applications to Smalltalk is difficult  
>> (a nice thing of GNU Smalltalk is that you could use the VM as a  
>> library in C -the people in VW is working in something similar, and  
>> I think that St/X also have something like this).
>> Thanks to this Python became more popular: Python is used as  
>> scripting language in a lot of games because is really easy to  
>> integrate from  C/C++. (for example in Linux you could make an  
>> filesystem driver using Python and FUSE!)
>>
>>
>> Well that are to me aspects that we as developers can resolve, and  
>> can have impact on the whole community: with better integration  
>> with other systems, an small consultant could sell a Seaside based  
>> solution more easily. With tools to work on multiple smalltalks I  
>> think it would be less duplicated work, and more shared packages  
>> between smalltalk implementations.
>>
>>
>>
>> On Jan 30, 2008, at 4:16 AM, Damien Cassou wrote:
>>
>>> Hi,
>>>
>>> On Jan 29, 2008 11:45 PM, David Zmick <[hidden email]> wrote:
>>>> I have been wondering how to make smalltalk a more "popular"  
>>>> language,
>>>
>>> I can find different options:
>>>
>>> - distribute flyers (http://damien.cassou.free.fr/)
>>> - present Smalltalk/Squeak/Seaside
>>> (https://svn.squeak.org/Advertisement/presentations/squeak_jm2l_en/)
>>> - help people working on the Smalltalk entry point (the dev-images,
>>> the documentation...)
>>> - live on #squeak irc and answer questions
>>> - develop programs with Smalltalk/Seaside and advertise
>>>
>>> --
>>> Damien Cassou
>>>
>>
>>
>>
>
>

>
> On Jan 31, 2008, at 7:26 PM, Philippe Marschall wrote:
>
>> 2008/1/31, Diego Fernández <[hidden email]>:
>>> To me one of the issues that we have to attack to make Smalltalk more
>>> popular in the business arena is: isolation.
>>>
>>> I mean, currently Smalltalk developments are "isolated" in two ways:
>>>
>>> - If you choose an Smalltalk, you can't migrate easily to another one.
>>>
>>> The "core" framework is more or less the same for all Smalltalks
>>> (collections, streams, exceptions, SUnit).
>>
>> That's not my experience from working on Seaside. At the end of the
>> day we had to define our own string conversion methods, everything
>> else would not fly. We probably will also have to the same for number
>> conversions. Strings beyond ASCII are inherently unportable, this of
>> course includes conversion from bytes to Strings. There is a subset of
>> collections that is portable, it's just unclear what it is. And this
>> is only the case if you don't target GemStone, then you might actually
>> want specialized collections. Then there are also the places where you
>> have to work around bugs in the Squeak weak array finalization and
>> closure implementation. The same goes for exceptions and streams and a
>> lot of other things like chronology and object initialization and
>> other stuff that I consider "core". All IO in inherently unportable. A
>> lot of reflection is unportable. And worst thing is there is now way
>> of telling whether or not your code is portable
>
> Well my experience was  the same. :)
> Not in Seaside, but writing code that works on VAST and GemStone.
> When I was at Mercap we have worked on the same things that you mention:
> strings, collections, IO, and also exceptions (GemStone has another
> exception mechanism). We don't have problems with String conversion, but
> with exceptions and numbers (scaled decimals and fractions).
>
> At Smalltalks 2007 in Buenos Aires, I saw a video introducing the
> "resurrection" of the ansi smalltalk effort.
> There is any link to read more? I only found this:
> http://smalltalk.gnu.org/wiki/ansi-smalltalk-home-page
>
>
>>
>> To sum it up: writing portable Smalltalk code is not trivial. Years
>> have been invested into increasing the portability of Seaside and
>> there still is a very long way to go.
>>
>>> But when you start using another things like networking, databases,
>>> UI... porting from one Smalltalk to another still requires a lot of
>>> work.
>>>
>>> Another issue on porting are tools for  "source code packages". For
>>> example the code of Aconcagua (the unit framework created at Mercap),
>>> is very portable: it was created on VisualAge, and them ported to work
>>> on GemStone, Squeak and VisualWorks.
>>> Camp Smalltalk Rosseta was used to port the initial version from VAST
>>> to Squeak and VW, but the required work was not trivial, and maintaing
>>> "source code packages" for each Smalltalk flavor is really tedious.
>>>
>>> I know that there is a Monticello package loader con VW Public Store,
>>> but having an open source package format with multiple smalltalks in
>>> mind would be nice. (Even more nice would be having an open source
>>> multi smalltalk versioning system... imagine how nice would be if
>>> SqueakSource packages, and VW Public Store packages are accessible
>>> from the same public repository and versioning system).
>>>
>>> - The integration with other tools could be really difficult
>>>
>>> In VisualWorks you have  tools to integrate an smalltalk application
>>> with the rest of the enterprise: webservices, ActiveX, JNIport.
>>
>> Do you mean webservices or WS-*? WS-* interoperability is a problem
>> with every implementation. But that has to do with WS-*. What in
>> general is a problem with Smalltalk is calling Smalltalk from C (from
>> a non-Smalltalk thread). I don't know if the callback patches from
>> Andreas fix this.
>>
>
> Sorry I don't know what is the difference between "webservices" and
> "WS-*", could you explain me more?
> I have created "webservices" (using WSDL and SOAP) clients and servers
> using VAST and VW.
> The experience with VW was nice (compared with the complexity of VAST).
> But  all my work was on VAST, I only used VW to check the
> interoperability and to do some experiments.
> And yes I had some interoperability problems :( (working with WSDL and
> SOAP is a pain in the... well you know), but in the end I workaround
> that problems using coarse interfaces and simple data types (for example
> SOAP arrays never worked to me so I have to declare a sequence and
> implement it).
>
> I wrote that in my previous mail because every time that I talk with
> friends of mine working with Java, they are always trying new web
> frameworks (tapestry, wicket, struts, etc), to leverage the pain that is
> to develop with Servlets. So I think that if there is a good way to call
> Java EJBs from Squeak, they would be attracted to replace the web front
> end with Seaside. (but this is my conclusion, based on some
> conversations with friends and my assumptions, maybe the people at
> Cincom have analyzed the market and have another conclusions).
>
> Cheers,
> Diego
>
>
>> Cheers
>> Philippe
>>
>>> But in Squeak, no :(
>>> The webservices package seems to be unmaintained, and you have a great
>>> FFI support, but compared to Ruby or Python, the communication with
>>> systems in Java or C# requires a lot of work.
>>> For example, a lot of enterprises  (Banks, travel agencies, etc) uses
>>> JavaEE for the middle tier. But there this is a potential market for
>>> Seaside in the web tier: the framework is superior and more flexible
>>> than JSP, Ruby On Rails or PHP.  But is not easy to communicate your
>>> Seaside front end to the Java/C# backend. You can use and ad-hoc HTTP
>>> or plain socket messages, or buy a license of VW and use WebServices
>>> or RMI. But the immediate cost of this compared to just develop the
>>> web application in Java or JRuby, is difficult to justify.
>>>
>>> Also integration from other applications to Smalltalk is difficult (a
>>> nice thing of GNU Smalltalk is that you could use the VM as a library
>>> in C -the people in VW is working in something similar, and I think
>>> that St/X also have something like this).
>>> Thanks to this Python became more popular: Python is used as scripting
>>> language in a lot of games because is really easy to integrate from  C/
>>> C++. (for example in Linux you could make an filesystem driver using
>>> Python and FUSE!)
>>>
>>>
>>> Well that are to me aspects that we as developers can resolve, and can
>>> have impact on the whole community: with better integration with other
>>> systems, an small consultant could sell a Seaside based solution more
>>> easily. With tools to work on multiple smalltalks I think it would be
>>> less duplicated work, and more shared packages between smalltalk
>>> implementations.
>>>
>>>
>>>
>>> On Jan 30, 2008, at 4:16 AM, Damien Cassou wrote:
>>>
>>>> Hi,
>>>>
>>>> On Jan 29, 2008 11:45 PM, David Zmick <[hidden email]> wrote:
>>>>> I have been wondering how to make smalltalk a more "popular"
>>>>> language,
>>>>
>>>> I can find different options:
>>>>
>>>> - distribute flyers (http://damien.cassou.free.fr/)
>>>> - present Smalltalk/Squeak/Seaside
>>>> (https://svn.squeak.org/Advertisement/presentations/squeak_jm2l_en/)
>>>> - help people working on the Smalltalk entry point (the dev-images,
>>>> the documentation...)
>>>> - live on #squeak irc and answer questions
>>>> - develop programs with Smalltalk/Seaside and advertise
>>>>
>>>> --
>>>> Damien Cassou
>>>>
>>>
>>>
>>>
>>
>
>
>

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> stephane ducasse
> Sent: 31 January 2008 9:33 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Promoting Squeak/Smalltalk
>
>
> can you tell us more :)
>
> Stef
>
>
> On Jan 30, 2008, at 4:38 PM, Gary Chambers wrote:
>
> > Well, despite what has been said here we at Pinesoft are  
> > (successfully)
> > devloping commercial applications with Squeak
>

> I've only been using Squeak a very short time (for robot main program)
> and would like to continue, however a rather serious limitation for
> robotics is computer vision and numerical methods used for things like
> Kalman and particle filters.  Python, for example, has PIL (Python
> Imaging Library), numPy (numerical methods) and sciPy (scientific
> methods), among others.
>
> http://www.pythonware.com/products/pil/
> http://www.scipy.org/
> http://numpy.scipy.org/
>
> These libraries greatly enhance Python for use in technology fields.
>
> I'm too much a novice to venture any opinions on how this point of
> distinction should or could be considered by the Smalltalk community,
> but it's definitely something that will affect me personally and must
> similarly affect others working on robots, electronic instruments,
> scientific experiments and so forth.