BCS Wrote:

> Hello Walter,
> 
> > BCS wrote:
> > 
> >> I guess my point is that aside from VERY resource limited systems, almost no one will have C as their first choice. Even with those limited systems I'd bet that most people would rather be working in something else if they could. That said, there are many places where it ends up being the lingua franca.
> >> 
> > I still think you're underestimating C's audience. Consider the Linux effort - they can choose any implementation language they want, and they choose C. They aren't forced into C.
> > 
> 
> Yes, C has a wide audience (any one who says differently is selling something). But I still thing that their are very few cases where C will be chosen for reasons other than it's purely technical merits. If C++/Java/C#/python/whatever would have done just as good a job in Linux as C, I'd almost bet that Linux wouldn't have been written in C. My point isn't that C is never the right choice (as that is clearly false) but that when C is chosen, it's (almost) always for technical reasons rather than aesthetic ones (where it is merely good enough).

I would say these are the technical merits of C that get it chosen these days:

1. The new code they're writing will be part of a large body of existing C code which they don't have time, permission, or inclination to convert to C++.

2. They need to be aware of every tiny low level detail anyway, so having the language do too many things "for you" is not the desired approach (security, O/S and embedded work).

3. C has a real ABI on almost every platform; therefore, C is chosen for most inter-language work such as writing python modules.

But some people really *are* choosing C for aesthetics.  Linus Torvalds, bless his little world dominating heart, chose C for a normal app (git), and he cited that the existence of operator overloading in C++ is bad because it hides information -- e.g. in the general case you "never know what an expression is actually doing."

I think this can be seen as mainly an aesthetic choice.  Avoiding a language because it *supports* information hiding (which is what I think operator overloading is) is not really an 'economic' tradeoff, since you could choose not to hide information by not using those features.  He'd just rather not be in the vicinity of language features that make those kinds of choices because they seem wrong to him (and because he wants to keep C++ies out of his code I think.)

