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 <dz0004455 at gmail.com> 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
>>
>
>
>