Re: C++

[Bas Wijnen]

On Mon, Nov 02, 2009 at 12:30:11AM +0100, address@hidden wrote:
> > In C, you would need to add the parent class as a first member, which
> > would lead to variable.parent.parent.foo and variable.parent.bar.  If
> > what you mean is inheritance (so top is just a specialized version of
> > middle, which is a specialized version of base), then all those parent
> > references are not adding information, but instead only obscuring
> > things.
> 
> No, they are definitely *not* obscuring things. They make things more
> explicit.

Yes, and because of all that explicitness, it gets harder to see what
it's all about.  That's obscuring to me.

> Whether it is good or bad is a different question. (I for my part
> consider it good in most cases.)

I consider it good only when what you mean is not inheritance.  Some
people might use inheritance just because it's there, or something.
Then it just confuses things.  But in Iris, for example, all kernel
objects inherit from a common kObject.  I have linked lists of those,
and I don't need any casts, I can just loop over kObject *'s.  If you
implement inheritance with parent members, that is not possible either,
because the start of the parent is not guaranteed to be the start of the
container (even though in practice it always is AFAIK).

> Organising things isn't hiding complexity. It's managing complexity at
> best.

Whatever you like to call it.  But with this definition, I don't think I
actually want to hide any complexity.  In the end, I want to be in
control of everything, so it must still be there in a form that I can
change.

> Moreover, it can be done perfectly well without a special language
> syntax IMHO.

It can indeed.  I used to dislike C++ for the same reason.  However,
after using it for some time, I have become to appreciate the syntax
features.  They changed the way I think about problems, and the new way
of thinking makes solving some problems significantly easier.  Sorry I
can't really explain it, it's something you have to experience to
understand, I think. ;-)

> > > It's just a different notation
> > 
> > I don't have a problem with that, if it is useful, and it is.
> 
> As I already said, this is subjective -- *I* don't consider it useful.

Of course it is subjective. :-)

> > I've used Python for some larger projects.  It's a very nice language,
> > but I wouldn't consider it higher level than C++.
> 
> Err... You are the first person I ever saw making such a claim.

Perhaps the others don't know enough C++, or (more likely) I don't know
enough Python. ;-)

> In either case, the fact that few people are helping now, doesn't mean
> it wouldn't be even fewer if we used a less common language. While I
> can't actually prove it, common sense tells me it's pretty obvious.

I feel that the people who want to help wouldn't be discouraged by
seeing a few new syntax features in code that otherwise looks like C.
But of course that's just a feeling as well, and I can't prove it
either.

> > > > 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;
> > 
> > I consider that educational.
> 
> No, it's not about learning kernel programming. It's about being in
> control. This is very different. When learning programming, it might be
> wise to choose a language that supports learning. But here, we assume
> that people already know programming. Choosing a language for
> "educational value" would be pointless. Choosing a *common* language is
> what puts more people in control.

I prefer a language which makes them learn at the same time.  That's why
"using a C++ compiler to compile code that is mostly C" is so
attractive: people can read it if they only know C, and will see
constructs that are not as elegant would they have been done in C.  For
understanding and hackability it doesn't make much difference IMO.

> I actually consider generic programming with the C preprecessor pretty
> fun -- though not exactly helping readability ;-)

I must agree with you there. :-)  But "fun" in a sense of "nice to play
with", not in a sense of "let's put it in a project which must be
maintainable". :-P

> However, I'm not talking about runtime features, nor explicit code
> generation. I'm talking about the type inference implemented by some
> languages (mostly functional ones), allowing the compiler to
> automatically instance any function for the types it is actually used
> on,

But that's exactly what templates do (and what C is incapable of).  If
you want such features in the kernel, you will need templates, because
the other languages aren't suitable for kernel programming, I suppose (I
don't know which ones you mean, though, so that might be incorrect).

> without any explicit template handling.

Again, I don't want to hide my complexity so far away that I can't reach
it anymore.  I want to hide it into a place where it isn't in the way.
IMO templates are very usable for that.

Thanks,
Bas

signature.asc
Description: Digital signature