Some people want their language to have a "WYSIWYG" relationship with the generated assembler code (if I'm right, it does seem consistent with him being an OS developer).

I also know some scientists and mathematicians who use C rather than C++.  I think the reason is that by using a simpler language they can know everything about the language.  I think the sooner they can 'get the computer science stuff out of the way', the sooner they can focus on what they see as the domain issues.  (I think once the program gets big enough, the CompSci aspects reassert themself and scalability and maintainability issues begin to bite you in the rear.)

Kevin

== Quote from Kevin Bealer (kevinbealer@gmail.com)'s article
> I would say these are the technical merits of C that get it chosen these days: 1. The new code they're writing will be part of a large body of existing C code
which they don't have time, permission, or inclination to convert to C++.
> 2. They need to be aware of every tiny low level detail anyway, so having the
language do too many things "for you" is not the desired approach (security, O/S
and embedded work).

Even if you need to be aware of every tiny detail, it still sometimes pays to have
more ability to automate some stuff.  For example, even if you care about
performance enough to really think hard about when to use virtual functions, it's
nice to have an automated, non error-prone way to create them if you do want them.
 Similarly, if you need to parametrize something on types, it's nice to be able to
automate this with templates instead of doing it manually.

> 3. C has a real ABI on almost every platform; therefore, C is chosen for most
inter-language work such as writing python modules.
> But some people really *are* choosing C for aesthetics.  Linus Torvalds, bless
his little world dominating heart, chose C for a normal app (git), and he cited that the existence of operator overloading in C++ is bad because it hides information -- e.g. in the general case you "never know what an expression is actually doing."

Isn't the whole purpose of any language higher-level than assembler to hide information?  If your language isn't hiding any complexity, you may as well be writing in raw, inscrutable hexadecimal numbers.

> I think this can be seen as mainly an aesthetic choice.  Avoiding a language
because it *supports* information hiding (which is what I think operator overloading is) is not really an 'economic' tradeoff, since you could choose not to hide information by not using those features.  He'd just rather not be in the vicinity of language features that make those kinds of choices because they seem wrong to him (and because he wants to keep C++ies out of his code I think.)
> Some people want their language to have a "WYSIWYG" relationship with the
generated assembler code (if I'm right, it does seem consistent with him being an
OS developer).

This kind of thinking is understandable for kernel development and very resource-constrained environments, but not much else.

> I also know some scientists and mathematicians who use C rather than C++.  I
think the reason is that by using a simpler language they can know everything
about the language.  I think the sooner they can 'get the computer science stuff
out of the way', the sooner they can focus on what they see as the domain issues.
 (I think once the program gets big enough, the CompSci aspects reassert themself
and scalability and maintainability issues begin to bite you in the rear.)

I personally am a scientist (bioinformatics specifically) and I think having basic
complexity management in your code is worthwhile even at fairly small project
sizes.  I learned this the hard way.  For anything over about 100 lines I want
some modularity (classes/structs, higher order functions, arrays that are more
than a pointer + a convention, etc.) so that I can tweak my scientific app easily.
 Furthermore, multithreading is absolutely essential for some of the stuff I do,
since it's embarrassingly parallel, and is a huge PITA in C.

dsimcha wrote:
> I personally am a scientist (bioinformatics specifically) and I think having basic
> complexity management in your code is worthwhile even at fairly small project
> sizes.  I learned this the hard way.  For anything over about 100 lines I want
> some modularity (classes/structs, higher order functions, arrays that are more
> than a pointer + a convention, etc.) so that I can tweak my scientific app easily.
>  Furthermore, multithreading is absolutely essential for some of the stuff I do,
> since it's embarrassingly parallel, and is a huge PITA in C.


When I was working on converting Optlink to C, I thought long and hard about why C instead of D. The only, and I mean only, reason to do it via C was because part of the build process for Optlink used old tools that did not recognize newer features of the OMF that D outputs.

Once it is all in C, the old build system can be dispensed with, and then it can be easily converted to D.

If you want to, you can literally write code in D that is line-for-line nearly identical to C, and it will compile to the same code, and will perform the same.

You can do the same with C++ - Linus surely knows this, but I suspect he didn't want to use C++ because sure as shinola, members of his dev team would start using operator overloading, virtual base classes, etc.

Walter Bright wrote:
> dsimcha wrote:
>> I personally am a scientist (bioinformatics specifically) and I think having basic
>> complexity management in your code is worthwhile even at fairly small project
>> sizes.  I learned this the hard way.  For anything over about 100 lines I want
>> some modularity (classes/structs, higher order functions, arrays that are more
>> than a pointer + a convention, etc.) so that I can tweak my scientific app easily.
>>  Furthermore, multithreading is absolutely essential for some of the stuff I do,
>> since it's embarrassingly parallel, and is a huge PITA in C.
> 
> 
> When I was working on converting Optlink to C, I thought long and hard about why C instead of D. The only, and I mean only, reason to do it via C was because part of the build process for Optlink used old tools that did not recognize newer features of the OMF that D outputs.
> 
> Once it is all in C, the old build system can be dispensed with, and then it can be easily converted to D.
> 
> If you want to, you can literally write code in D that is line-for-line nearly identical to C, and it will compile to the same code, and will perform the same.
> 
> You can do the same with C++ - Linus surely knows this, but I suspect he didn't want to use C++ because sure as shinola, members of his dev team would start using operator overloading, virtual base classes, etc.

Well, if you ask the question "what's C++'s biggest mistake?" it's much more difficult. C++'s failure to specify the ABI is enough of a reason to use C instead, I reckon. It think it's an appalling, inexcusable mistake -- it guaranteed compiled libraries 20 years later would use extern(C), not extern(C++). And that's not the worst C++ mistake.

Don:
> Well, if you ask the question "what's C++'s biggest mistake?" it's much more difficult. C++'s failure to specify the ABI is enough of a reason to use C instead, I reckon.

What about of mistakes that D can avoid? :-) A larger stack alignment? (I think on Snow Leopard the standard stack alignment is 16 bytes).

