On Jan 31, 2008, at 7:26 PM, Philippe Marschall wrote:

> 2008/1/31, Diego Fernández <diegof79 at gmail.com>:
>> 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 <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
>>>
>>
>>
>>
>