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

Re:A critique (and take a look at Ocaml)

[Chuck Messenger]

Yes -- overloading can be abused. It's the same reasoning people use against macros -- that they can be even _more_ abused. It takes an experienced hand to use them effectively.

Still, overloading, and macros, add a great deal to the language, increasing the possibilities for creating powerful libraries, with simple, intuitive interfaces. If you want a language which protects you from yourself, use Java. But don't expect to be as productive! (he says as he ducks for cover...)

As an example (of overloading), consider the C++ streams library. Imagine having to do:

put(put(put(put(cout, "Value "), valName), " = "), val);

It's horrible! Instead, we can write:

cout << "Value " << valName << " = " << val;

Nice! It's much faster to type, and much more clear (hence more maintainable and less prone to bugs).

In my experience, in general, reducing the number of keystrokes (increasing the conciseness of code) leads, simultaneously, to faster-written, less-buggy, and more-maintainable code.

In general.

Re:No templates?

[TephX]

Oof... believe me, I know about strong versus weak typing. (I posted the parent, but posted it anonymously by accident.) I learned real programming (i.e. not Applesoft Basic) with Scheme, and learned SML last year. SML is just about as strongly-typed as you can get, and Scheme is weakly typed.

Weak typing does have some advantages. I use Perl, which is weakly typed, and the convenience is worth it. But weakly typed languages are slower than strongly typed ones (and this is a fundamental limitation that can't be removed, weakly typed languages have to have runtime checks for types). Also, type errors can catch a lot of common mistakes at compile time rather than runtime (for example, putting arguments to a function in the wrong order will often trigger a type error.)

Overall, I definitely agree that weak typing has some purpose, but for general applications development, strong typing makes for significantly more maintainable code - at a cost to developers, to be sure, but in my opinion a worthwhile one.

Re:Maybe?

[rabtech]

Have you ever tried Visual Basic? I know it gets a bad rap sometimes, because it is VERY forgiving. It is extremely easy to write very crappy code that still works.

However, for those who bother to do the job right, VB can be a very powerful tool, used to create shipping application. (As I personally have done.)

With VB, you don't care about all the "stuff" underneath (which can be a problem when you try to do something that isn't built-in, but there are creative solutions). You just drag controls onto your window, and write the code behind them. Very easy.

VisualStudio.NET is bringing this in two different directions: First, VB gets full access to everything, and is no longer the "bastard" child of the VS family. Secondly, the other VisualStudio languages get a new Forms system similar to VB's -- just drag controls onto the Window, set properties, then write the code to handle the events. Easy and clean.

That's really what the entire .NET runtime is about: moving away from Win32. What is easier for using sockets to listed on Port 80? Fooling with the separate WinSock2 API, or doing "Dim mySocket as New System.Sockets.TcpListener(80)" ?
This message sometimes gets lost because .NET is a very large umbrella. But what it is bringing to the programming side of things is very impressive indeed. An entirely new programming paradigm where everything you ever wanted to do is neatly arranged within the various Class libraries. I know that in and of itself isn't new, but having that kind of support on the OS level IS new.

