www.digitalmars.com         C & C++   DMDScript  

D - Comments

reply Matt Busigin <mbusigin helios.spang.org.uk> writes:
Good day, all.


I will go through the D spec section by section, and list my comments.


First of, I believe the creation of D requires a specific goal of exactly
where the language sits over top of the machine, what capabilities are
necessary, and then throw the rest away.

This will prevent the mess that C++ is, in regards to trying to be
'everything to everyone', but rather have things done the right way.

I think your specification actually quite well nearly embodies Java, and I
doubt that is your goal!

I'll repeat that I think that it is very important to decide right early on
exactly what level the language will be based about.

The spec right now just looks like a load of loosely strung together ideas. 
That's nice - except to put together something real, you need to have a
clear definition of your *design philosophy* before deciding much else. 
Your future decisions about what features to include/drop, and how they are
to be implemented should definitely be based on that philosophy.

One of the reasons why C++ is such a pain in the arse to learn is because it
had no clear objective for following a design philosophy, and tried to
appease everyone.  _I_ like C++ (it's my preferred general purpose
programming language), but it is huge, unwieldy, and a lot of concepts
don't fill well together -- because they weren't designed with the same
level of abstraction and general design in mind.

Which makes it a pain in the arse to learn, and implement.

My last general comment is about how you say, "There is no VM.", "It is
compiled", and other comments along those lines.  This is a -language-
specification, not an -implementation- specification, right?  If we get too
specific here, and we don't think ahead, then there WON'T be a virtual
machine or embedded scripting language.  That is short sighted.


Things have to be designed in a general enough fashion that is well **
thought out.  It should be easily implementable and flexible enough to be
implemented in any which way - as an embeddable scripting language, or a
native compiler.

That is the only way you will have success.  There are already enough
languages that are too inflexible that only work in one environment.  One
language (that you also seemed to have "borrowed" quite a bit of your spec
ideas from) to look at for inspiration is Java.  It works well as a native
compiled language, or byte code. This is a good thing.  The language has to
take these generalities into account.



OK, now on to the bickering about featurism.


Excerpt:
         Exception handling. More and more experience with exception
         handling shows it to be a superior way to handle errors than the C
         traditional method of using error codes and errno globals.

