|Why D isn't Java?|
|By Daniel Yokomiso|
Since its inception D has strived to be a "better C". Although this looks similar to early C++ goals, D isn't an extension to C: source code compatibility with it was discarded together with all associated syntax and semantic problems. Where does this leave us?
D follows the tradition of the C-like languages (C, C++, Java and C#) using similar constructs and declarators. This snippet is valid in all of them:
Programmers familiar with any of these won't have many problems learning D.
If D is C with classes without C++ complexities, how is it different from Java?
The similarities list could go on and on, listing concepts and keywords. Both share an object model and C-like syntax. Now the question is: "How are they different?"
The main difference lies in intent. Java supports and mandates the object-oriented paradigm, with few exceptions. For example, every function must be defined as some class's method, leading to static methods, single method classes and utility classes. Everything must be an object (except primitives and their ilk). On the other hand, D just support the object-oriented paradigm; if you want plain functions or data structures they are available. Everything could be an object, but if you think different it's OK too. D helps you get things done without getting in your way.
While Java intends to be an application programming language, D was designed to be a system programming language too. There are several features in D, either "unsafe" or "too low level", included to allow system programming. These features are non-existent in Java, for reasons so strong that any language including them isn't a Java derivative. I will highlight the most important ones and their role in D:
The last four features make D both powerful and unsafe, so use them judiciously.
But supporting C programming practices isn't the only thing that makes it different from Java. D's creator, Walter Bright, used almost 20 years of experience on compiler writing as D's design guideline. The syntax has very few ambiguities, leading to very fast compile times. The semantics for language constructs leave plenty of room for optimizing compilers. Portability of semantics is a concern that permeates the language design. Also, efficiency of execution is one of the main goals: D is suitable for industrial strength, real-time software. Finally D is an evolving language. Anyone can drop in at news.digitalmars.com and help shape the language or the basic libraries. Suggestions and criticisms are welcome.
The future will part Java and D even more. The current D implementation (DMD 0.58) includes several features missing in Java, including covariant return types, delegates, templates (true generics, instead of type erasure) and Design by Contract. Most of these are currently RFE's in Java Developer's Connection, and even when Java develops these features they'll have to live with legacy libraries written using older syntax and semantics.
For another view on Java vs. D check the Digital Mars D site.
Copyright (c) 2003 Daniel Yukio Yokomiso. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at GNU Free Documentation License .