www.digitalmars.com         C & C++   DMDScript  

D - why D

reply user domain.invalid writes:
Why do we need a new language
isn't C\C++ asm and those many other high level languages enough ?
what's the big use of D ?
Mar 16 2003
next sibling parent Helmut Leitner <helmut.leitner chello.at> writes:
user domain.invalid wrote:

 Why do we need a new language
 isn't C\C++ asm and those many other high level languages enough ?
 what's the big use of D ?


I'm new to this group and not bound to D, so maybe I can answer your 
question without becoming guilty of hype or advocacy.

First, your question seems pretty silly to me, because there are 
thousands of programming languages out there and if you start asking
about whether there are enough or not, why start with D? 
Anyone who is able to write a new language is free to do so. 
And Walter Bright has proven this ability long ago.

Second, there are lots of people like me, who like the C language and 
are not satisfied with the developments during the last 10-20 years.
The C standardization process has brought the language to a stop.
C++ has deviated from the C philosophy of a simple language that

and they add a lot of complexity and an enormous footprint.

So I think D doesn't need a "big use". If those that like to use
C for its universal applicability, can use D for the same things,
but with some benefits like lightweight OO and GC, keeping things
simple and environments small, that's quite enough.

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Mar 16 2003
prev sibling parent reply Bill Cox <bill viasic.com> writes:
user domain.invalid wrote:

 Why do we need a new language
 isn't C\C++ asm and those many other high level languages enough ?
 what's the big use of D ?


Hi.

Everyone will have differing opinions on this.  Here's mine:

The short answer:  Commercial applications are generally written in C 
and C++.  C is too feature poor.  C++ sucks.  D is a nice answer.

The elevator ride answer:  Commercial applications are generally written 
in C and C++.  C is too feature poor.  C++ has major issues.  In 
particular, it is far too difficult to write compilers for C++.  Instead 
of getting more powerful programming capabilities, we've been waiting 15 
years for C++ compilers simply to work on most platforms.  Worse, at 
least half the programmers out there will never understand C++ well 
enough to use it properly.  This makes it unsuitable for large scale 
development with large teams.  I believe this is why GNU recommends that 
most applications be developed in C, rather than C++.  There aren't any 
good new languages out there to succeed C that seem to have a real 
chance at it, except for D.  Java is too slow when running on a virtual 

Microsoft.  Ocaml is cool, but runs 2x slower than C, and like C++, most 
programmers will never figure out how to use it properly.

Some unspoken reasons that most people wont get:  There's some really 
cool stuff we've come up with in the last 15 to 20 years that 
programmers could really benifit from.  For example, contracts, and 
features that make pointers a thing of the past.  This is stuff you can 
only sell to programmers who are early addopters.  D is the only 
language I'm aware of that is judiciously incorporating the new ideas 
that work well for high-performance applications developed in a 
realistic industrial developement environment.  Generally, the other new 
languages have been developed by academics who haven't been in industry 
long enough to know what features will work in industry.  You have to be 
really picky, and you need a lot of experience to be able to choose.

I think I know of many of the major programming trends in EDA.  There is 
a shift to C++ that has been trying to take hold since the late 80's. 
C++ has been instrumental in killing half of the projects the EDA 
industry tries to use it on.  Once average programmers become a 
significant part of the staff, kiss your C++ code base good-bye.  There 
was a significant attempt at Java, but it didn't work out.  Many of us 
thought that early use of Java was a good move, since surely good 
compilers would come along.  However, Sun worked hard to tie Java into 
the virtual machine in such a way that it would be very difficult to 
compile.  Mirror classes require a Java interpreter be present.  Swing 
(now JFC) uses them.  There are other under-handed features Sun put in, 
like an extremely complex constant propogation spec that makes 
absolutely no sense.  I get a good laugh when I hear them complaining 
about Microsoft.

If you know of other good successors to C, I'm always interested in 
hearing about them.  Truth is, I still need convincing before commiting 
to D.  There is only one reasonably stable compiler, and our code has to 
run cross-platform.  At a minimum, I require Sun, Linux and Windows XP. 
  If Walter gives up on this, it's surely dead, which doesn't make me 
