What are the differences between C++ and smalltalk? 
Author Message
 What are the differences between C++ and smalltalk?

Roland:

What follows is something I picked up somewhere - it compares Smalltalk and C++.
 If you look carefully, you will actually see that it compares Smalltalk and
C++ TO Smalltalk!  Obviously, Smalltalk wins!

Gareth Patterson

Object Oriented Language Comparison
Smalltalk and C++
May 16, 1994 - Douglas R. Krueger

This document is a compilation of the opinions and suggestions expressed by the sources
surveyed, when asked about the pros and cons of using  Smalltalk and C++ in a
commercial environment. The survey was not conducted in a scientific manner
and is not an exhaustive treatment of the subject.  Its purpose is to
stimulate discussion and identify topics warranting further investigation.  
The items in this document have been compiled from many sources across EDS,
including our own experiences, other consulting firms, language vendors,
CompuServe object language forums, and the Colorado University Computer
Department.

Smalltalk   (all vendor compilers)
Platforms: Windows 3.x, OS/2, Macintosh, UNIX

Smalltalk Pros
Smalltalk is a mature language, developed over the last 30 years
Four major vendors offer compilers for Smalltalk, most recently, IBM who
includes a full graphical Parts environment that competes directly with
Digitalk's products. Clearly, IBM foresees a profitable market in Smalltalk.
Sources say IBM is positioning Smalltalk to be the next COBOLPure OOP -
Everything in environment is an object. This means the mechanism of accessing
one entities' behavior is the same for all entities in the environment and all
entities are available for customization, and subclassing.

Weak typing - Greatly improves polymorphism and reduces prototyping and
implementation time. For example, a relational database key for CUSTOMER is
defined as numeric. After testing, for instance, the key needed to be changed
to alphanumeric. In C++, every place the key is used and passed would have to
be re-typed from numeric to alphanumeric. In Smalltalk there would be no
changes to the code other than any user edit checking rules.

Real-time compiler eliminates the compile and link steps.   For example, a
developer can open any text window and enter some code they are working on (in
a prototypical manner) and run it right there, optionally hopping into and out
of inspectors and de{*filter*}s in the process. Before long, those few lines of
code are refined and are copy/pasted into a new or existing method used in
production code.

Powerful real-time inspectors and de{*filter*}s, are intuitive, and easy to use.  
Developers can make code changes within the de{*filter*} and simply 'restart' the
failed code by pressing the 'restart' button.

Windows developers do not require knowledge about the Windows API, allowing
the developers to focus on the business solutions rather than the operating
system. Smalltalk is a set of controls that developers can use across multiple
platforms with equal productivity.

Full multiprocessing (emulated since PCs are single CPU) is a major feature
and benefit that has been used on the QueryTool project very successfully.  It
has a fully controllable priority scheme.

Smalltalk licenses doubled between 1992 and 1993. It is predicted to double
again in 1994.Smalltalk is rapidly becoming not only source portable, but also
binary portable (both Digitalk and IBM)There are numerous 3rd party class
libraries.  IBM has publicly announced their encouragement of an extensive 3rd
party market.EDS has recommended Smalltalk for GUI applications in the EDS
Technology Policy Guide.EDS corporate training in Smalltalk is being sought
due to the high demand.

Smalltalk Cons
Execution time is slower than C++. Some estimates indicate that C++ is 2 to 5
times faster, however implementing garbage collection and strong-typing
work-arounds in C++ can significantly reduce the performance edge. Another
mitigating factor is that workstation performance increases by a factor of 5
every year.

Pure OOP forces the Object Oriented paradigm.  Institutionalizing OO requires
a well thought out development process, Analysis and Design methodology and
training program.

Large foot print.  This problem may be solved by a  feature in the 32 bit
version we have received.  This allows the hierarchy to be divided into a
series of DLLs.

Cannot be used for back-end processing.  This is refuted by at least two
contacts that have done it.

Run-time errors can occur if not all the objects that can be sent a message,
implement that message.  An example of  this is  "aSpreadSheetDocument print".
 This means that a spread sheet  document was inadvertently sent the "print"
message from which "print" is not implemented.  In C++ the receiver type (or
class) is hard-coded.  A compiler error occurs if that class doesn't have the
"print" method implemented for it, however this limits design flexibility and
minimizes polymorphic opportunities.  There have been few errors due this
problem and those that did exist should have been caught by testing.

C++   (all vendor compilers)
Platforms:
Windows: (MS, Borland, Watcom), Mac: (Think C), UNIX: (native on all UNIX
platforms, gnu)

C++ Pros
Most widely used OO language in the industry Many 3rd party class libraries
available Gives Object Oriented qualities to CFaster than Smalltalk at
execution time.Many C programmers available that could be trained in OO and
C++ extensions. Some say that prior experience with COBOL is better than C.

C++ Cons
Inherently flawed as an Object Oriented programming language because the
object portion is an add-on; most often viewed as a better C.  

Implementations are highly variable across vendors.  For example templates and
run-time exception handling are implemented differently by different
compilers. Templates are not implemented at all by some vendors.

Not all entities in the environment are objects (e.g. Important ones like
Class, Integer and Float).  This means their behavior cannot be altered,
enhanced or subclassed.  This feature in Smalltalk was used in the QueryTool
to make the SQL generation polymorphic for any object that could be used in
SQL.