Comment:

         Definitely.  When I am writing bog standard C code, I typically
         engage in the practise of creating my own exception handling-ish
         sort of routines by creating an "error stack".

         I have a struct that looks somewhat like this:

         struct error_s
         {
                 char *file, *function;
                 char error[ ERROR_MESSAGE_SIZE ];
                 int xerrno;
         };

         Then, I create an an array of these, and manipulate it as a stack.

         I have my macro to push an error on to the stack:

         #define ERROR( fmt, args... ) {                         \
                es_push( );                                     \
                error_sp->error[ERROR_MESSAGE_SIZE - 1] = '\0'; \
                snprintf( error_sp->error, ERROR_MESSAGE_SIZE - 1,\

                error_sp->file = __FILE__;                      \
                error_sp->function = __FUNCTION__;              \
                error_sp->line = __LINE__;                      \
                error_sp->xerrno = errno;                       \
                }
         
         To read all of the errors, I simply call es_pop() until it returns
         null (no more errors).  This works very well.  It means I can have
         a function -- say, create_listening_socket() -- which calls a few
         other functions that I have written (like create_socket(),
         bind_socket()?).  bind_socket() may have a syscall error, call the
         ERROR() macro right away saying "bind() failed". 
         create_listening_socket() sees this, pushes its own error message
         on the stack ("Unable to bind socket"), and returns.
         
         The result?  The calling function can do something like this:
         
         void print_errors( void )
         {
            error_t *e;
            
            
            while( (e = es_pop() )
            {
               if ( e->xerrno )
                  printf( "%s <%s:%d>: %s (%s)\n",
                     e->file, e->function, e->line, e->error,
                     strerror(e->xerrno) );
               else
                  printf( "5s <%s:%d> %s\n",
                     e->file, e->function, e->line, e->error );
            }
         }
         
         Which prints something like this:
         
         rawsocket.c <create_listening_socket:321>:  bind_socket failed
         rawsocket.c <bind_socket:21>:  bind() failed (Address in use)
         
         (or something to that effect)
         
         Perhaps the language should incorporate some thing like this.


Excerpt:
         C source code compatibility. Extensions to C that maintain source
         compatibility have already been done (C++ and ObjectiveC). Further
         work in this area is hampered by so much legacy code it is unlikely
         that significant improvements can be made.

Comment:
         In fact, it would probably be easiest to, at first, write the
         compiler to simply compile down to C code.


Excerpt:
         Templates. Templates are a way to implement generic programming.
         Other ways are using macros, or having a variant data type. Using
         macros is out.  Variants are straightforward, but the loss of type
         checking is a problem.  The difficulties with C++ templates are
         their complexity, they don't fit well into the syntax of the
         language, all the various rules for conversions and overloading
         fitted on top of it, etc. What's needed is a smoother way to
         integrate them into the language, so they have a much more natural
         and obvious feel to them. I am searching for this solution.

Comment:
         I agree that the syntax doesn't fit well, and things can get
         clouded dead quick with the various rules you're speaking about.

         D *must* have some sort of templates, however.  It is probably wise
         to look at the way Ada does generics - very smoothly done there.


Excerpt:
         On arrays...

Comment:
         In Ada, the array length is actually part of the *array type
         information*.  This makes for efficient array block copying
         routines.  It makes sense.


Excerpt:
        String manipulation is so common, and so clumsy in C and C++, that
        it needs direct support in the language. Modern languages handle
        string concatenation, copying, etc., and so does D.

Comment:
        Have match operators on strings for various string matching
        algorithms, and have the standard library have a regexp state
        machine (!!)

        Do not make the mistake of releasing it with the standard library
        not having one!


Excerpt:
        The fundamental data type is the bit, and D has a bit data type.
        This is most useful in creating arrays of bits:

Comment:
        For implementation, pack this in memory, round off (up) to native
        integer size?


Excerpt:
        D supports simple C style struct's, both for compatibility with C
        data structures and because they're useful when the full power of
        classes is overkill.

Comment:
        Support for packing structs should definitely be native.


Excerpt:
        Assignments do not yield boolean results

Comment:
        Assignments in C don't.  (x = 5) emits the value of 5.



On the subject of identifiers, I believe you should use international
English, not American English.  For example, 'synchronized' should be
'synchronised'.  At least have _both_ - that's a pet peeve of mine (and
would probably be a pet peeve for Americans if we made them use proper
English spellings!).


I've already written too much for one email.  More to follow later.


Cheers,
	Matt


-- 
Nature, to be commanded, must be obeyed. -- Sir Francis Bacon
Aug 16 2001
next sibling parent reply "Angus Graham" <agraham_d agraham.ca> writes:
"Matt Busigin" <mbusigin helios.spang.org.uk> wrote in message
news:9lhi4r$5u3>

 I'll repeat that I think that it is very important to decide right early


on

 exactly what level the language will be based about.

 The spec right now just looks like a load of loosely strung together


ideas.

 That's nice - except to put together something real, you need to have a
 clear definition of your *design philosophy* before deciding much else.
 Your future decisions about what features to include/drop, and how they


are

 to be implemented should definitely be based on that philosophy.


The philsophy seems obvious to me: C++ but better.


 My last general comment is about how you say, "There is no VM.", "It is
 compiled", and other comments along those lines.  This is a -language-
 specification, not an -implementation- specification, right?  If we get


too

 specific here, and we don't think ahead, then there WON'T be a virtual
 machine or embedded scripting language.  That is short sighted.


You wanted a philosophy?  Here is a system level programming language.
Personally, as a game programmer I couldn't care less about embedding
scripting-D or compiled-to-bytecode-D.
I would say treating that stuff as afterthoughts is absolutely the right
answer - make D a better C++ and let Java be Java and Perl be Perl.


 Excerpt:
          Exception handling. More and more experience with exception
          handling shows it to be a superior way to handle errors than the


C

          traditional method of using error codes and errno globals.

 Comment:


(error stack described)

Why use an error stack?  Catch the exception, output the error, throw the
exeption and catch it again at the next level to output the next level of
error messages.  Otherwise you must clean up after the error at every level
and finally output each level's errors at the top level which makes no sense
to me.


 Excerpt:
          C source code compatibility. Extensions to C that maintain source
          compatibility have already been done (C++ and ObjectiveC).


