Re: C++

[olafBuddenhagen]

Hi,

On Wed, Sep 23, 2009 at 06:31:41PM +0200, Bas Wijnen wrote:
> On Wed, Sep 23, 2009 at 12:59:06AM +0200, address@hidden
> wrote:
> > On Tue, Sep 15, 2009 at 06:26:10PM +0200, Bas Wijnen wrote:

> > Unfortunately, in spite of the name and resulting general
> > perception, C++ can not really be considered an evolution of C.
> > While it adds a couple of useful features, and a couple of features
> > considered useful by some, it also takes away an essential feature
> > of C -- its elegance.
> 
> Not at all.  You can still write C code in C++, which means that
> whatever you consider elegant is still possible.  If you mean that it
> is possible to write horrible code in C++, then I agree.  But that is
> very easy in C as well.  Both languages allow many things, which is
> what makes them so powerful.

My point is not that C++ encourages writing ugly code. (Though some
people claim this too -- but I haven't cared to look at enough C++ code
to be able to judge for myself :-) )

My point is that many of the "features" added by C++ are dead ugly in
themselfs. (cin/cout probably being the worst of them.) The fact that
it's possible to use a certain subset that is pretty elegant and
consistent -- called C -- doesn't change the fact that C++ as a language
is dead ugly.

> > > Of course Richard Stallman is a known hater of C++.  He has a
> > > point that everybody knows C, so using that makes the code
> > > readable for everyone. [...] IMO his love for C is unreasonable.  
> > 
> > Richard Stallman is not a C++ hater,
> 
> I heard that the egcs fork of gcc was really a quarrel between him and
> people who wanted a C++ port integrated into it.

Not at all. C++ has been a part of gcc long before the fork. (In fact, I
think I read somewhere that it was the first native C++ compiler -- but
I'm not sure on this point.)

According to Wikipedia, the original gcc maintainers were generally
conservative about merging improvements; which is why at some point many
improvements were collected to form egcs. *Some* of these were indeed
improvements for better C++ support -- but concluding that RMS hates C++
is absurd.

> I thought this as well, but I have found that using only a few
> features (in particular organizing code in classes with member
> functions, instead of creating interfaces which pass their object as
> an explicit first argument) will really make the result a lot more
> readable.

That is precisely what I take issue with: this doesn't really hide any
complexity. It's just a different notation -- which obscures the fact
that the object is really just an argument like all the others; limits
flexibility by strict class boundaries; and I don't find it more
readable either, quite the opposite. (Though the latter is obviously a
matter of taste...)

> > While for the kind of code where a higher-level language is more
> > useful, you better use a true high-level language.
> 
> I come from real low-level languages (assembly and sometimes even raw
> machine code), and C++ is high enough for me. ;-) It is well possible
> that some other languages offer even more.  I just haven't discovered
> those languages yet.

Are you at all familiar with high-level languages; say Haskell, Lisp, or
even Python?...

Using any of these (or others of a similar abstraction level) would at
least offer enough benefit to even consider a departure from C for
certain components being wothwhile.

> > > However, our main interest is not that everyone can read our code.
> > 
> > Free software is about enabling people to understand and adapt the
> > software. An obscure language is a major obstacle.
> 
> Yes, I agree.  As I wrote, it is a good thing if many people can read
> our code.  But it is more important that we can efficiently write good
> code.  It obviously helps to combine the two.  But if both cannot be
> accomplished together, IMO actually getting the code written is more
> important than making it readable.

Note however that using a more common language, the "we" can potentially
be much larger...

Of course it's a tradeoff, which might actually be positive, if using a
language that really improves productivity a lot. (Hint: not C++.) 

> Additionally, the point about free software you cite is that it is
> useful for educational purposes.

No, not really. Studying the code can happen for educational purposes of
course: but more important is the ability to know what the software
really does; and adapting it to ones own needs.

> It does not make sense to teach people to use a language which really
> isn't the best tool for the job.  So if you would think that C is not
> the best language to write a kernel in, doing it anyway "because
> people can learn from it" isn't actually a good idea.

This point is moot, as I consider C to be the best language for
low-level stuff like the microkernel :-)

Of course this is different for some higher-level components of the
Hurd... But then, all the other points still apply :-)

-antrik-