Newsgroups: comp.lang.smalltalk,comp.lang.object,comp.lang.c++
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!xlink.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: C++ and Smalltalk Productivity
Message-ID: <1995Jan19.112824.20592@wavehh.hanse.de>
Organization: The Internet
References: <1995Jan13.184124.10801@boole.com> <NEWTNews.8706.790319161.laird@astro.zti.com>
Date: Thu, 19 Jan 95 11:28:24 GMT
Lines: 100
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:19677 comp.lang.c++:108220

laird@zti.com writes:

[...]
>We built a system that required transporting objects over a net connection. As 
>we had both C++ and Smalltalk code, and as this was several years ago, we had 
>to construct our own flattening, resurection, and net interface services. The 
>C++ code was in excess of 10,000+ lines, and we had to modify it specifically 
>for each different class of object that we wished to transport. 

[...]
>In short:
> C++        10000+ lines   2 weeks    VERY application specific.
> Smalltalk   ~400  lines   2 days     VERY (but not QUITE competely) general

[...]
>1) Object flattening and ressurection tend to favor a Smalltalk implementation, 
>since these operations typically require meta-information that C++ does not 
>have available. i.e. Flatten and Ressurect are LOTS easier when you have 
>classes as a runtme entity, rather than a syntactic entity. (It is important 
>to note that class objects make lots of other functionality easier to 
>implement as well...take network proxy behavior for example).

As you say, you have to build an application that requires
metainformation about the classes of objects at runtime. You're
comparing a language that has this functionality build in with one
that lacks such features.

Your approach to implement this in C++ was to manually add the needed
information at a per-class basis. Depending on what classes exactly
you need to build, a better solution might have been to write a little
preprocessor that edits C++ source code and adds meta-class
information and member functions to do binary and/or ASCII-Based I/O
and object construction from a stream (it seems you need the ability
to detect an object's type first and then call the needed class).

Of course, such a preprocessor needs more than two weeks to build and
there are requirements such as that the proprocessor needs to edit all
superclasses of a given class too (it would not be able to get the
needed information when seeing only the end class). Smalltalk's
solution is more elegant, of course, but a preprocessor in C++ is not
catastrophic, since this functionality could be implemented so that
the editing files would still be valid, readable C++.

My point is, that your comparsion tends to be a bit unfair. You
comapre two languages by using a library/build-in-feature in one and
adding ad-hock solutions on a per-class basis in the other. While it
is true, that the given features in today's implementations reflect
this, I still thing this doesn't say much about the two languages in
general.

>2) We did NO efficiency measurements, other than to note that in both 
>implementations the overhead associated with flattening and ressurecting 
>objects was trivialized by the remaining computation. i.e. Both implementations 
>were fast enough for our application. The C++ MIGHT have been faster, but who 
>cares?

In this case, the usual speed advantage of C++ may be narrowed. C++'s
speed advantages are a result from the ability to use low-level
types/operations and classes with inlined member function calls (when
you don't need virtual functions). You cannot use this in a
distributed application where it is not know in advantage what kind
(class) of object arrives in what order. Some Smalltalk
implementations, on the other hand, can optimize types like
integer/character even when they are integrated in a class library
with full dynamic dispatch (as they always are in Smalltalk).
Therefore, they can optimize some operations on objects that arrives
from a stream.

Of course, in projects that have chosen C++ as their implementation
language, it is likely that such a distributed application is designed
in a different way. Choosing C++ means that you don't want the
flexibility to send whatever message you want to every object, you
don't want the flexibility to feed unforseens objects to
operations. If you don't, this distributed application would in fact
been implemented so that it is know in advance what exactly arrives at
what time from the stream. Then, C++ can use low-level-types on such
streams and can do static dispatch on some member function calls,
resulting in inlined calls.

A matter of style... Both for choosing a language and how to use a
language you're forced to use. From your description, I guess you have
a 'Smalltalk-Style' like distributed application. C++ will have a hard
time to use it, resulting in more implementation time and in giving up
some of C++ advantages.

Before you flame: I too think, that distributed applications are a
field where the Smalltalk approach of working tends to be more
appropriate in many cases. Distributed applications where the above
static approach is used tends to be build for one specific task that
is implemented in a very inflexible (but save and fast) way.

For me it seems, the result is that most C++ applications that need
persistance and distribution are implemented by calling a
client/server database engine. More performance is likely to be needed
only for specialized applications and for those the inflexible
solution is best.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de> Fax +49 40 522 85 36
