Smalltalk - more usable by others than C++?

Recently I was looking at trying to use a C++ API from Smalltalk and ran
into various problems.  Having been down similar roads before and not
having the time, inclination, or compelling reason to overcome them I've
decided to back-burner the whole Smalltalk/C++ project for now.

In a recent ACM Queue article it is reported Bjarne Stroustrup says
there are over 3 million C/C++ programmers, and that number is growing.
I personally hope more of them are C programmers because C++'s
mangling isolates it from other languages, making its libraries and
various other artifacts more difficult to reuse by other languages in
closely-bound environments (like shared libraries).  Mangled function
names and the dependency on instances makes any OOP more difficult to
interface with since non-OOP languages don't have direct support for the
API semantics and mangled function names make things even less
straightforward.

Moments ago I was reading a posting in comp.lang.lisp about how Lisp has
few or hard-to-find bindings to OpenGL.  I started wondering how similar
Lisp and Smalltalk might be.

Now I'm pondering how Smalltalk is no better than C++ in this regard.
Smalltalk's artifacts, like other OOPs, are not readily accessible
through dynamic libraries.  In fact, I don't have any experience myself
accessing Smalltalk code inside a shared library since VW doesn't
provide that mechanism (that I'm aware of).  I think I've read Dolphin
or MT might provide that but I'm unsure.

In fact, this may be a failing of all OOP languages that each is
incapable of directly reusing the other's objects and that this obstacle
is doing programmers no favors when trying to deliver software to their
customers.  Java has overcome this barrier not by finding a way to cross
it, but by rewriting every conceivable API in Java to make those API's
native.  Instead of using an available LDAP and wrapping it there's a
Java LDAP library (that's just one of hundreds of examples).

Since OOPs don't seem able (or willing?) to speak directly to each other
we've had to create all kinds of translators between them.  SOAP and
CORBA are two that come to mind, but erecting those bridges have a far
higher expense than any of these languages have talking to C functions.

And I suppose that's the beauty of C.  Everyone can talk to it (that I
know of).  Java (with a little exercise in JNI), Smalltalk, Lisp,
Python, Ruby, Fortran, COBOL, you name it, it can talk to C.

So what makes a good C API usable?  I think GNU's Privacy Guard (GPG) is
a decent design that is easily wrapped and interfaced with using an OOP.
The API returns opaque data structures that must be passed to
functions in a manner similar to how file handles or streams are passed
to open, read, write, and close files.

If someone were to hack a mechanism for making Smalltalk code accessible
to other languages from a shared library I think a similar mechanism
could be constructed.  After initializing the library (I won't attempt
to describe how that would work) instance methods could be called by
making their first argument a handle to the instance.  The function name
would be resolved inside the scope of the instance handle to avoid
collisions.  This would resemble Python's (less than aesthetically
pleasing) "self" reference to functions.

Name mangling would still be a problem.  Even if we assume all method
parameters are positional there's still the matter of the method
signature itself.  In one of my own methods I'm unsure how pleasing the
signature from a method, "defaultTableHeadersForResult: aTupleCollection
columnList: aColumnList on: aStream" would look as a C-ish function.
void  defaultTableHeadersForResult:columnList:
on:
Though there are the same amount of characters, it seems awkward outside
its natural habitat, the Smalltalk IDE.  Not unmanageable, just awkward.
Forget for the moment C doesn't allow colons inside names.

By now some of you may be thinking I've wasted a bunch of time with this
posting but I can assure its therapeutic (for me).  It just one of my
own 12-step program of realizing how much more difficult some things are
now than they were in the 80s.  Sometimes it seems programmers have made
their jobs more difficult instead of less so.  My Pascal, Fortran, C,
Cobol and ADA could all call each others' libraries on Data General's
AOS/VS.  I could move to a new language without abandoning the assets of
the previous one.  I could increase the return on old code by migrating
some functions to newer languages.  Heck, we were even able to move into
and out of 16 and 32-bit address spaces.  Now such mobility isn't as
easily accessible.  Consider how difficult it would be moving to
Smalltalk from Java, Lisp, C#, or anything else.