Bye,
bearophile

Don wrote:
> Well, if you ask the question "what's C++'s biggest mistake?" it's much more difficult. C++'s failure to specify the ABI is enough of a reason to use C instead, I reckon. It think it's an appalling, inexcusable mistake -- it guaranteed compiled libraries 20 years later would use extern(C), not extern(C++). And that's not the worst C++ mistake.

I'd be hard pressed to come up with C++'s biggest mistake. Perhaps it was failing to address the array => pointer conversion.

Walter Bright wrote:
> Don wrote:
>> Well, if you ask the question "what's C++'s biggest mistake?" it's much more difficult. C++'s failure to specify the ABI is enough of a reason to use C instead, I reckon. It think it's an appalling, inexcusable mistake -- it guaranteed compiled libraries 20 years later would use extern(C), not extern(C++). And that's not the worst C++ mistake.
> 
> I'd be hard pressed to come up with C++'s biggest mistake. Perhaps it was failing to address the array => pointer conversion.

I think the biggest mistake was preserving backwards source-code compatibility with C, but _still_ managing to lose many of C's advantages. As a pure superset of C, it _should_ have been able to replace 100% of the uses of C, but failed miserably.

Walter Bright wrote:
> Don wrote:
>> Well, if you ask the question "what's C++'s biggest mistake?" it's much more difficult. C++'s failure to specify the ABI is enough of a reason to use C instead, I reckon. It think it's an appalling, inexcusable mistake -- it guaranteed compiled libraries 20 years later would use extern(C), not extern(C++). And that's not the worst C++ mistake.
> 
> I'd be hard pressed to come up with C++'s biggest mistake. Perhaps it was failing to address the array => pointer conversion.

That's partially addressed by the ability to define somewhat encapsulated types like std::vector. Don's suggested lack of ABI is big, and unfortunately not addressed in C++0x. There are many smaller ones to follow... two that come to mind: using "<"/">" for grouping and argument-dependent lookup.

Happy New Year in 2010! Let's make it a great year for D.


Andrei

Andrei Alexandrescu wrote:
> Walter Bright wrote:
>> Don wrote:
>>> Well, if you ask the question "what's C++'s biggest mistake?" it's much more difficult. C++'s failure to specify the ABI is enough of a reason to use C instead, I reckon. It think it's an appalling, inexcusable mistake -- it guaranteed compiled libraries 20 years later would use extern(C), not extern(C++). And that's not the worst C++ mistake.
>>
>> I'd be hard pressed to come up with C++'s biggest mistake. Perhaps it was failing to address the array => pointer conversion.
> 
> That's partially addressed by the ability to define somewhat encapsulated types like std::vector.

I agree that it is partially addressed by std::vector and std::string. But:

1. Those appeared 10 years after C++ was in widespread use, 10 years of wandering in the desert with everyone trying to invent their own string class.

2. It still reflects in the design of std::string, in that to preserve the 0 termination design, it makes severe compromises.

3. The glaring fact that std::vector<char> and std::string are different suggests something is still wrong.

4. The pointer-centric design resulted in std::iterator, and of course iterators must go!

> Don's suggested lack of ABI is big, and unfortunately not addressed in C++0x. There are many smaller ones to follow... two that come to mind: using "<"/">" for grouping and argument-dependent lookup.

I would suggest a broader issue than < >, it is the willingness to require semantic analysis to successfully parse C++. < > would never have been used if that was not considered acceptable. Only later did the C++ community realize there was value in parsing things without semantic analysis, i.e. template bodies.

ADL was a fix for another issue, the asymmetric design of operator overloading. So I don't think ADL was a mistake so much as what C++ was forced into to compensate for a previous mistake.

Walter Bright:
> 3. The glaring fact that std::vector<char> and std::string are different suggests something is still wrong.

In an array/vector you want O(1) access time to all items (ignoring RAM-cache access/transfer delays), while in a string with variable-width Unicode encoding that can be hard to do. So they look like two different data structures.

Bye,
bearophile