Further

          work in this area is hampered by so much legacy code it is


unlikely

          that significant improvements can be made.

 Comment:
          In fact, it would probably be easiest to, at first, write the
          compiler to simply compile down to C code.


Walter is saying you cannot compile C code in a D compiler, and you reply
that you should be able to compile D _into_ C?  The two are not related in
any way.


 Excerpt:
         String manipulation is so common, and so clumsy in C and C++, that
         it needs direct support in the language. Modern languages handle
         string concatenation, copying, etc., and so does D.

 Comment:
         Have match operators on strings for various string matching
         algorithms, and have the standard library have a regexp state
         machine (!!)

         Do not make the mistake of releasing it with the standard library
         not having one!


I agree.  And since Digital Mars' C/C++ compilers have regular expressions,
I imagine D would too.



 (arrays of bits should be packed, structs should be packed)


As a man with decades of experience writing compilers, I wonder whether
Warren needs handholding with the simplest of implementation issues.

Angus Graham
Aug 16 2001
next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Angus Graham wrote:

 
 "Matt Busigin" <mbusigin helios.spang.org.uk> wrote in message
 news:9lhi4r$5u3>

 Comment:
          In fact, it would probably be easiest to, at first, write the
          compiler to simply compile down to C code.


 
 Walter is saying you cannot compile C code in a D compiler, and you reply
 that you should be able to compile D _into_ C?  The two are not related in
 any way.


A common trend for new languages is to make the early implementations
compile to C, and then use C as a "portable assembly language" to 
avoid having to write an optimizing compiler back-end. I assume this 
is what Matt meant. 

The initial implementation of C++, in fact, was a C++-to-C compiler
(not a simple translator) called Cfront. See Stroustrup's _The Design 
and Evolution of C++_ for more details. 

-Russell B
Aug 16 2001
parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
 The initial implementation of C++, in fact, was a C++-to-C compiler
 (not a simple translator) called Cfront. See Stroustrup's _The Design
 and Evolution of C++_ for more details.


Yes, and Cfront was one reason why C++ got a really bad reputation in the
early days as the compilation speeds very dismal (used to be a big concern
over at Apple, compile times of 15, 30 minutes or more...). A big problem
was the amount of C code generated, but the again at those times memory was
tight and CPU cycles slow, so eventually this problem is no longer there.
But in general, if the first taste of a new compiler is slowness, how good
the language itself is, it will be rejected (and hard to repair the image
long term). --Kent
Aug 16 2001
next sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Kent Sandvik wrote:

 

 The initial implementation of C++, in fact, was a C++-to-C compiler
 (not a simple translator) called Cfront. See Stroustrup's _The Design
 and Evolution of C++_ for more details.


 
 Yes, and Cfront was one reason why C++ got a really bad reputation in the
 early days...


This seems like less of an issue today than it would have been in 
the early days of C++.


 But in general, if the first taste of a new compiler is slowness, how good
 the language itself is, it will be rejected (and hard to repair the image
 long term).


Doesn't seem to have hurt C++'s acceptance all that much in the 
long term, but it may have been a factor in the persistent "C++
is bloated" meme. 

At any rate, given who's implementing this, I doubt that D's backend
will be a complete C compiler. :)

-Russell B
Aug 16 2001
parent Matt Busigin <mbusigin helios.spang.org.uk> writes:
Russell Bornschlegel wrote:

 Kent Sandvik wrote:
 

The initial implementation of C++, in fact, was a C++-to-C compiler
(not a simple translator) called Cfront. See Stroustrup's _The Design
and Evolution of C++_ for more details.


Yes, and Cfront was one reason why C++ got a really bad reputation in the
early days...


 
 This seems like less of an issue today than it would have been in 
 the early days of C++.
 


Quite true.  Writing a backend to GCC would probably be the best (and I 
believe I read that he wanted this done eventually?)
Aug 16 2001
prev sibling parent "Walter" <walter digitalmars.com> writes:
Kent Sandvik wrote in message <9lhsv6$ev7$1 digitaldaemon.com>...

But in general, if the first taste of a new compiler is slowness, how good
the language itself is, it will be rejected (and hard to repair the image
long term). --Kent