feel comfortable betting on it.  Also, D does not yet incorporate any 
features that I'm dying to be able to use in EDA software development. 
I don't need GC, and can live with assertions rather than contracts.  We 
already hide the use of almost all pointers.  Features that I think 
would be really great for EDA haven't made it in.  For example, I have 
to emulate dynamic object extensions with void pointers and lots of 
casting.  Dynamic extensions are a requirement in EDA systems built 
around a common object database.  I still can't reuse simple code like 
graph modules very well.  Support for code generators is poor, and we 
have a lot of code generators to make up for short-commings in C.  Also, 
I'm becomming concerned that the huge number of features already in D 
may make new compilers hard to write.

All these shortcommings may be resolved.  D is still developing.

Bill
Mar 16 2003
next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
The only feature I see in D that may be even somewhat hard to compile (to
anyone with the means to write a commercial compiler) is templates.
Templates are not so mysterious;  academia has the whole thing worked out
already.  There are plenty of papers on it.

Templates are also key to code reuse so they have to be in D.  Lack of
templates is what drives me running and screaming away from languages such


If anything, I'd get rid of the instance keyword and integrate generics
directly into the core language.  There was a thread going a short time ago
called "Why isn't everything a template".  I'm definitely in that camp.  I
figure *anywhere* in the code you can write a type specifier (in any kind of
declaration) you should be able to put a construct such as "$T <:
comparable" and have the compiler figure it out at point of usage.  And I
haven't this out thoroughly so I'm unclear how to handle instantiation.  It
just seems as though there should be a way.  I wish I had a fulltime job
designing languages!

The way Walter has it now though if anything makes it far easier to write a
compiler for.  There's something to be said for that.

I don't see any features of D that are hard to compile.  What in particular
were you thinking of?

Sean

P.S. Regarding C and C++, you're right on the money.  C is too prehistoric
to be anything but a (bad) intermediary language these days.  One may be
able to write a toy project in it, but nothing substantial.  C++ is too
complicated and the community too fragmented.  It has all the nasty things
about C and doesn't deliver on the higher-order capabilities.  Memory
management in C++ is a huge burden.  And anytime you try to make user
constructs in C++ to make the language a little nicer, nobody wants to use
it because they don't understand it.  The specification doesn't give you
enough guarantees to even be able to write a decent Singleton construct.  It
seems as though every single design decision in C++ was made to facilitate
compiler vendors to be as lazy and uncooperative as possible, and yet we
still don't have but one standards-conforming compiler.  Porting C++
continues to be barely possible but entirely unadvisable.  And users pay the
price over and over again.  We pay because the language is too complex.  We
pay because it doesn't have enough modern features.  We pay because it's
inconsistent and error-prone.  We pay because it's impossible to write a
conforming compiler for.  We pay because the standard only guarantees us
enough rope to hang ourselves by, but not enough to hold our app together.

I'm sick of it, and I think alot of other people are too.

Functional languages seem like they have alot of the answers, in theory, but
every time I've tried to learn one, it's like going back to kindergarten.  I
have to relearn everything.  That sucks.