Microsoft has already stated that when the Win9x code line is pretty much dead, and everyone is writing to the CLR instead of Win32, they are going to make a move to port the CLR to the WinNT Executive (that is NT's native kernel API). Win32 will finally be relegated to "legacy" tech just like DOS interrupts and Win16.

Re:Convince me

[Vanders]

It's unfair to compare a Java UI directly with a native UI.

Why? Users don't care about wether your application has a slow user interface, all they'll do is complain that "This program is slow"

Java has a place, and by extension Java UI's have their place. But saying "Oh well it's O.K for the user interface to be slow, because it will run equally slow across all platforms" is a load of rubbish. If Java code can run just as fast as native compiled C or C++, just why are the Java User Interfaces slow?

Any Java zealots want to clear up the aparent contradiction there?

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 [digitalmars.com]...

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 [ioccc.org] 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 [sun.com] 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 [gnu.org] 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 [geocities.com] which are much much more likely to conform to the standard [sun.com] than the C++ equivalents [cplusplus.com].

SECURITY BY DEFAULT

[zenray]

One thing in this new programming language that needs to be designed in from the ground floor is SECURITY BY DEFAULT. Make buffer overruns impossiable for starters. I'm very weak as a C programmer and just a student of computer security but it woluld go a long way to solve most of the security problems in appliacations if the programming language enforced proper security codeing practices. Maybe everything would be as secure as OpenBSD. Theo should help design D language to be SECURE BY DEFAULT rather than doing a security review after the software is written. Just my opion, I might be wrong.

Re:practical experience implementing compilers??

[hey!]

"Declaration" is an overloaded term in this context.

If you look at the source files, you see that you still have to declare variables (e.g. "int i;").

What you don't have to do is to declare classes in a separate header file, when all the information about the class's public interface could have been gleaned from source file in which the class is actually defined.

The purpose of this, I guess, in C++ is to allow the compiler to layout an object in memory prior to the constructors being called, and generate assembly for class member access, without necessarily knowing where the class is defined or even having access to source at all. Secondarily the class's interface can be determined for compile time checking. I say secondarily, because clearly that isn't the main purpose of class definition headers since they also reveal information about private members and methods, which are of no interest to the client modules.

D is more like Java in that the compiler can do all this without any special help (in the form of header files) from the programmer.

Perhaps somebody who knows java better than I can comment, but I expect that the Java compiler does all its checking by looking for .class files in the CLASSPATH and poking around in them, and presumably the byte compiled files. So you don't need access to source code to use a class. If you wanted to do something like this in C++, you couldn't, because the necessary information probably isn't in the object file format. You would need a new format that performs some of the functions of the ".class" files, or perhaps the compiler could generate the header files for the programmer as his classes are compiled.

In any case, I've never found the C++ way of doing things much of a problem, but if you think about it, it is rather unnecessarily complicated. Every little bit counts.

this isn't progress

[mj6798]

D looks like a stripped down version of C++, limited to the features that an application programmer who grew up in the Windows environment might find useful. But we already have simplified, limited, easy-to-use languages: Java and C#. C++ is a complex language, and it isn't a particularly well designed language, but the complex features that it has are useful and powerful. Language design should go more in the direction of figuring out how to simplify providing those features, not in stripping C++ down to something from the 1960s again. Two thumbs down.

Re:Convince me

[rossjudson]

What you've learned is that shitty programming can run slow anywhere. A well-written Java UI can fly. Do yourself a favor and download JBuilder from Borland. That's a nicely written Java UI, and it's pretty much the same speed as a native UI.

It's unfair to compare a Java UI directly with a native UI. How well does that native UI run on other platforms? Oh yeah, it can't. How well does it run from a web page? It doesn't.

Properly written Java code can approach the speed of pure C, be done in a tenth the time, and be significantly more maintainable and portable.

Great feature, but. . .

[alnapp]

I like the fact that you can embedd code in html and still compile it [digitalmars.com]

Apparently this means "The code and the documentation for it can be maintained simultaneously, with no duplication of effort"

Unfortunately until its "the documentation is automatically created and maintened with no effort" it still won't prevent the junk I'm often buried in

The only thing new is the name

[seldolivaw]

It's a nice name. I like "D" as a name better than C#. But that's all. From the description of the language, it's just Java without bytecodes -- but with "the option" of bytecodes. The major things it does is throw away legacy C compatibility -- making for faster compilers that are easier to write, but not a whole lot of gain for the programmer. However, maybe it would be good to have C++ updated and throw away unnecessary features, and more structured ways of defining things (like the try-catch-finally structure instead of try-catch, which I like the idea of).

Re:Convince me

[Anonymous Coward]

With a smart JIT compiler it's actually possible for it to be _faster_ under some cirumstances as it has runtime information :-) It might seem impossible, but computer performance is so complex to determine that it's possible.

What are his motives?

[deppe]

Go ahead and flame me, but I really think this is silly.

I think this is the work from someone who has worked so long with C and C++ that he thinks Java is useless, and now he's going about trying to write a language that looks so much like Java that it's just ridiculous.

Plus, Java can be compiled without a VM with GJC.

Besides, it's going to be a really hard time implementing a full suite of standard libraries for this kind of language when the C APIs are available because legacy D code will probably have just the same problems as older C++ code has (i.e. not using the std::string etc.).

But hey, if he can pull it off and it works out then why not. But I can't see large organizations adopting this anytime soon.

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

Re:Convince me

[JohnA]

Why, oh, why must people propogate the myth that Java is slow? While that may have been true in 1995, it is hardly the case today.

If you're going to make comparisons, at least get your facts straight