[Home]
[Search]
[D]
FAQ
The same questions keep cropping up, so the obvious thing to do is
prepare a FAQ.
Why the name D?
The original name was the Mars Programming Language. But my friends kept
calling it D, and I found myself starting to call it D, so finally I
accepted reality and global searched/replaced the documents from Mars to D.
When can I get a D compiler?
I'm hard at work on one. I hope in a couple months. I had not anticipated
being slashdotted.
What about templates?
Templates were not in the original plans for D. C++ was wildly successful
even before templates were added, and Java is wildly successful without
templates. The feedback I've been getting, however, is that D will not
be successful without some form of templates, so in they go.
Why emphasize implementation ease?
Isn't ease of use for the user of the language more important? Yes, it is.
But a vaporware language is useless to everyone. The easier a language
is to implement, the more robust implementations there will be. In C's
heyday, there were 30 different commericial C compilers for the IBM PC.
Not many made the transition to C++. In looking at
the C++ compilers on the market today, how many years of development went
into each? At least 10 years? Programmers waited years
for the various pieces of C++ to get implemented after they were specified.
If C++ was not so enormously popular, it's doubtful that very complex features
like multiple inheritance, templates, etc., would ever have been implemented.
I suggest that if a language is easier to implement, then it is likely also
easier to understand. Isn't it better to spend time learning to write better
programs than language arcana? If a language can capture 90% of the power of
C++ with 10% of its complexity, I argue that is a worthwhile tradeoff.
Why is [expletive deleted] printf in D?
printf is not typesafe. It's old fashioned. It's not object-oriented.
It's not usable with user-defined types. printf is guilty as
charged. But it's just so darned useful. Nothing beats it for banging out
a quick dump of a value when debugging.
Note: printf is actually not really
part of D anyway, but since D provides easy access to C's runtime library,
D gets it when needed.
Will D be open source?
The long term success of D will require it to be open source. The plan is
to first get an implementation working, and then make the front end available
to people who would like to merge it with GCC.
Why fall through on switch statements?
Many people have asked for a requirement that there be a break between
cases in a switch statement, that C's behavior of silently falling through
is the cause of many bugs.
The reason D doesn't change this is for the same reason that integral
promotion rules and operator precedence rules were kept the same - to
make code that looks the same as in C operate the same. If it had subtly
different semantics, it will cause frustratingly subtle bugs.
Why should I use D instead of Java?
D seriously departs from Java. Here are some of the ways,
in no particular order:
- D has out and inout function parameters, i.e. functions can return
multiple values.
- D has enums.
- D's floating point is the best available on the target machine.
- D has design by contract.
- D has a direct interface to C and operating system APIs.
- D has lightweight structs.
- D has strings implemented as arrays, not objects.
- D has broad basic type support.
- D has imaginary and complex floating point types.
- D has typedefs.
- D does not do dynamic class loading.
- D has turn-offable array bounds checking.
- D has support for assert()s and debug statements.
- D works with your other existing dev tools (make, linkers, debuggers,
etc.)
Java is designed to be write once, run everywhere. D is designed for writing
efficient native system apps. Although D and Java share the notion that
garbage collection is good and multiple inheritance is bad , their
different design goals mean the languages have very different feels.
Why have an asm statement in a portable language?
An asm statement allows assembly code to be inserted directly into a D
function. Assembler code will obviously be inherently non-portable. D is
intended, however, to be a useful language for developing systems apps.
Systems apps almost invariably wind up with system dependent code in them
anyway, inline asm isn't much different. Inline asm will be useful for
things like accessing special CPU instructions, accessing flag bits, special
computational situations, and super optimizing a piece of code.
Before the C compiler had an inline assembler, I used external assemblers.
There was constant grief because many, many different versions of the
assembler were out there, the vendors kept changing the syntax of the
assemblers, there were many different bugs in different versions, and even
the command line syntax kept changing. What it all meant was that users
could not reliably rebuild any code that needed assembler. An inline
assembler provided reliability and consistency.
Copyright (c) 1999-2001 by Digital Mars, All Rights Reserved