"Bill Cox" <bill viasic.com> wrote in message
news:3E74EF6C.1050906 viasic.com...

 user domain.invalid wrote:

 Why do we need a new language
 isn't C\C++ asm and those many other high level languages enough ?
 what's the big use of D ?


 Hi.

 Everyone will have differing opinions on this.  Here's mine:

 The short answer:  Commercial applications are generally written in C
 and C++.  C is too feature poor.  C++ sucks.  D is a nice answer.

 The elevator ride answer:  Commercial applications are generally written
 in C and C++.  C is too feature poor.  C++ has major issues.  In
 particular, it is far too difficult to write compilers for C++.  Instead
 of getting more powerful programming capabilities, we've been waiting 15
 years for C++ compilers simply to work on most platforms.  Worse, at
 least half the programmers out there will never understand C++ well
 enough to use it properly.  This makes it unsuitable for large scale
 development with large teams.  I believe this is why GNU recommends that
 most applications be developed in C, rather than C++.  There aren't any
 good new languages out there to succeed C that seem to have a real
 chance at it, except for D.  Java is too slow when running on a virtual

 Microsoft.  Ocaml is cool, but runs 2x slower than C, and like C++, most
 programmers will never figure out how to use it properly.

 Some unspoken reasons that most people wont get:  There's some really
 cool stuff we've come up with in the last 15 to 20 years that
 programmers could really benifit from.  For example, contracts, and
 features that make pointers a thing of the past.  This is stuff you can
 only sell to programmers who are early addopters.  D is the only
 language I'm aware of that is judiciously incorporating the new ideas
 that work well for high-performance applications developed in a
 realistic industrial developement environment.  Generally, the other new
 languages have been developed by academics who haven't been in industry
 long enough to know what features will work in industry.  You have to be
 really picky, and you need a lot of experience to be able to choose.

 I think I know of many of the major programming trends in EDA.  There is
 a shift to C++ that has been trying to take hold since the late 80's.
 C++ has been instrumental in killing half of the projects the EDA
 industry tries to use it on.  Once average programmers become a
 significant part of the staff, kiss your C++ code base good-bye.  There
 was a significant attempt at Java, but it didn't work out.  Many of us
 thought that early use of Java was a good move, since surely good
 compilers would come along.  However, Sun worked hard to tie Java into
 the virtual machine in such a way that it would be very difficult to
 compile.  Mirror classes require a Java interpreter be present.  Swing
 (now JFC) uses them.  There are other under-handed features Sun put in,
 like an extremely complex constant propogation spec that makes
 absolutely no sense.  I get a good laugh when I hear them complaining
 about Microsoft.

 If you know of other good successors to C, I'm always interested in
 hearing about them.  Truth is, I still need convincing before commiting
 to D.  There is only one reasonably stable compiler, and our code has to
 run cross-platform.  At a minimum, I require Sun, Linux and Windows XP.
   If Walter gives up on this, it's surely dead, which doesn't make me
 feel comfortable betting on it.  Also, D does not yet incorporate any
 features that I'm dying to be able to use in EDA software development.
 I don't need GC, and can live with assertions rather than contracts.  We
 already hide the use of almost all pointers.  Features that I think
 would be really great for EDA haven't made it in.  For example, I have
 to emulate dynamic object extensions with void pointers and lots of
 casting.  Dynamic extensions are a requirement in EDA systems built
 around a common object database.  I still can't reuse simple code like
 graph modules very well.  Support for code generators is poor, and we
 have a lot of code generators to make up for short-commings in C.  Also,
 I'm becomming concerned that the huge number of features already in D
 may make new compilers hard to write.

 All these shortcommings may be resolved.  D is still developing.

 Bill
Mar 16 2003
next sibling parent reply Bill Cox <bill viasic.com> writes:
Hi, Sean.

Sean L. Palmer wrote:

 The only feature I see in D that may be even somewhat hard to compile (to
 anyone with the means to write a commercial compiler) is templates.
 Templates are not so mysterious;  academia has the whole thing worked out
 already.  There are plenty of papers on it.


I agree.  I also agree that they are needed in D, so the complexity is 
worth it.  I'm too lazy to read the code, but hopefully it wasn't that 
bad in D.


 I don't see any features of D that are hard to compile.  What in particular
 were you thinking of?
 
 Sean


I can't think of any.  My concern is the number of features, which is 
quite high.  Each one takes a little effort to implement.

Bill
Mar 16 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Features that are truly orthogonal are ok.

It's features that interact with each other in subtle ways that cause the
most bugs.

Ok, what features of D would you consider "fat" that can be trimmed without
losing functionality?

There's some redundancy in the declaration parsing to retain C compatibility
that I think could go.

Sean

"Bill Cox" <bill viasic.com> wrote in message
news:3E7552C4.40307 viasic.com...

 I don't see any features of D that are hard to compile.  What in




particular

 were you thinking of?

 Sean


 I can't think of any.  My concern is the number of features, which is
 quite high.  Each one takes a little effort to implement.

 Bill
Mar 17 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi, Sean.

Sean L. Palmer wrote:

 Features that are truly orthogonal are ok.
 
 It's features that interact with each other in subtle ways that cause the
 most bugs.
 
 Ok, what features of D would you consider "fat" that can be trimmed without
 losing functionality?
 
 There's some redundancy in the declaration parsing to retain C compatibility
 that I think could go.
 
 Sean


I don't think there is much fat in D.  I simply think that while lots of 
featuers vs C is great, it's making writing D compilers hard.  The two 
goals work against eachother.

A possible solution would be for D to become extensible as in Forth or 
Scheme.  Much of D could be defined in standard libraries.  This could 
possibly allow D compilers to be written more easily while still 
supporting a rich feature set.  In particular, D would need to have a 
yacc-like syntax extension capability, and compile-time mirror classes 
for meta programming.