All these thoughts while at the same time reading about different
languages being implemented on others' VMs.  I've read Smalltalk can't
competently be implemented using Java bytecodes but that Java could be
implemented on Smalltalk's (I may have misread that).  In the case of
the former it's unknown if such a thing is economically survivable for
vendors.

How can this be made easier?  Is someone already making it so?  Is there
a VM that will run Lisp, Smalltalk, Java, and C# while at the same time
providing straight-forward access to 3GL-written functions?

Have you taken a look at CORBA (Common Object Request Broker
Architecture)? Most of the Smalltalks I have used have had corba
interfaces if not a way to run an ORB, the ones that didn't pre-dated
the spec. Try the site http://linas.org/linux/corba.html; it has a
number of good links for more information and places to find software
for most platforms.

Thomas Gagne <tgagne@wide-open-west.com> wrote:
...
> Now I'm pondering how Smalltalk is no better than C++ in this regard.
> Smalltalk's artifacts, like other OOPs, are not readily accessible
> through dynamic libraries.  In fact, I don't have any experience myself
> accessing Smalltalk code inside a shared library since VW doesn't
> provide that mechanism (that I'm aware of).  I think I've read Dolphin
> or MT might provide that but I'm unsure.

MT specifically supports the building of DLLs which are callable from
other applications, so it is not a deficience of the language but of the
systems which derive from the original image concept.
As soon as you are willing to let the Smalltalk objects live happily and
securely in their own address space and communicate with them through
IPC mechanisms, calling image-based Smalltalk from other languages is
pretty easy. CORBA has already been mentioned, although I consider that
a little heavyweight. There are a number of other mechanisms. For
example, more than 10 years ago our company implemented SUN RPC client
and server code in Smalltalk-80. Doing this kind of stuff is actually
much easier in Smalltalk than in other languages due to its superb
reflective capabilities and other dynamic language features.

But as always, it should be considered whether your question has a
practical background or is just a theoretical consideration. Is there a
real life use case where you need to call Smalltalk from non-Smalltalk
code? If yes, what prohibits the use of such IPC technologies? Inquiring
minds want to know...

Cheers,
Hans-Martin

Thomas Gagne <tgagne@wide-open-west.com> wrote:

[snip]

>Since OOPs don't seem able (or willing?) to speak directly to each other
>we've had to create all kinds of translators between them.  SOAP and
>CORBA are two that come to mind, but erecting those bridges have a far
>higher expense than any of these languages have talking to C functions.

However, if you look at Swig, C++ libraries are easily wrappered by a
multitude of langauges.  It seems to be the de-facto standard as to how to
integrate "scripting" and higher-level languages and C++ and/or external
C/FORTRAN/ETC languages.

Swig supports the following languages:

Perl
Python
Tcl/Tk
Guile
MzScheme
Ruby
Java
C#
PHP
CHICKEN
Ocaml
Objective-C
Javascript
S#
VW Smalltalk (coming, and with others help, perhaps other dialects)

That is a pretty tall order.  Your statement "Don't seem to be able or
willing" seems a little off to me.

Swig modules also support notions of what they call "directors" whereby C++
virtual functions can be overriden by other higher-level language
implementations.  So by using C++ directors, one can build C++ classes with
virtual functions, and then implement them in the language you choose.  The
language can then compile this result into a library and you can have an
object-oriented interface (C++) implemented in different higher-level
languages, and they can all talk to each other using C++.  Directors are
currently only supported in Java, C#, and Python, I believe.  Support for
"directors" for the other languages may be in development (and is for
S#/Smalltalk).  When complete, S# (a superset of Smalltalk) would be able to
expose a C++ interface to it's behavior, in the form of a shared library or
DLL.  S# and Smalltalk MT already support exposing compiled classes/behavior
as a pure C interface.  All this is definately a "poor-mans" excuse for
something like a unified .NET VM architecture, however, calling it
nonexistant may be fairly off the mark.

If you look at big libraries like this www.wxwidgets.org, you can see that
it's a C++ library that has been integrated into probably a dozen
higher-level languages.  And this library is pretty extensive!
Many C++ libraries today are designed with for Swig integration in-mind.
Some C++ libraries come pre-built for a whole number of languages (using
Swig).  Here is one such example:  http://librdf.org/

On that note, many are looking at RDF, OWL, and OWL-S as a "data-centric"
focus to cross-systems and cross-language integration, as opposed to
behavior-centric, like SOAP and CORBA.  Still, for high-performance and
simplicity, connecting higher-level languages to C and C++ seems to be a
reasonable choice at the moment.

>And I suppose that's the beauty of C.  Everyone can talk to it (that I
>know of).  Java (with a little exercise in JNI), Smalltalk, Lisp,
>Python, Ruby, Fortran, COBOL, you name it, it can talk to C.

Or using Swig, C++.  Even using JNI to connect to a C library is fairly
painful compared to using Swig.  You could also use Swig to have FORTRAN
connect to C++.

[snip]
>If someone were to hack a mechanism for making Smalltalk code accessible
>to other languages from a shared library I think a similar mechanism
>could be constructed.  After initializing the library (I won't attempt
>to describe how that would work) instance methods could be called by
>making their first argument a handle to the instance.  The function name
>would be resolved inside the scope of the instance handle to avoid
>collisions.  This would resemble Python's (less than aesthetically
>pleasing) "self" reference to functions.
>
>Name mangling would still be a problem.  Even if we assume all method
>parameters are positional there's still the matter of the method
>signature itself.

