Hi, On Wed, Sep 23, 2009 at 06:31:41PM +0200, Bas Wijnen wrote: > On Wed, Sep 23, 2009 at 12:59:06AM +0200, [email protected] > 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-