If such a capability were included, the following features from the 
comparison chart could possibly be pushed out of the D compiler and into 
standard libraries:
Resizeable arrays
Arrays of bits
Array slicing
Array bounds checking
Associative arrays
Operator overloading
Templates
Design by Contract
Unit testing
try-catch-finally blocks
Support all C types
Complex and Imaginary

I could have some mistakes here, but I think all these could be 
implemented.  In particular, tempates are easy to support in libraries 
using compile-time reflection classes.  Check out OpenC++ for some ideas 
in that direction, although I think a much simpler aproach would work well.

In addition, this kind of extendability would allow me to add dynamic 
class extensions, and several other EDA-centric features.

Some other features of D do add power, but IMO are not used very often 
in an industrial setting:

Function delegates
Closures
Nested functions

None of these particularly bother me, the need for them just doesn't 
seem to show up much in the EDA code I've seen.  AFAIK C++ still doesn't 
have closures or nested functions, and if I remember correctly, member 
pointers took forever to get into the standard.

Bill
Mar 17 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E7630A8.40404 viasic.com...

 Some other features of D do add power, but IMO are not used very often
 in an industrial setting:

 Function delegates
 Closures
 Nested functions

 None of these particularly bother me, the need for them just doesn't
 seem to show up much in the EDA code I've seen.  AFAIK C++ still doesn't
 have closures or nested functions, and if I remember correctly, member
 pointers took forever to get into the standard.


These 3 features are strongly interrelated. For examples of their
usefulness, see:

    www.digitalmars.com/d/pretod.html
    www.digitalmars.com/d/ctod.html
    www.digitalmars.com/d/cpptod.html

I've noticed in my own C/C++ code those 3 features result in a significant
shrink of my source code, with better type checking and cleaner syntax.

One feature I *am* considering dumping is the properties-as-function-call
thing. First of all, it isn't implemented, and secondly, it produces
numerous ambiguities in the semantic parsing. More ambiguities means more
special case rules and a harder to understand language.
Mar 17 2003
next sibling parent reply J C Calvarese <jcc-47 excite.com> writes:
Walter wrote:
...snip...

 One feature I *am* considering dumping is the properties-as-function-call
 thing. First of all, it isn't implemented, and secondly, it produces
 numerous ambiguities in the semantic parsing. More ambiguities means more
 special case rules and a harder to understand language.


Do you mean 'get'ers and 'set'ers?  They are my favorite OOP concept. 
Could it be that the ambiguities are due to poor coding techinques? 
'Get'ers and 'set'ers seem like a straight-forward, common-sensical way 
to make encapsulation easy and effective.  (But I'm not the one writing 
the compiler.)  Just my 2 cents.

Justin
Mar 17 2003
parent reply Bill Cox <bill viasic.com> writes:
J C Calvarese wrote:

 Walter wrote:
 ...snip...
 

 One feature I *am* considering dumping is the properties-as-function-call
 thing. First of all, it isn't implemented, and secondly, it produces
 numerous ambiguities in the semantic parsing. More ambiguities means more
 special case rules and a harder to understand language.


 
 
 Do you mean 'get'ers and 'set'ers?  They are my favorite OOP concept. 
 Could it be that the ambiguities are due to poor coding techinques? 
 'Get'ers and 'set'ers seem like a straight-forward, common-sensical way 
 to make encapsulation easy and effective.  (But I'm not the one writing 
 the compiler.)  Just my 2 cents.
 
 Justin


He's not talking about get'ers and set'ers.  Properties are different.

Get'ers and set'ers are a key feature.  Why they didn't make it into C++ 
or Java I will never understand.

Properties are attributes of types like size that replace constructs 
like sizeof.  The syntax usually looks like Class.property.  It sounds 
like there may be some need for a Class.property(parameter) syntax, but 
I don't know what it would be for.

Bill
Mar 18 2003
parent J C Calvarese <jcc-47 excite.com> writes:
Bill,

Thanks for allaying my fear.  I'm not well-versed in OOP-speak.  I tend 
to think of classes as being composed of properties (fields) and methods 
(functions).  Oops.  I never even realized someone might want to define 
their own .size for a class.

Justin


