Re: What's C's biggest mistake?

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++.

Re: What's C's biggest mistake?

== Quote from Kevin Bealer (kevinbealer <at> 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

Unofficial wish list status.(Jan 2010)

Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

I am closing this wish list. 
New requests should be posted to bugzilla on http://d.puremagic.com/issues/

It would be a great help, 
if you could help move some of the wish list items to bugzilla.
But please use the same title, so it is easy to avoid duplication.

Right now the wish list looks like this:

213  Stack tracing (#26)
203  Reflection API (#6)
133  vectorization (#10)
114  Multiple return values (tuples (#28)
103  Multiple opCast per class (#24)
97  Debug check for null reference (#52)
90  Native AMD64 codegen (#36)
80  !in (#44)
79  Short syntax for new (#18)
77  unit test after compilation (#1)
71  extra compiler values (#19)
67  Return-type overloading (#49)
58  Explicit out/inout (#38)
56  Foreach on first/on last (#42)
55  Unit test isolation  (#2)

Re: What's C's biggest mistake?

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.

Re: output ranges: by ref or by value?

Re: What's C's biggest mistake?

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.

Re: What's C's biggest 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

Things to look up in the docs

In a language like C/D1 there are common simple parts that's easy to remember, like:
int x = 10;

Other parts are more complex, but they are common enough that you usually remember them:
for (int x = 10; x < foo.bar(); x += 2) {}

Other parts of the language or its standard library are less easy to remember, but in normal programs they
are uncommon enough that looking them into the docs is acceptable. You don't need to keep in memory all the
standard library of Java or C# to use such languages.

But in a language (like D1/D2) there can be parts that are both common enough and hard enough to remember,
those are a problem, because looking in the docs each time is a waste of programming time (especially if you
don't have an IDE under your hands) and more. Realistically it may be impossible to remove or simplify all
such parts from a large system language as D1/D2, but it's important to write down a list of such parts, to
keep such list in memory during the language design, and to try to minimize the length of such list. In
theory some of the things in such list can be modified to make them more easy to remember, etc.

It's nice to program in Python also because most common parts of the language are easy to remember, for
example the are't one undred string/list methods as in Ruby, so after few months you memorize the most
common Python string methods, and this helps speed up programming significantly. 

What are the parts of the D1/D2 languages that are both common enough in programs and not easy to remember, so
you need to look them often in the docs (or in an example list, code snippets list, already written code,
etc)? This list is partially subjective, but probably there are also some common trends.

For example the syntax of opApply is one of the things I have often to look up in the docs (while I never need the
manual to remember how to write a generator in Python, that has very similar purposes).

Do you have other parts to add to this list?

Bye,
bearophile

Re: What's C's biggest mistake?

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.

Re: What's C's biggest mistake?

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.