I'm not quite sure what you're describing here, but it sounds like Swig
directors, and no, name mangling is not a problem, as this has been resolved
in the implementation.  If you want more details, read the Swig manual.

>In one of my own methods I'm unsure how pleasing the
>signature from a method, "defaultTableHeadersForResult: aTupleCollection
>columnList: aColumnList on: aStream" would look as a C-ish function.
>	void  defaultTableHeadersForResult:columnList:
on:
>Though there are the same amount of characters, it seems awkward outside
>its natural habitat, the Smalltalk IDE.  Not unmanageable, just awkward.
>   Forget for the moment C doesn't allow colons inside names.

[snip]

>How can this be made easier?  Is someone already making it so?  Is there
>a VM that will run Lisp, Smalltalk, Java, and C# while at the same time
>providing straight-forward access to 3GL-written functions?

A universal VM?  The closest things that I'm aware of to this are:

Java VM (cross-platform, yielding poor performance, widespread adoption
despite a poor implementation)
.NET VM  (windows specific, better performance, vendor lock-in)
Mono VM (cross-platform, not overly exciting performance, early stages of
development, beginnings of adoption)
AOS/Smallscript VM (excellent dynamic performance, early stages of
development and adoption)

So I may disagree with you in saying that there aren't any efforts to
integrate all these languages, but I wholeheartedly agree, that this
technology sure has miles of headroom to improve upon.

Ian

---
http://www.upright.net/ian/

Thomas Gagne escribi=F3:
> Recently I was looking at trying to use a C++ API from Smalltalk and
ran
> into various problems.  Having been down similar roads before and not
> having the time, inclination, or compelling reason to overcome them
I've
> decided to back-burner the whole Smalltalk/C++ project for now.

> [SNIP]

> By now some of you may be thinking I've wasted a bunch of time with
this
>   posting but I can assure its therapeutic (for me).  It just one of
my
> own 12-step program of realizing how much more difficult some things
are
> now than they were in the 80s.  Sometimes it seems programmers have
made
> their jobs more difficult instead of less so.  My Pascal, Fortran, C,
> Cobol and ADA could all call each others' libraries on Data General's
> AOS/VS.  I could move to a new language without abandoning the assets
of
> the previous one.  I could increase the return on old code by
migrating
> some functions to newer languages.  Heck, we were even able to move
into
> and out of 16 and 32-bit address spaces.  Now such mobility isn't as
> easily accessible.
> Consider how difficult it would be moving to
> Smalltalk from Java, Lisp, C#, or anything else.

That's probably because Smalltalk, Java, Lisp and C# live in another
plane, orthogonal to C, ADA, Pascal and Fortran. And Smalltalk's plane
isn't parallel to Java and C# neither.

> [SNIP]
> How can this be made easier?  Is someone already making it so?  Is
there
> a VM that will run Lisp, Smalltalk, Java, and C# while at the same
time
> providing straight-forward access to 3GL-written functions?

Perhaps is the plane shift what's missing, you still want to make use
of a "new"* technology from an old technology.