Bill Cox wrote:
...snip...

 He's not talking about get'ers and set'ers.  Properties are different.
 
 Get'ers and set'ers are a key feature.  Why they didn't make it into C++ 
 or Java I will never understand.
 
 Properties are attributes of types like size that replace constructs 
 like sizeof.  The syntax usually looks like Class.property.  It sounds 
 like there may be some need for a Class.property(parameter) syntax, but 
 I don't know what it would be for.
 
 Bill
Mar 18 2003
prev sibling next sibling parent Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Bill Cox" <bill viasic.com> wrote in message
 news:3E7630A8.40404 viasic.com...
 

Some other features of D do add power, but IMO are not used very often
in an industrial setting:

Function delegates
Closures
Nested functions

None of these particularly bother me, the need for them just doesn't
seem to show up much in the EDA code I've seen.  AFAIK C++ still doesn't
have closures or nested functions, and if I remember correctly, member
pointers took forever to get into the standard.


 
 These 3 features are strongly interrelated. For examples of their
 usefulness, see:
 
     www.digitalmars.com/d/pretod.html
     www.digitalmars.com/d/ctod.html
     www.digitalmars.com/d/cpptod.html
 
 I've noticed in my own C/C++ code those 3 features result in a significant
 shrink of my source code, with better type checking and cleaner syntax.


I've been using nested functions a lot in my code.  It helps me to 
express them algorithmically - I write a set of nested functions that 
performs utilities until the main code is a pure implementation of the 
algorithm.


 One feature I *am* considering dumping is the properties-as-function-call
 thing. First of all, it isn't implemented, and secondly, it produces
 numerous ambiguities in the semantic parsing. More ambiguities means more
 special case rules and a harder to understand language.


It isn't implemented in DMD - it IS in DLI.

I don't like the implicit semantics, although properties are useful in 
an explicit syntax, particularly with interfaces and rigorous OOP 
application.  I favour OMG IDL (which I still can't shake off as reading 
"Oh my God, IDL!"); in interfaces it would be declared as:

    readonly attribute type name; /* Implements a get only. */
    attribute type name; /* Implements get/set. */

So I could drop in, say, the COM IDL and just have to change a couple 
type names.  Then in implementation, something like:

    attribute type name
    {
       get
       {
          return super.name;
       }

       set (value)
       {
          foobar = value;
       }
    }
Mar 18 2003
prev sibling parent Bill Cox <bill viasic.com> writes:
Walter wrote:

 "Bill Cox" <bill viasic.com> wrote in message
 news:3E7630A8.40404 viasic.com...
 

Some other features of D do add power, but IMO are not used very often
in an industrial setting:

Function delegates
Closures
Nested functions

None of these particularly bother me, the need for them just doesn't
seem to show up much in the EDA code I've seen.  AFAIK C++ still doesn't
have closures or nested functions, and if I remember correctly, member
pointers took forever to get into the standard.


 
 
 These 3 features are strongly interrelated. For examples of their
 usefulness, see:
 
     www.digitalmars.com/d/pretod.html
     www.digitalmars.com/d/ctod.html
     www.digitalmars.com/d/cpptod.html
 
 I've noticed in my own C/C++ code those 3 features result in a significant
 shrink of my source code, with better type checking and cleaner syntax.
 
 One feature I *am* considering dumping is the properties-as-function-call
 thing. First of all, it isn't implemented, and secondly, it produces
 numerous ambiguities in the semantic parsing. More ambiguities means more
 special case rules and a harder to understand language.


Ok... the examples do look cleaner.  I look forward to trying these 
three features on for size to see how I like them.  I suspect they'll 
grow on me.

If losing properties-as-function-call simplifies parsing, feel free to 
do it.  I don't think I'll miss it.

Bill
Mar 18 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b53hl5$15a6$1 digitaldaemon.com...

 The only feature I see in D that may be even somewhat hard to compile (to
 anyone with the means to write a commercial compiler) is templates.
 Templates are not so mysterious;  academia has the whole thing worked out
 already.  There are plenty of papers on it.


The way C++ does templates is extremely difficult to write a compiler for.
The way D does it is pretty simple - see \dmd\src\dmd\template.c.


 And anytime you try to make user
 constructs in C++ to make the language a little nicer, nobody wants to use
 it because they don't understand it.


That's exactly why GC and associative arrays are built-in to D, rather than
done with add-on libraries.


  The specification doesn't give you
 enough guarantees to even be able to write a decent Singleton construct.


