Walter Bright is the man that liked C++ so much, he created the first native C++ compiler called Zortech C++. He then decided the language had grown so much by layering on needed features that it made sense  to look at it afresh and try to design a language that, he says,  ‘gets there in a straight line, rather than try to be compatible with obsolete decisions made 20 or 30 years ago.

He claims that the design of C++ is rooted in its ASCII past, making support of modern requirements like Unicode Transformation Format difficult. He believed that C++ had reached a certain level of maturity; its period of rapid evolution was over so the time was right to see what could be done with a redesign.

‘In 1999, I found myself at a crossroads, and decided that it was therefore the right time to stop grumbling, stop saying “I’d have done it this way”, and put my money where my mouth was’.

“I don’t agree with the notion
that programmers must be
moulded to fit the software,
and that the cure for bugs
is better education”

Out of his development came D, a general purpose systems and applications programming language which he claims is a higher level language than C++, yet retains the ability to write high performance code and interface directly with the operating system API’s and with hardware.

Bright says that D is well suited to writing medium to large scale million line programs with teams of developers.

‘It’s easy to learn, provides many capabilities to aid the programmer, and is well suited to aggressive compiler optimization technology. The D programming language has been carefully designed to improve programmer productivity based on decades of experience programming, working with programmers and development tools.’

Walter graduated from Caltech in 1979 with a degree in mechanical engineering. He worked for Boeing for 3 years on the development of the 757 stabilizer trim system, before switching to writing software, specialising in compilers. He has been writing them ever since, for Pascal, C, C++, Abel, Java, Javascript and D. It was this experience, both as a user and implementer of languages that put him in a good position to design a successor to C and C++.

RM:

What were the fundamental flaws in other languages that drove the development of D?

WB:

Many flaws were the result of the languages being targeted to solve problems that no longer exist, having to deal with technical limitations that have since been overcome, and ideas about what makes a good programming language have progressed.

Examples of these issues include very small available memory, slow processors, inadequate character sets, non-existent or primitive floating point, ones-complement, etc. The easing of these problems opens up a lot more opportunities for language design. Over the years the programming methodologies of the day appear, get everyone excited, then get merged into the mainstream. For example, in the 70’s it was structured programming (getting rid of goto), then user-friendly, then object-oriented, then generic programming, then meta-programming, agile programming, functional programming, etc.

I’ve been doing compiler support for a long time, and through helping users with their programming problems I’ve gained a lot of insight into what language features work well and what causes problems. Trying to set up the language features to emphasize what works and to redesign what causes problems is of very large interest to me. Even the little things help; like:

for (i = 0; i < 10; i++); foo(i);

This loop only executes once. I knew a crackerjack programmer who spent all afternoon struggling with this one, blind to the extra ; that was causing the problem. D solves this by not allowing a ; to follow a for, if, while, etc., condition because those are usually mistakes. Sure, it’s a small thing, but they add up. Another example is not allowing lower case l to follow an integer literal, as in:

x = 10l;

Is that ten long or one-hundred-one? With many fonts the two characters look identical.

RM:

Why did you feel that C++ needed re-engineering and were there any shortcomings in the language that you tried to avoid?

WB:

Probably C++’s biggest issue is its need for backwards source compatibility. This means that while it gets new features, they get layered on carefully in ways that leave the old ways still fully functional. This makes the new features awkward and complex to use.

Probably the largest of these problems D tried to avoid were the lack of a true module system, over reliance on pointers, and the avoidance of problems through convention rather than enforcement.

RM:

Do you think C++ has become too ‘expert friendly’?

WB:

It certainly does take a long time to master C++, perhaps longer than any other language. Some regard this as necessary because C++ is powerful, but I don’t agree. When a feature is proposed for “library writers”, which is a euphemism for being too complicated for regular programmers, I see an opportunity to redesign it to get the same capability in a more usable form. Probably the most epic example of this was the Concepts proposal, which was recently dropped as having become just too complex.

RM:

What are the application areas that D targets?

WB:

In short, any application that would otherwise use C or C++ would be suitable for D. D looks and feels like C/C++, but fewer lines of code are needed, and performance is better. D is most suited to applications requiring native code, small executable file size, and high speed. D has all the features that make C/C++ nice for writing system applications, and even does better by providing direct support for inline assembler.

C and C++ are great programming languages. But they are showing their age – the necessity to support legacy code has made it increasingly difficult to integrate in modern features in a sensible way. D takes a fresh look at the features, syntax, and modern features and refactors the language into a sensible, practical, modern language. D retains the look and feel of C/C++, and is easy to learn by anyone familiar with C/C++. This refactoring enables D to be a more powerful programming language while being a far easier language to learn and implement.

RM:

In his book The Design and Evolution of C++, Bjarne  Stroustroup mentioned Kierkegaard was an influence on your conception of   the language. Has there been any particular human influences in your work? Anyone who especially inspired you?

WB:

Just about everything has influenced the design, it’s pretty hard to tease out one without overlooking many others. But I would have to credit my experience at Boeing designing flight critical machinery for teaching me the principles of how to create fail safe systems, and later on Andrei Alexandrescu for teaching me the theoretical underpinnings of language design. There’s a long list of others who have positively influenced D’s design, too.

RM:

Are there things in your technological career that would you have done differently?

WB:

I certainly wish I’d started sooner in business for myself.

RM:

And what are you most proud of?

WB:

I’m most proud of creating things that others find useful. For example, the design work I did at Boeing has proven to be safe and reliable. The Empire game I wrote still generates regular email from people still using and enjoying the game they bought 25 years ago! How many other games do people play for decades? The large user and developer community that has sprung up around D is very satisfying.

RM:

What do you think would make D the language of choice for system programmers?

WB:

D has both the low level capability needed to manipulate hardware and do system tasks, as well as a full suite of high level capabilities normally only found in languages far removed from the metal. There’s been a large shift towards VM based languages, but my heart and soul is still in systems work! I just like being able to manipulate things directly and exactly.

RM:

Do you think you would ever design a new language from scratch?

WB:

Sure, every compiler writer wants to do that from day one! They usually do it, too, it’s just that most of those languages never get very far for a number of reasons.

RM:

Do you think education is the answer to developing better software and that somehow we get out from the ‘we must do it first no matter how buggy it is’ way of thinking?

WB:

I don’t agree with the notion that programmers must be moulded to fit the software, and that the cure for bugs is better education. Perhaps that may be eventually true, but I see an awful lot of opportunity in designing programming languages to eliminate whole classes of bugs, or at least to minimize their occurrence. Once that has been exhausted, then we can talk about better education for programmers.

RM:

What would be your perfect piece of software and what purpose would you put it to?

WB:

I never think of software as an end in itself. I only think of it in terms of what it can do. The only problem is my ideas for things software can do greatly outpace my productivity in implementing them. So perhaps you could characterize my goal with D is to improve programmer productivity so I’ll have time to write even more software!

RM:

What projects are you working on and that you can tell us about?

WB:

My main focus is working on the D language and compiler. I also teach seminars on compiler construction.