Also, compilers for new languages tend to have poor code generators. D has
an advantage of using a well developed optimizing back end. There will be no
need for early adopters to suffer with long compile times and lousy
generated code.

Just bugs <g>.
Aug 23 2001
prev sibling parent Matt Busigin <mbusigin helios.spang.org.uk> writes:
Angus Graham wrote:


 
 The philsophy seems obvious to me: C++ but better.
 



Just like C++ was 'C, but better' (or C, with classes, ore accurately), 
and look what a mess it became!  I think you need more clearly defined 
and thought out ideas about where you want to go - and take a look at 
Ada as a very good example of a language that did this.



 You wanted a philosophy?  Here is a system level programming language.
 Personally, as a game programmer I couldn't care less about embedding
 scripting-D or compiled-to-bytecode-D.
 I would say treating that stuff as afterthoughts is absolutely the right
 answer - make D a better C++ and let Java be Java and Perl be Perl.



Of course.  But as a control systems programmer, for my non-realtime 
systems, scriptable procedures written in the same language as the 
caller would be excellent.

Writing various things as modules is one thing, but a lot of things suit 
the scripted VM paradigm, too.  Especially if it were machine 
independent with the standard libraries .. (not that I would expect an 
implementation like this within a short period of time ;)

What I am saying, is that part of the philosophy also should be thinking 
about flexibility and portability to other applications.  (applications, 
in a general sort of way)



 Why use an error stack?  Catch the exception, output the error, throw > the
 exeption and catch it again at the next level to output the next level > of
 error messages.  Otherwise you must clean up after the error at every > level
 and finally output each level's errors at the top level which makes no > sense
 to me.


Excuse the crap quoting. The reason is output management.  One of the 
weakest parts of almost any code.  Yes, easily implementable in host code.


Errors and exceptions generally queue up . You generally have to handle 
them that way.  Why not make a nice clean interface to do it?


 Walter is saying you cannot compile C code in a D compiler, and you  
 reply
 that you should be able to compile D _into_ C?  The two are not 
 related in
 any way.



Right that does it, I'm going to tin tomorrow.

No, sorry, not directly related.  I'll blame tiredness on my rather 
unrelated comment.


 I agree.  And since Digital Mars' C/C++ compilers have regular >expressions,
 I imagine D would too.


Excellent.



(arrays of bits should be packed, structs should be packed)


 
 As a man with decades of experience writing compilers, I wonder whether
 Warren needs handholding with the simplest of implementation issues.


Not all structs should be packed, unless explicitely stated.  Perhaps he 
has other ideas for that.


Cheers,
Matt
Aug 16 2001
prev sibling next sibling parent reply "Sheldon Simms" <sheldon semanticedge.com> writes:
Im Artikel <9lhi4r$5u3$1 digitaldaemon.com> schrieb "Matt Busigin"
<mbusigin helios.spang.org.uk>:


 On the subject of identifiers, I believe you should use international
 English, not American English.  For example, 'synchronized' should be
 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and
 would probably be a pet peeve for Americans if we made them use proper
 English spellings!).


You are making a worse mistake by assuming that your preferred spelling
is "international". It isn't. American spelling is taught as standard
is many countries. In any case, it's ridiculous to gripe about this.
As least the words are in your language. Think of all the people who
don't have english as a native language that have to put up with english
words as programming language reserved words. By your argument there
should be different reserved words for each natural language, or perhaps
thousands upon thousands of reserved words from every natural language
to make sure that no one feels left out.

-- 
Sheldon Simms / sheldon semanticedge.com
Aug 17 2001
next sibling parent reply "kaffiene" <kaffiene xtra.co.nz> writes:
"Sheldon Simms" <sheldon semanticedge.com> wrote in message
news:9lirlg$181d$1 digitaldaemon.com...

 Im Artikel <9lhi4r$5u3$1 digitaldaemon.com> schrieb "Matt Busigin"
 <mbusigin helios.spang.org.uk>:


 On the subject of identifiers, I believe you should use international
 English, not American English.  For example, 'synchronized' should be
 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and
 would probably be a pet peeve for Americans if we made them use proper
 English spellings!).


 You are making a worse mistake by assuming that your preferred spelling
 is "international". It isn't. American spelling is taught as standard
 is many countries. In any case, it's ridiculous to gripe about this.
 As least the words are in your language. Think of all the people who
 don't have english as a native language that have to put up with english
 words as programming language reserved words. By your argument there
 should be different reserved words for each natural language, or perhaps
 thousands upon thousands of reserved words from every natural language
 to make sure that no one feels left out.


