Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!news.maz.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: C++ / Smalltalk
Message-ID: <1995Jan9.121647.19131@wavehh.hanse.de>
Organization: The Internet
References: <3ejiou$t69@news1.delphi.com>
Date: Mon, 9 Jan 95 12:16:47 GMT
Lines: 117

jsutherland@BIX.com (Jeff Sutherland) writes:

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

>Agreed, some of the world class object database developers I know still
>code only
>in C.  They think C++ is too high level and that it is a kludge.

They probably want some kind of `assembler' to do very low-level stuff
and (hopefully) express high-level-constructs with some kind of their
own language.

I generally feel better when the nice little languages I use (perl,
lisp-dialects) are implemented in pure C that in C++. More portable
(because a good C compiler is more likely to be there) and you don't
have to worry about compiler bugs, assuming that free software is most
often compiled using a free Compiler - g++, not to speak of outdated
compilers like most cfront environments.

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

>I've worked with COBOL programmers being converted to C++.  It takes 12-18
>months to make a C++ programmer out of a COBOL programmer, 6 months with
>Smalltalk, and 3 months with Synchronicity.  This is due to the complexity
>of C++
>some of which is due to pointer managment.  I rest my case.

It is certainly true that one can become a useful Smalltalk programmer
in a much shorter time than a useful C++ programmer (Useful = you can
put him/her in your team and let him/her implement some of the
non-wizard code).

My point was that becoming a programmer who is able to write Smalltalk
code as (runtime-) efficient as his implementation permits takes as
much time as it does to learn the more complex C++ language (This is
not a comment on how long does it take to solve a given problem once
you're educated).

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

>Agreed.  C++ is the assembler language of the day and should always be
>used where assembly language is required.  The goal should be 
>to hide the assembler as much as possible from the application developer.

>But to get back to the most important point, who in their right mind would 
>code applications in assembler when they could use Smalltalk?

Mumble, here's some difference in how we see C++. Of course, it makes
a good language to implement a higher-level language.

But C++ can do a bit more. Many people think it is more difficult to
solve a given problem in C++. I think, C++ does a bit better than it
seems from such statements, because C++ forces some different style of
working. C++ focus on having some kind of library for the problem to
solve and the implementor of an end-user-application should focus on
glueing the components together. Those end-user-apps gluers doesn't
have to know about all the complexities of C++ (I think this statement
is true).

It may require a better programmer and more time to implement such a
library, but it is assumed that *every* company without inhouse-
wizards buys such libraries. When enough people buy a given library
the price for the library will drop at least to the costs of solving
the problem inhouse using a more 'code-writing-efficient'
language. The end-user-application programmers are not that expensive
(as long as you provide libraries that fit the problem) and therefore
it is not too bad they spend more time using a C++ lib to solve the
problem instead of a library in other languages.

The right way or not, it is what most companies think is good. Having
a company that may be sued responsible for the most difficult
programming tasks and the prospect to get by without own good-educated
programmers may sound good. Sadly, much of this is caused by
inhouse-developers doing bad work and being a danger for their
company.

As an individual programmer I have to decide where to place myself,
and being an inhouse-programmer who maintains his tools by himself
still sounds best to me, even when the general trend is against it. Of
course, I need to be *very* efficient and I need a language that
enables myself to react fast to new tasks, faster than the provider of
C++ classes needs to (or can).

I still didn't decide about C++ for my own use. I certainly don't fear
the educational needs for C++, and runtime efficiency is very good and
important for my work. The point is, I didn't really make up my mind
about my personal style of OO programming and learning new languages
shapes this style. So far this learning seems the best way to become a
more efficient programmer, more important that the decision for one
language :-) And so far there are places where C++ gets in my way of
OO programming, but not so much that I could say it clearly outweighs
C++'s advantages (runtime efficiency, available resources, interfacing
with C-based libs).
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de> Fax +49 40 522 85 36