C++ is strong-typed.  This means that every memory location in the system must
be defined with a hard data type (Char, Int ...).  This immediately limits the
usefulness of the code in prototyping because it can't be anything other than
what it was originally intended to be. This means there is a longer
maintenance cycle during reiterative prototyping.  It is a disincentive to
good design due to the protracted cycle time.  It also requires a lower level
and a more lengthy design process.  The designer must know, down to the most
finite detail how the design will fit together instead of staying at a higher
level of abstraction.  This is exemplified in Smalltalk, where any variable
can contain any type of object - what a convenience.

C++ greatly limits polymorphism (and consequently,  reuse and flexibility)
because it is strongly-typed.  For example, word processing documents and
spread sheets cannot be put into a list box (without making them subclasses of
a common virtual class) because they are different types and the listbox can
hold only one type (or class) of object.

The sacrosanct principle of Object Oriented systems called Encapsulation is
violated because the sender has to know what kind of object the receiver is.  
This adds complexity to the sender; increasing maintenance time.  If a new
receiver were to be added to the listbox from which the user could ask to
'print', say a drawing, the sender of 'print' would need to be changed to make
the accommodation, incurring maintenance again.

C++ does not come with memory management. Memory needs to be allocated for
every new object that is instantiated. The problem here is knowing when can
that memory be deallocated ?  For example if methodA creates Object1 and
passes the pointer to methodB, and C, who both optionally pass it to methodD,
which method can do the deallocation ?  Ideally, when the last reference to
the object1 is dropped, then the memory held by object1 can be deallocated.
However, reference-count memory manager architectures can significantly cut
into performance. This architecture is also flawed because of the "Circular
Structures" phenomenon, in which the reference to the reference (etc...) could
be destroyed, making the reference count inaccurate.  This can result in
"Duplicate Free" errors.

Mark and sweep memory architectures (like those employed by Smalltalk) can't
be done in C++ because pointers can't always be identified as pointers.
Integers can look like pointers. In fact programmers often use integers to
point to a memory location.On the other hand other memory management
techniques can consume up to 40% of a project, and memory leaks will be
something developers will be frequently chasing.  Memory management is implied
in Smalltalk.  It is called garbage collection. Its presence is one of  
reasons that Smalltalk runs slower than C++.On the other hand up to 40%  of
the project time can be recovered and without the headaches of memory leaks.

Multiple inheritance is a convention in C++ that can be used to get around the
some of the problems of implementing polymorphism due to strong-typing in C++.
 This can tempt developers to make something a subclass of a virtual class
just to avoid redesign.

C++ is 2 to 3 times more complex than Smalltalk.
There are few incentives for C++ developers to adhere to the object paradigm.  
There is a real and present danger of sliding back into procedural
programming. This will nullify the expense invested in OOA and OOD methods,
tools and training.

Conclusions

No one of the surveyed group believe that one language can suffice at this
site.Most feel that Smalltalk should be used for desktop applications.
Everyone saidthat Smalltalk is an excellent language. They raised performance ...

read more »



Sun, 04 May 1997 21:34:57 GMT  
 What are the differences between C++ and smalltalk?


Quote:
>Roland:

>What follows is something I picked up somewhere - it compares Smalltalk and C++.
> If you look carefully, you will actually see that it compares Smalltalk and
>C++ TO Smalltalk!  Obviously, Smalltalk wins!

I found this comparison somewhat biased towards Smalltalk. Don't get me wrong:
although I use C++, I want to learn Smalltalk.

Here are a couple of points:

Quote:
>Smalltalk Cons
>Execution time is slower than C++. Some estimates indicate that C++ is 2 to 5
>times faster, however implementing garbage collection and strong-typing
>work-arounds in C++ can significantly reduce the performance edge. Another
>mitigating factor is that workstation performance increases by a factor of 5
>every year.                                                       ^^^^^^^^^^^

I'd say something closer to 2. The PowerPC made the Mac go 3 to 4 times faster
than the 68k, but that was due to a change in architecture (doesn't happen
every day). And even if workstations get faster, C++ will still be faster
by the same factor.

Quote:
>C++ Pros
>Most widely used OO language in the industry Many 3rd party class libraries
>available Gives Object Oriented qualities to CFaster than Smalltalk at
>execution time.Many C programmers available that could be trained in OO and
>C++ extensions. Some say that prior experience with COBOL is better than C.

                                                     ^^^^^
Are you joking?                                              

Quote:
>C++ Cons
>Implementations are highly variable across vendors.  For example templates and
>run-time exception handling are implemented differently by different
>compilers. Templates are not implemented at all by some vendors.

C++ hasn't been frozen. Templates, exception handling are relatively new features.
Compiler vendors are trying to get these implemented, but it needs some time.

Smalltalk looks great for building commercial applications, and that's why I
want to get into it. But we have to remember that not everything can be done
with a single language.

Julio Marcos



Tue, 06 May 1997 00:12:24 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. C++/Smalltalk differences and keys to learning C++

2. What are the differences between C++ and smalltalk?

3. What difference(s) am I missing? (Tcl_Eval) (Tcl_EvalFile)

4. The difference between smalltalk/v and smalltalk/v

5. REQUEST: Differences between Gnu Smalltalk & Smalltalk-80

6. Multiprocessing (Differences between Smalltalk/V and Smalltalk/V286)

7. C++ question for Smalltalk/C++ programmers

8. C++ or (Smalltalk and C++)?

9. C++ or (Smalltalk and C++)?

10. C++ or (Smalltalk and C++)? Experience added

11. Help: major differences between Eiffel & C++

12. Difference between ADA and c++

 

 
Powered by phpBB® Forum Software