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