As an analogy, (forgive me if it doesn't fit) think in order of
"technological relevance", in a sense as people name them "1G, 3G, 4G
languages", say, in a timeline you have Pascal, C, ADA in the start;
then Java, Python, Ruby, then Lisp and Smalltalk.
As in real life, time has a direction, C and Pascal doesn't know
anything about Java or Smalltalk, because it's "in the future", the
inverse occurs with Java or Smalltalk in respect to C and Pascal, Java
and Smalltalk knows them, because C is "in the past".

The solutions to interconnect those "new systems" are complicated, is
always easier to make an API call than to make a CORBA request.
And that kind of things is what make many of us "feel" that no real
progress and advance has been made in the last 15 years.

In Dolphin you can implement COM servers, however it isn't
straightforward as an API call, but that's because there is no main()
neither in Smalltalk, and I'm happy with that.


Best regards,

--
Esteban.

Hans-Martin Mosner wrote:
<snip>
>
>
> MT specifically supports the building of DLLs which are callable from
> other applications, so it is not a deficience of the language but of the
> systems which derive from the original image concept.
> As soon as you are willing to let the Smalltalk objects live happily and
> securely in their own address space and communicate with them through
> IPC mechanisms, calling image-based Smalltalk from other languages is
> pretty easy.
<snip>

But IPC mechanisms seem to me a more complicated solution than linking
with a library.  Each has advantages.  For the purposes of linking and
distribution it's hard to compete against a shared library.  For
purposes of distributed processing loosely-coupled alternatives using
IPCs of any variety are hard to beat.

But the latter requires the involvement of 3rd party software.  Clients
and servers must be coordinated, there ports available, more software,
GUIs, and moving parts to go awry.

<snip>


> But as always, it should be considered whether your question has a
> practical background or is just a theoretical consideration. Is there a
> real life use case where you need to call Smalltalk from non-Smalltalk
> code? If yes, what prohibits the use of such IPC technologies? Inquiring
> minds want to know...

My company, like any other, has accumulated various software assets I'm
rue to reimplement in other languages.  We use C, Smalltalk, and PHP and
each does some things well.  The only one that's easily reusable is C.
Both Smalltalk and PHP can *reuse* its code.  However some things must
be solved in both Smalltalk and PHP.  Principally it violates my (and
hope everyone's) preference to reuse code.

It wouldn't hurt my feelings if more people used open-source shared
libraries written in Smalltalk.

> My company, like any other, has accumulated various
> software assets I'm rue to reimplement in other languages.
> We use C, Smalltalk, and PHP and each does some things well.

If you use Smalltalk as a "language", only a new syntax to do things,
you're missing a lot. _A LOT_.
And that miss is what doesn't help smalltalk "the technology" to
improve, many people see it as a language, not as a system with another
syntax.
Personally I don't see it as a language, its a technology, wich uses a
special syntax named "Smalltalk" (also).

> The only one that's easily reusable is C.

You reuse functions? or simply use them from many places (other
programs)?
However, that's the opposite of what i think about reusability in C,
but is just a personal opinion.

> Both Smalltalk and PHP can *reuse* its code.

What about reusing objects instead of code?
Can you see a difference between use and reuse?

> However some things must be solved in both Smalltalk and PHP.

Like...?

> Principally it violates my (and hope everyone's) preference to reuse
code.

I tend to reuse objects.

Best regards.

Ian:

Swig sounds very interesting and promising, it would have made a great
topic at  SS 2005 and sounds like a great CampSmalltalk project if not
one already.

-Charles

Esteban A. Maringolo wrote: 
>
>
> If you use Smalltalk as a "language", only a new syntax to do things,
> you're missing a lot. _A LOT_.

Good advice.  I agree.  Smalltalk is many things, but it shouldn't be an
island.

<snip>
>
> 
>
>
> You reuse functions? or simply use them from many places (other
> programs)?
> However, that's the opposite of what i think about reusability in C,
> but is just a personal opinion.

I don't understand what you mean.

>
> 
>
>
> What about reusing objects instead of code?
> Can you see a difference between use and reuse?

Reusing objects is just as problematic.  How is PHP to reuse Smalltalk
objects in a tightly-coupled environment?  How is C to reuse Smalltalk
objects in a tightly-coupled environment?  If Smalltalk is an island
then we shouldn't complain about its lack of use, lack of scripting,
lack of publicity, lack of usage, lack of profits, and lack of customers
clamoring for us to write Smalltalk for them.  Customers (ourselves
included) need to be able to migrate to new technologies, Smalltalk
among them.  If Smalltalk is an all-or-nothing choice we risk being
negligent advising our clients to bite of more than is necessary to get
the job done.
>
> 
>
>
> Like...?

Like business rules that must present themselves in both the application
server and the user interface.

>
> 
>
> code.
>
> I tend to reuse objects.

A luxury when your whole world is objects, but the expense for many to
get there is more than they can afford.  Even after writing the check
they regret the result trading a bunch of code that did work for brand
new code without a history.  More regrettable (IMO) was the choice most
of them made.

Thomas Gagne escribió:
>
>
> Esteban A. Maringolo wrote:
> 
> Good advice.  I agree.  Smalltalk is many things, but it shouldn't be an
> island.

It left the island several years ago, and went orthogonal (even
today), that explains the baloon issue ;-)

> <snip> 
> I don't understand what you mean.

Using a function from several places isn't reuse, it is use (many
times). I mean, using sprintf() from an API call in a Smalltalk
String, or Perl, or PHP doesn't mean you're reusing sprintf(), it
only means you're using it many times. Reuse is another different thing.

Having a Person class, which fits in different business domains is
more a kind of reuse. Because you build it for one purpose, and can
use it in other.
Point is a good example, basically it's a class of objects for
windowing support (I guess in the beginning it was there for that
reason), but you can use it for handle other kind of coordinates,
and even subclassify it and give it special behavior.

Reuse is more a kind of "different purpose use".

You can find more on this approach in <www.smalltalking.net>
 

Copying and pasting C code (or smalltalk code) isn't reuse.
 
> Reusing objects is just as problematic.
> How is PHP to reuse Smalltalk
> objects in a tightly-coupled environment?
> How is C to reuse Smalltalk
> objects in a tightly-coupled environment?

Build an interface, if you like. Smalltalk is floating "above",
(hence the baloon again ;-)

The effort to connect "legacy" technologies to smalltalk is always
hard. Connect a COBOL to Java, then you tell me. Do the inverse and
tell me which is easier.

Make a flat API through sockets, COM, IPC or whatever you have in
your Smalltalk.

> If Smalltalk is an island then we shouldn't complain about its
> lack of use, lack of scripting, lack of publicity,
> lack of usage, lack of profits, and lack of customers
> clamoring for us to write Smalltalk for them.

Perhahps it's an island, a tropical one, if you like.
Wouldn't you live there if you could? :-)

> Customers (ourselves  included)
> need to be able to migrate to new technologies, Smalltalk
> among them.

Many people has walked that path, and as stated before, smalltalk
can use "backward components" (C APIs, CORBA, COM, etc).

Once "in the island"... if you need to communicate your smalltalk
you cand build your own tailored solution.

WebServices proliferation, not being as straighforward, nor
perfomant as an C API call is what you have now with spread support
among many "objects" (mostly object oriented) platforms.

> If Smalltalk is an all-or-nothing choice we risk being
> negligent advising our clients to bite of more than is necessary to get
> the job done.

I agree on this, smalltalks are more an all than nothing. But it
doesn't means that you can't coexist with other alternatives.
 
> Like business rules that must present themselves in both the application
> server and the user interface.

Which is which? Smalltalk the user interface?
 
> A luxury when your whole world is objects, but the expense for many to
> get there is more than they can afford.

That's a personal decision.

> Even after writing the check they regret the result trading
> a bunch of code that did work for brand new code
> without a history.
> More regrettable (IMO) was the choice most
> of them made.

One additional note: Even considering Smalltalk a good technology
with which do effective reuse, the only _true_ reuse is the
experience, something very valuable, and hardly findable when
developers are used a "human resource" (consumed and discarded, as
any finite resource).
Software reuse is hard to develop, and requires maduration of the
software and developers, which in turn requires time to achieve. And
time is money, so my simple inference is that Software reuse
requires money. :-)

Best regards.

--
Esteban.