Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!godot.cc.duq.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!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++ / Smalltalk
Message-ID: <1995Jan5.094541.16980@wavehh.hanse.de>
Organization: The poor LISPers' hacking kitchen
References: <3cl83v$jmq@news1.delphi.com>
Date: Thu, 5 Jan 95 09:45:41 GMT
Lines: 98

jsutherland@BIX.com (Jeff Sutherland) writes:

>>"C++ and Smalltalk are both said to be object-orientated languages.
>>Compare these two languages, including in the comparison the main features
>>of object orientated languages".
>>
>>Three weeks into the course and they throw this at me can anyone help.
>>
>>Thank you (david@royd.demon.co.uk)

>The short version of a paper in press at Object Magazine is that C++ is a
>hybrid language, meaning valid C code runs in C++.  This means that you can
>write a C++ program with no objects.  This is not true in Smalltalk where
>everything is an object (although you can still write bad "procedural"
>Smalltalk code).

I don't want to comment on whether C++ sucks or Smalltalk is a toy,
but I wouldn't see C++ as a 'hybrid language'.

C++'s OO features are integrated with the C type system and other
semantics in a way that the result is one tight language. C++ enforces
a hybrid programming style, though.

The counterexample is Objective-C, which I would call a hybrid
language. It has different semantics for Objects and the old C stuff.

Whether it is possible to write non-OO programs in a language doesn't
say anything about it's quality or even OOnes.

>Second, C was created to be a better assembler and C++ was created to be a
>better C, ergo C++ is object assembler.  Assembly languages have pointers
>and force the program to manage memory, and allow the programmer to
>overwrite his own data in memory, cause memory leaks, etc.

Whether the programmer is responsible for and has control over the
memory layout doesn't say anything about it's OOnes, too. Especially
this doesn't break encapsulation, just because you *can* break into a
object. The point is, C++ way of programming doesn't include to break
encapsulation by using pointers. It is certainly easier to break
encapsulation in C++, though, especially by casting.

>Smalltalk is an application language.  You don't need to understand
>pointers and memory is managed for you.  COBOL programmers can easily learn
>Smalltalk but not C++.

See above. C++'s way of programming needs control over the memory
layout. Of course you shouldn't use C++ if you don't like it's style
(which includes memory control).

BTW, a programmer who doesn't understand pointers will have problems
sooner or later anyway. At least he will not have an idea how to write
efficient programs in any language.

>We write our internals for our Smalltalk compiler in C++ and have  other
>4GL products now being written in C++.  The rule of thumb we use for
>project estimation is six to one.  So C++ runs faster but six times later. 

Using the right or a wrong language for a given task will cause such
differences every time, of course. The questions is, how much areas
are there where C++ or Smalltalk is the right language. Would you
implement your Smalltalk compiler using Visualworks or xlisp?

>Lot's more can be said.

To return to the original author's question, C++ follows its own way
of OO programming and does it well. As said, I don't even count C++
under 'hybrid' languages. His and his teacher's comparison depends on
their definition of OO programming, and that is more likely to be
Smalltalk's than C++'s. I am curious how this assignment will be
judged when the opinions differ between teacher and author.

The one and only bad thing about C++ is that programmers very often
are forced to use it in areas und under circumstances where it is not
the right language. But that is a matter of stupid ties and there's
nothing C++ can do about it.

To really evaluate how useful languages are, he will have to find out
what style of programming a given language will enforce, then evaluate
if the language's semantics allows the programmer to make full use of
that style (and some other requirements, like quality of
implementations).

Finally, the decision is not between languages, but between a given
set of styles, how they fit a programmers mind and the problem he is
going to solve (or to be fired for... :-]    ).

You may be interested in a posting of mine about Objective-C and C++
some days ago in comp.object, where I give some examples of different
ways to solve some kinds of problems in Smalltalk/Objective-C and
C++. I'll mail it to you cannot access it.

P.S. If you want my comments exactly where I find what language to be
most useful, please send personal mail. But don't expect a clear
decision for or against one specific language :-)

And excuse me for for bad english...
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de> Fax +49 40 522 85 36