I think that the English might have a valid claim that they were speaking
English first - and that it spread to a number of countries across the world
prior to the advent of American English.  There really are a lot of
countries that don't do English the way America does.

Personally, as a New Zealander who is a programmer, I'm used to using both
interchangably (International English in everyday life, American English in
software APIs).  Would it really hurt to support both spellings?

Peter.
Aug 17 2001
next sibling parent "Sheldon Simms" <sheldon semanticedge.com> writes:
Im Artikel <9lj2tp$1cdf$3 digitaldaemon.com> schrieb "kaffiene"
<kaffiene xtra.co.nz>:


 "Sheldon Simms" <sheldon semanticedge.com> wrote in message
 news:9lirlg$181d$1 digitaldaemon.com...

 Im Artikel <9lhi4r$5u3$1 digitaldaemon.com> schrieb "Matt Busigin"
 <mbusigin helios.spang.org.uk>:


 On the subject of identifiers, I believe you should use international
 English, not American English.  For example, 'synchronized' should be
 'synchronised'.  At least have _both_ - that's a pet peeve of mine
 (and would probably be a pet peeve for Americans if we made them use
 proper English spellings!).


 You are making a worse mistake by assuming that your preferred spelling
 is "international". It isn't. American spelling is taught as standard
 is many countries. In any case, it's ridiculous to gripe about this. As
 least the words are in your language. Think of all the people who don't
 have english as a native language that have to put up with english
 words as programming language reserved words. By your argument there
 should be different reserved words for each natural language, or
 perhaps thousands upon thousands of reserved words from every natural
 language to make sure that no one feels left out.


 
 I think that the English might have a valid claim that they were
 speaking English first - and that it spread to a number of countries
 across the world prior to the advent of American English.  There really
 are a lot of countries that don't do English the way America does.
 
 Personally, as a New Zealander who is a programmer, I'm used to using
 both interchangably (International English in everyday life, American
 English in software APIs).  Would it really hurt to support both
 spellings?


My point is just that there is no international/american dichotomy.
American spelling is used internationally as well.

And my point about speakers of other languages stands.

-- 
Sheldon Simms / sheldon semanticedge.com
Aug 17 2001
prev sibling parent Christophe de Dinechin <descubes earthlink.net> writes:
kaffiene wrote:


 Personally, as a New Zealander who is a programmer, I'm used to using both
 interchangably (International English in everyday life, American English in
 software APIs).  Would it really hurt to support both spellings?


Interestingly, the C++ compiler on which I worked (HP Ansi C++ compiler) has an
error message for "misspelled keyword". I never tried to trigger that error (I
suspect it's disabled). But what if I have:

    int synchronizzed

Is this a misspelled keyword, or a valid declaration?


Christophe
Aug 17 2001
prev sibling parent reply Christophe de Dinechin <descubes earthlink.net> writes:
Sheldon Simms wrote:


 Im Artikel <9lhi4r$5u3$1 digitaldaemon.com> schrieb "Matt Busigin"
 <mbusigin helios.spang.org.uk>:


 On the subject of identifiers, I believe you should use international
 English, not American English.  For example, 'synchronized' should be
 'synchronised'.  At least have _both_ - that's a pet peeve of mine (and
 would probably be a pet peeve for Americans if we made them use proper
 English spellings!).


 You are making a worse mistake by assuming that your preferred spelling
 is "international". It isn't. American spelling is taught as standard
 is many countries. In any case, it's ridiculous to gripe about this.
 As least the words are in your language. Think of all the people who
 don't have english as a native language that have to put up with english
 words as programming language reserved words. By your argument there
 should be different reserved words for each natural language, or perhaps
 thousands upon thousands of reserved words from every natural language
 to make sure that no one feels left out.


Another use for the preprocessor. I am personally illiterate and
typo-maniac, so I define:

#define sinhcronised synchronized

But of course, you can't do that in D ;-)


