C++ for Smalltalk programmers [was: Smalltalk for C programmers]
Stephan Rudlof
sr at evolgo.de
Thu Feb 10 20:37:38 UTC 2000
Ian Piumarta wrote:
>
> *** TOTALLY OFF-TOPIC. SMALLTALKERS: PRESS "DELETE" NOW ***
>
I'm also a Smalltalker, but I haven't found the "DELETE" button... ;-)
> I tried hard not to answer, but I was probably feeling a bit grumpy
> already -- so consider this an utterly selfish attempt at cheering
> myself up. (Last time this happened, about 18 months ago, I did
> manage to stop myself before hitting CTRL-D.)
>
> I've said before that C++ gets a really unfair press,
Hm, I'm not from a news magazine. In the public I think C++ has gotten
very, very good press! So good, that it is much more widespreaded as it
would be with a more rational evaluation...
> and now I'm
> saying it again. But before the rant gets underway, C++ detractors
> should maybe try visiting Stroustrup's home page and reading some of
> his (rather good) short papers on the design philosophy behind C++,
Once a time I have bought Stroustrup C++ book, but I haven't had the
time to fully read it: And working through all the exercises would be
work for months (in the actual release the exercises seem to be reduced
a little bit ;-) ).
> how the language is intended to be used, and in what contexts (there
> are, after all, many more wrong tools for a given job than right
> ones). Maybe enlightenment will strike.
I have another interesting link:
http://www.elj.com/cppcv3/
contains
C++?? : A Critique of C++ (3rd Ed.)
and
Programming and Language Trends of the 1990s
from Ian Joyner. There are discussed principal weaknesses of C++.
>
> Picking a message at random (there's nothing personal at all in the
> following: it could have been any one of several messages)...
>
> > C++ is *much* more error-prone as C, because it is ANSI-C with *many*
> > additional constructs. Therefore the complexity of C is enlarged.
>
> cfront manages to implement the entirety of C++ in standard C.
Many programming languages have Turing computation capability...
You could use Basic, too.
> The
> basic facilities are therefore the same, only in C++ one has
> abstractions that make the code easier to read for the same overall
> effect.
I agree in principle. If C++ is reasonable used this is true: But using
C++ reasonable is not trivial!
First you have to learn *when* to use *which* of the *many* features:
There are often many ways to do something in C++, but in my experience
often it is difficult to choose the best or just one of the better ones
in advance.
> Look at Xt/Xaw: straight C code, with classes and
> inheritance.
>
> (Pedantically besides: C++ isn't a superset of ANSI C. There are some
> fundamental differences.)
I have read: Every ANSI-C program should also be a correct C++
program...
If this statement lays near by 'true', then C++ indeed is a superset of
ANSI-C.
BTW: I'm not talking about K&R-C, this is a dino.
>
> FWIW (not much, really) my own experience is that C++ is far less
> error-prone than C -- precisely because it has many more constructs
> for abstracting away complexity and concisely expressing intent.
Agreed: if you are a disciplined programmer and *experienced* in C++,
this is true.
>
> > - try to understand 'Functionals' in C++;
>
> There are classes in the Smalltalk library that defy comprehension
> too. (Anyway, I don't see the problem. <functional> is to C++ what
> sort blocks are to Smalltalk -- just generalised a bit into generic
> traits in a way that will often let the compiler elide them entirely
> at compile time. And thanks for the pointer: I had to go find a copy
> of the 3rd edition to read about <functional>. Way cool!)
>
> > - the horrible syntax of templates: much code for less functionality;
>
> No worse than any other parameterised type system, and far more
> powerful (and flexible, in the presence of a strong type system) than
> some.
But the source files where templates are defined are looking bad:
Ok, you have to use a good class browser... But the M$ stuff with which
I had to work with over a year has a browser which has problems with
templates: If they are better to read in the source, they are not
displayed correctly in the browser and vice versa :-(
>
> > - thumb class browsers in M$ VC++6.0;
>
> Nobody ever suggested that Microsoft ever made anything that was a
> good metric. If Microsoft made Smalltalk, we'd have a real PR problem
> on our hands.
>
> There are much better alternatives to Microsoft, and they're free.
>
> > - write a full functional iterator in STL style for multiary trees;
>
> Again, there are plenty of alternatives -- including several with a
> Smalltalk look-and-feel.
Objective-C.
> Or better still, implement a really good one
> from scratch that can be reused as many times as necessary.
>
> (ObBesides: a decent container class implementation runs twice as fast
> as the equivalent thing in STL.)
>
> > - decide when to collect garbage;
>
> That's what the GC is there for -- so that we don't have to decide.
>
> If Boehm's doesn't fit for whatever reason, then one can always roll
> one's own -- it is, after all, part and parcel of The C++ Way.
>
> (And I know this one is fodder for a minor religious war, so that's
> why I'm gratuitously and irresponsibly wasting 18k of everybody's
> inboxes -- or 9 seconds of download time on a slow modem, to put it
> financially -- with the "attachment". [I have endless problems
> extracting MIME attachments and "quoted printable" {or whatever it's
> called}, so now I get to have my Unixy revenge.])
>
> > - look at message passing with Macros in C++ source files in VC++;
>
> Nobody ever suggested that Microsoft ever wrote any software worth
> looking at. I'm afraid this is thoroughly inadmissible evidence.
>
> (IMH [and personal] O, they're experts at writing utter junk.)
>
> > - just becoming familiar with version control takes time, and time...;
>
> What does that have to do with C++?
Nothing. But it has to do with my frustration about VC++6.0 development
tools...
> Anyway, there's no reason to use
> version control if it doesn't make the job easier. There are
> alternatives (including using nothing at all).
>
> > - never ending list...
>
> I didn't see it start yet.
>
> > I don't want to complain only: C++ is better than C if its features are
> > used modestly.
By a very experienced programmer.
> And it is as fast as C, because it is C with extensions
> > (important for e.g. image processing).
>
> It's often faster, because (decent) C++ compilers do better type
> inferencing and constant propagation than do C compilers.
C++ compilers compile ANSI-C, isn't it?
>
> But more important is the increased opportunity for abstraction: the
> algorithmic leverage due to higher expressivity should not be
> underestimated. And for that there's no beating using its most
> advanced features, in copious quantities.
Agreed: If...
I have chosen to use C++ for an image processing library (and not only
for the GUI) and have had a fight with my project manager asking: 'Why
didn't you use C? It's easier to port. Better to understand for
students.', etc.. He hadn't programmed in C++ at all and is afraid of
C++...
I know it has its merits *** if used reasonable *** !
But I've found it difficult to become experienced enough to use it
reasonable. And for newbies it is much better to start with Smalltalk, I
think.
I have gone a long way from
TI57->Basic->Pascal->Modula->Lisp->C->Smalltalk->C->C++ and some other
languages less intensively. I suppose you have gone a long way in a
similar manner, too.
But try to imagine you had to learn C++ without any C experience before,
horrible isn't it?
>
> And one could say precisely the same things in Smalltalk's defense, of
> course...
>
> > > 5. A good C programmers can became two-times productive (or more)
> > > using Smalltalk instead of C....but someone must show this to
> > > him...
>
> Funny -- I seem to write C++ as fast as I write Smalltalk. (But I
> never once claimed to be a fast Smalltalk programmer. ;-)
>
> Ahh... that did the trick. I'm feeling much better now. Hmm, which
> language should I enjoy hacking in this afternoon? So many to choose
> from, and every one of them is *soooo* much fun! ;-)
>
> Kind regards,
>
> Ian
>
> PS: the following in no way represents good C++ style (and I doubt
> that I could quite compete with Microsoft on that score),
What is good C++ style? I don't think that it is easy to generate
examples for that not coming from good C++ practice...
> but it most
> definitely does represent good C++ practice. IMH (and all too
> frequent) O, anyone who hasn't already written something similar (in
> spirit, if nowhere near in detail) hasn't been using C++ the way it
> was intended to be used.
>
> Name: enjoy.tgz
> enjoy.tgz Type: unspecified type (application/octet-stream)
> Encoding: x-uuencode
After a very short first look it seems to be a nice piece of code (in
typical C++ style) to me. :-)
A last remark:
Didn't the Linux guys try to use C++ and then change back to C, because
the compilers were to error prone (because of the complexity of C++)?
With best regards,
Stephan
P.S.: If you are interested I can post you a typical source code (not M$
related) from my practice, but not today: Monday I will be at work
again, here I'm programming ST and C!
--
Stephan Rudlof (sr at evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
More information about the Squeak-dev
mailing list
|