www.digitalmars.com         C & C++   DMDScript  

D - Which goal takes precedence?

reply Tony West <Tony_member pathlink.com> writes:
The recent discussion regarding the switch statement raised a more fundamental
issue.

Which of the following two goals should take precedence in D language design
issues:
1. compatibility with C or C++
2. striving for the best possible design

Where C/C++ (I know these are really two different languages) are considered to
already embody best practices, this is not an issue.  However, I suspect most
people with an interest in D will consider that this is often not the case.

Please note that I'm not trying to reopen discussion of the switch statement,
but simply trying to establish which principle is normally going to govern D
design.

Tony
Dec 18 2003
next sibling parent "Matthew Wilson" <matthew.hat stlsoft.dot.org> writes:
 The recent discussion regarding the switch statement raised a more


fundamental

 issue.

 Which of the following two goals should take precedence in D language


design

 issues:
 1. compatibility with C or C++
 2. striving for the best possible design

 Where C/C++ (I know these are really two different languages) are


considered to

 already embody best practices, this is not an issue.  However, I suspect


most

 people with an interest in D will consider that this is often not the


case.

 Please note that I'm not trying to reopen discussion of the switch


statement,

 but simply trying to establish which principle is normally going to govern


D

 design.

 Tony


It can't be an all or nothing thing, surely? C and, especially, C++ are
sometimes "wrong" in ways that end up being very powerful. For example, the
behaviour of the language in selecting matching function overloads has led
to all kinds of powerful techniques in template meta-programming. So
sometimes it may not be best to ape what these languages have, since some of
their power is accident, and which we can, one would hope, engineer more
understandably and more easily with the benefit of hindsight and our
compiler-walter.

But, the switch statement is not a good example of such. There were some
rather serious differences of philosphical opinion which, IMO, have nothing
to do with the particulars of D or any other language. The few people who
argued for the C/C++ switch semantics status-quo did so (correct me if I'm
wrong) not because they considered that it represents a zenith of design,
but rather than it was less dangerous to tamper with current widely known
but broken semantics, than to introducing surprising new broken ways.

IMO, D should have nothing to do with compatibility with C++ whatsoever.
(Advertainment: for anyone stupid enough to be planning to buy my book next
summer, there're 6 chapters covering why C++ is *not* a good language of
inter-link-unit communication, and then, perversely, how to do just that
;).) But D absolutely must maintain compatibility with C, which is the
lingua franca of multi-lingual programming for just about any
language-language or language-technology that you can name. Note that not
having C++ compatibility does *not* mean that C++ cannot interroperate with
D. In the next release there'll be the std.recls module, which is
implemented entirely in C++, using lots of modern jiggery pokery. It's just
that it expresses a C API (as all C++ components should!). (Walter and I are
hoping that this mapping from the C++ recls to D will serve as a good, or
adequate at least, example for anyone else trying to do the same. It's
undoubtedly the case that many D components will start life as D mappings;
and probably many will always be so, which is perfectly appropriate.)

But just because D _can_ talk C, does not mean that that should be the limit
of its ambition. I predict that, by the time Walter presents at next year's
expo, D will have a whole new template architecture, which will facilitate
generic programming from the ground up, not as the warty and
dialectically-partial afterthought that is the case with C++.
(Self-aggrandising aside: I am occasionally asked by Boost fans why STLSoft
is so incomprehensible, and yet when I look at Boost code my brain freezes;
that just seems to be the way of C++ template programming: it's the most
clique-y thing in IT. The more frequent question is why it does not use
Boost, or why it is not part of Boost. I'll leave those questions as an
exercise for the reader, and maintain a politic silence ...)

Anyway, I've crapped (/carped?) on far too much, as is my wont. I think we
should always aim for the highest highs in D, which are (in semi-random
order):

- efficiency
- robustness
- maintainability
- flexibility

Anytime the language can promote any/all of the last three without
sacrificing the first one, I think we should strongly consider the merits.

Cheers

-- 
Matthew Wilson

STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

----------------------------------------------------------------------------
---
Dec 18 2003
prev sibling next sibling parent The Lone Haranguer <The_member pathlink.com> writes:
You left out 

3) Safer than C/C++

I of course want 2 to be the primary objective, with 3 coming in second, then 1.

In article <brrnjq$2a3q$1 digitaldaemon.com>, Tony West says...

The recent discussion regarding the switch statement raised a more fundamental
issue.

Which of the following two goals should take precedence in D language design
issues:
1. compatibility with C or C++
2. striving for the best possible design

Where C/C++ (I know these are really two different languages) are considered to
already embody best practices, this is not an issue.  However, I suspect most
people with an interest in D will consider that this is often not the case.

Please note that I'm not trying to reopen discussion of the switch statement,
but simply trying to establish which principle is normally going to govern D
design.

Tony
Dec 18 2003
prev sibling next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:

isn't any clearly better way to do it, then the way C chose is preferred
since people are familiar with it.  But if C is broken in any way, I would
prefer that D attempt to fix it.

Sean

"Tony West" <Tony_member pathlink.com> wrote in message
news:brrnjq$2a3q$1 digitaldaemon.com...

 The recent discussion regarding the switch statement raised a more


fundamental

 issue.

 Which of the following two goals should take precedence in D language


design

 issues:
 1. compatibility with C or C++
 2. striving for the best possible design

 Where C/C++ (I know these are really two different languages) are


considered to

 already embody best practices, this is not an issue.  However, I suspect


most

 people with an interest in D will consider that this is often not the


case.

 Please note that I'm not trying to reopen discussion of the switch


statement,

 but simply trying to establish which principle is normally going to govern


D

 design.

 Tony
Dec 18 2003
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
Tony West wrote:


The recent discussion regarding the switch statement raised a more fundamental
issue.

Which of the following two goals should take precedence in D language design
issues:
1. compatibility with C or C++
2. striving for the best possible design

Where C/C++ (I know these are really two different languages) are considered to
already embody best practices, this is not an issue.  However, I suspect most
people with an interest in D will consider that this is often not the case.

Please note that I'm not trying to reopen discussion of the switch statement,
but simply trying to establish which principle is normally going to govern D
design.

Tony
  


If we support 1 then we end up with C++ again.  So 2 is the obvious choice.

-Anderson
Dec 18 2003