Christophe
Aug 17 2001
next sibling parent "Sheldon Simms" <sheldon semanticedge.com> writes:
Im Artikel <3B7D331B.A63C155A earthlink.net> schrieb "Christophe de
Dinechin" <descubes earthlink.net>:


 Sheldon Simms wrote:
 

 Im Artikel <9lhi4r$5u3$1 digitaldaemon.com> schrieb "Matt Busigin"
 <mbusigin helios.spang.org.uk>:


 On the subject of identifiers, I believe you should use international
 English, not American English.  For example, 'synchronized' should be
 'synchronised'.  At least have _both_ - that's a pet peeve of mine
 (and would probably be a pet peeve for Americans if we made them use
 proper English spellings!).


 You are making a worse mistake by assuming that your preferred spelling
 is "international". It isn't. American spelling is taught as standard
 is many countries. In any case, it's ridiculous to gripe about this. As
 least the words are in your language. Think of all the people who don't
 have english as a native language that have to put up with english
 words as programming language reserved words. By your argument there
 should be different reserved words for each natural language, or
 perhaps thousands upon thousands of reserved words from every natural
 language to make sure that no one feels left out.


 
 Another use for the preprocessor. I am personally illiterate and
 typo-maniac, so I define:
 
 #define sinhcronised synchronized
 
 But of course, you can't do that in D ;-)


:-)

-- 
Sheldon Simms / sheldon semanticedge.com
Aug 17 2001
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
Christophe de Dinechin wrote in message <3B7D331B.A63C155A earthlink.net>...

I am personally illiterate and
typo-maniac, so I define:

#define sinhcronised synchronized

But of course, you can't do that in D ;-)



d*mn right!
Aug 21 2001
prev sibling parent Russ Lewis <russ deming-os.org> writes:
Christophe de Dinechin wrote:


 #define sinhcronised synchronized


sinhcronised = ?calculate sinh with cron?
Aug 21 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Matt Busigin wrote in message <9lhi4r$5u3$1 digitaldaemon.com>...

I think your specification actually quite well nearly embodies Java, and I
doubt that is your goal!



D seriously departs from Java. Here are some of the ways, in no particular
order:

1. D has out and inout function parameters, i.e. functions can return
multiple values.
2. D has enums.
3. D's floating point is the best available on the target machine.
4. D has design by contract.
5. D has a direct interface to C and operating system APIs.
6. D has lightweight structs.
7. D has strings implemented as arrays, not objects.
8. D has broad basic type support.
9. D has imaginary and complex floating point types.
10. D has typedefs.
11. D does not do dynamic class loading.
12. D has turn-offable array bounds checking.
13. D has support for assert()s and debug statements.
14. D works with your other existing dev tools (make, linkers, debuggers,
etc.)

Java is designed to be write once, run everywhere. D is designed for writing
efficient native system apps. Although D and Java share the notion that
garbage collection is good and multiple inheritance is bad <g>, their
different design goals mean the languages have very different feels.
Aug 21 2001
parent "Bradeeoh" <bradeeoh crosswinds.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9lt5k7$1th6$1 digitaldaemon.com...

 Matt Busigin wrote in message <9lhi4r$5u3$1 digitaldaemon.com>...

I think your specification actually quite well nearly embodies Java, and




I

doubt that is your goal!



 D seriously departs from Java. Here are some of the ways, in no particular
 order:

 1. D has out and inout function parameters, i.e. functions can return
 multiple values.
 2. D has enums.
 3. D's floating point is the best available on the target machine.
 4. D has design by contract.
 5. D has a direct interface to C and operating system APIs.
 6. D has lightweight structs.
 7. D has strings implemented as arrays, not objects.
 8. D has broad basic type support.
 9. D has imaginary and complex floating point types.
 10. D has typedefs.
 11. D does not do dynamic class loading.
 12. D has turn-offable array bounds checking.
 13. D has support for assert()s and debug statements.
 14. D works with your other existing dev tools (make, linkers, debuggers,
 etc.)

 Java is designed to be write once, run everywhere. D is designed for


writing

 efficient native system apps. Although D and Java share the notion that
 garbage collection is good and multiple inheritance is bad <g>, their
 different design goals mean the languages have very different feels.


<applause>
Well put, and exactly why I'm awaiting even a preliminary D compiler to
start messing around with  :)

-Brady
Aug 21 2001