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.

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 <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
> >
>
>
>