It

 seems as though every single design decision in C++ was made to facilitate
 compiler vendors to be as lazy and uncooperative as possible, and yet we
 still don't have but one standards-conforming compiler.


It might seem that way, but I was told more than once by C++ committee
members that implementation difficulties were of no consequence. Well, the
consequence is as I predicted - about 95% of the C compiler vendors failed
to make the transition to C++, and of the few that did, none of them
implement the same language despite 15 years of trying. (At one point, I
counted *30* different C compilers available just for the IBM PC.)


  Porting C++
 continues to be barely possible but entirely unadvisable.


I stick to pretty basic features of C++ when writing portable code.
Mar 17 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E74EF6C.1050906 viasic.com...

 user domain.invalid wrote:
 Many of us
 thought that early use of Java was a good move, since surely good
 compilers would come along.  However, Sun worked hard to tie Java into
 the virtual machine in such a way that it would be very difficult to
 compile. Mirror classes require a Java interpreter be present.  Swing
 (now JFC) uses them.


True, that pretty much killed off the Java native compiler I did.


 Truth is, I still need convincing before commiting
 to D.  There is only one reasonably stable compiler, and our code has to
 run cross-platform.  At a minimum, I require Sun, Linux and Windows XP.
   If Walter gives up on this, it's surely dead, which doesn't make me
 feel comfortable betting on it.


My making of the front end open source is an attempt to deal with this.


 Also, D does not yet incorporate any
 features that I'm dying to be able to use in EDA software development.
 I don't need GC, and can live with assertions rather than contracts.  We
 already hide the use of almost all pointers.  Features that I think
 would be really great for EDA haven't made it in.  For example, I have
 to emulate dynamic object extensions with void pointers and lots of
 casting.  Dynamic extensions are a requirement in EDA systems built
 around a common object database.  I still can't reuse simple code like
 graph modules very well.  Support for code generators is poor,


How so?


 and we
 have a lot of code generators to make up for short-commings in C.  Also,
 I'm becomming concerned that the huge number of features already in D
 may make new compilers hard to write.


That's another reason why I made the front end open source. It should enable
the proliferation of D compilers.


 All these shortcommings may be resolved.  D is still developing.


Yes, and I thank you for your contributions here!
Mar 17 2003
parent reply Bill Cox <bill viasic.com> writes:
Hi, Walter.

Walter wrote:

Truth is, I still need convincing before commiting
to D.  There is only one reasonably stable compiler, and our code has to
run cross-platform.  At a minimum, I require Sun, Linux and Windows XP.
  If Walter gives up on this, it's surely dead, which doesn't make me
feel comfortable betting on it.


 
 
 My making of the front end open source is an attempt to deal with this.


That's a really smart move.  If I weren't so swamped I'd dive in and 
help with the GCC version.

I read a bit of your source.  It's nice.


Also, D does not yet incorporate any
features that I'm dying to be able to use in EDA software development.
I don't need GC, and can live with assertions rather than contracts.  We
already hide the use of almost all pointers.  Features that I think
would be really great for EDA haven't made it in.  For example, I have
to emulate dynamic object extensions with void pointers and lots of
casting.  Dynamic extensions are a requirement in EDA systems built
around a common object database.  I still can't reuse simple code like
graph modules very well.  Support for code generators is poor,


 
 
 How so?


The ability to spread class and module definitions across multiple files 
would help.  I hate having to read C++ header files, scan for the magic 
comment, and generate code there.  It's no big deal, though.  It won't 
make or break D.

Bill
Mar 18 2003
parent "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:3E76FCB0.2070802 viasic.com...

Also, D does not yet incorporate any
features that I'm dying to be able to use in EDA software development.
I don't need GC, and can live with assertions rather than contracts.  We
already hide the use of almost all pointers.  Features that I think
would be really great for EDA haven't made it in.  For example, I have
to emulate dynamic object extensions with void pointers and lots of
casting.  Dynamic extensions are a requirement in EDA systems built
around a common object database.  I still can't reuse simple code like
graph modules very well.  Support for code generators is poor,


 How so?


 The ability to spread class and module definitions across multiple files
 would help.


I understand the problem you're trying to solve with that, but having a
module be one piece of source text is important for the semantic analysis.


 I hate having to read C++ header files, scan for the magic
 comment, and generate code there.  It's no big deal, though.  It won't
 make or break D.


This sounds like a good application for a custom text preprocessor.
Mar 18 2003