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 ?

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
gets the job done. Java and C# are about controlling the market
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

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 machine, and is very difficult to compile well.  C# is owned by 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

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 as Java and C# which are otherwise perfectly good languages.

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 machine, and is very difficult to compile well.  C# is owned by 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
>

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

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

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

"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!

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

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