The D Programming Language

dereferenced writes: "Walter Bright, author of the original Zortech C++ Compiler and the free (as in beer) Digital Mars C/C++ Compiler, has posted a draft specification for a new programming language that he describes as "a successor to C and C++". It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe its time for a new language born out of practical experience implementing compilers."

Comments

Re:Convince me

[IsleOfView]

I'm afraid I have to disagree. I'm a pretty strong Java advocate, but I still don't feel that it's ready for desktop use because of Swing performance issues. I spoke with several of the engineers that worked on JBuilder while I was at JavaOne this year. They spent a *LOT* of time writing custom classloaders, etc. to make their GUI so snappy. JBuilder is a spectacular example of a well written Java GUI, but I don't know if it would be reasonable to say that just anybody could write something like it in 1/10 the time of some other language.

Now on the server...that's a totally different story. I write server apps all day in Java --- my development times are SLASHED from what they would be in C/C++, or even CGI's. Maintenance and documentation are a breeze, and performance is fabulous. Java really has done great things on the server.

can you say "Java?"

[dobratzp]

from the overview page...

features to keep:

• compile/link/debug development model
• Exception handling
• Runtime Type Identification
• link compatibility with the C calling conventions

All except the last is contained in Java.

features to drop:

• C source code compatibility
• Link compatibility with C++
• Multiple inheritance
• Templates
• Namespaces
• Include files
• Creating object instances on the stack. In D, all objects are by reference.
• Trigraphs and digraphs
• Preprocessor
• Operator overloading
• Object oriented gradualism
• Bit fields of arbitrary size
• Support for 16 bit computers

This seems to be precisely the parts of C++ that Java also does away with. Furthermore, the C preprocessor is not strictly part of the C language and in fact many other programming projects use cpp for simple cut and paste includes of their favorite language. When I first read about trigraphs, I couldn't wait to try them out to make some extra obfuscated code, but alas the C compiler I was using didn't support them. In fact the lack of standards compliance is one of the main drawbacks to programming in C++ and C. If my Java code compiles on sun's compiler, then I can be assured that it will also compile on any other compiler claiming to compile Java code.

The author also mentions that D will not have any bytecodes. From a strict perspective, the Java programming language and the Java VM are two different standards and just because you typically compile Java code into (confusingly named) Java byte codes, doesn't mean you can't use one without the other. For example, anyone (who is insane) can pick up a copy of the Java Virtual Machine Specification and a hex editor and make some syntactiacally correct class files. More realistically though, java bytecodes are often targets for compiler construction classes. Also, if you use the GNU Java Compiler you can compile programs written in the Java programming language directly into machine code.

While 90% of the description of this language screams Java, there seem to be some of the more useful features of C++ thrown in (typedefs, scope operator, etc.). The only way for this to be successful, is to finish standardizing the language as soon as possible and get a reference compiler for it so it leaves the realm of theoretical vaporware. Perhaps Java might have looked more like this if the language design was revisited. However, Java has lots compilers which are much much more likely to conform to the standard than the C++ equivalents.

Re:practical experience implementing compilers??

[JabberWokky]

At this stage, languages are meant to make thing easier for the programmer.

He's talking about making the compiler do all the work - for instance, there are no headers, as declarations are lifted from the source. For that matter, modules and libararies and source are treated the same. I think that he *might* be talking about features that would require a new object format, and thus a new linker.

I really don't like his ".html" file idea: code inside a html file is compiled by ignoring everything but tagged bits. The concept is to use html to document and compile the code right in the documentation. Personally, I prefer to generate documentation from the code. A language that implements context sensitive comments that can be compiled into various types of documentation would be, IMHO, a very good thing. As it is, systems like doxygen seem to work okay, but if it were built into the language, you could even dump documentation out of modules on the fly. Nifty in an IDE environment, or makefile driven dev when you want to check that version 2.2 of openfoo() does the same thing that 2.1 openfoo() did.

--
Evan