My questions are in bold, his answers in normal type.
When you aren’t hacking D, what do you do to pay the bills?
I am currently at a financial services firm developing enterprise-level investment management and accounting software.
Before you found D, what was your programming background? Which languages were you most familiar with and which was/were your preference?
The job I remember most fondly was one in R&D for a switched long-distance carrier, which mostly involved developing custom applications for a high-volume telephony system. The remainder of my personal and professional background is fairly broad, but the common thread seems to be distributed problem solving. I most enjoy projects which require some form of communication, be it in-process concurrency, distributed server platforms, or social AI.
Before D my programming language of choice was C++, and C++ remains the language I use most often professionally. C++ is an extremely powerful language, but its support of a broad array of programming styles and tendency towards non-obvious syntax tends to complicate its use in large projects. Some of the other programming languages I’ve used professionally are Pascal, C, and Java.
How and when did you first learn of D? What was it about the language that hooked you?
I first learned of D from a Slashdot article a few years ago. At the time, my issues with C++ had really begun to crystallize and D seemed to address them all in a truly elegant manner. I was an instant convert.
What are some things you really like about D? What don’t you like about it?
I most like that D is a systems programming language but doesn’t feel like one — it is this breadth of application that makes it most appealing to me. Some of the language features I find most appealing are slicing, nested functions, delegates, contract programming, and optional garbage collection. Much of the rest is difficult to quantify. For example, D seems to naturally lend itself to producing elegant code. This is very important to me, but it is impossible to point at one or two features and say “this is why.”
Many of the things about D that I didn’t like have been changed or fixed in the time since I first discovered the language. However, mixins still feel like an unfinished feature and also raise concerns about code readability.
If you could add one new feature to D right now, what would it be? What other features do you think would be useful to have?
It’s not a language feature, but I would like a production debugger that works with all of D’s features. Classes, templates, mixins, the lot of it. I’ve gotten quite used to printf debugging since discovering D and I really don’t mind it too much, but there are times when printf alone won’t do.
Aside from that, I’d like to eliminate the differences between constructing different types of data. It’s not a big thing, but I find it occasionally annoying that concrete types don’t support ctor syntax, for example. Another feature would be some way to determine the size of a class at compile-time. I’ve also considered requesting built-in “placement new” support, though I haven’t given this last issue enough thought to be certain it is truly necessary.
Long before Tango, you created Ares as an alternative to Phobos. What was it that first motivated you to do so? What were your goals for the project?
Ares began as an attempt to provide the community with a proving ground for standard library features before submission to Phobos. The original idea was that much of the evaluation and review of code could be handled by the community in an attempt to offload some of the work it appeared Walter might otherwise have to do himself.
Once the project got off the ground however, I began inspecting the innards of Phobos, hoping to formalize the requirements for a third party to implement their own standard library for D. I finally concluded that the “all in one” approach of Phobos made such third party development impossible, so I decided to change that. Ares ultimately became a project to clearly separate and define the responsibilities of three parties: the compiler writer, the systems programmer, and the standard library developer.
As I understand it, your role in Tango is fairly low-level, whereas Kris works at a higher level. Could you clarify that? How are design issues and implementation details worked out?
Our roles were largely defined by what each of us contributed to Tango when the project was conceived: Kris had a robust user-level library and I had experience with the innards of the D runtime. This has given each of us a somewhat different perspective on library design, and I think it has been helpful in our design discussions, which are essentially continuous. As a result, I think it would be fair to say that if we didn’t work together well, Tango would never have been realized.
How has Ares influenced the development of Tango? Is it fair to say that the core of Tango is Ares++, or has it gone in a different direction?
The philosophy behind the Ares design was to produce a modular and configurable runtime on top of which to build a user-level D library. The original intent was simply to provide more structured support for D library developers, but the project ended up attracting developers who needed low-level control of the D runtime for one reason or another. One of my primary goals with Tango was to improve support for this type of development, and I am quite satisfied with the result.
Tango has come quite a long way in a rather short time and is still evolving. Are there any features currently missing from Tango that you would like to add? What can we expect to see in future versions?
As D is a new language, the D programming community contains a large number of library developers and other “pioneers” compared to some of the more entrenched programming communities. Also, recent exposure to Ruby Gems and similar projects have provided useful insight into some ways a completely modular library might be realized. With Tango, we are attempting to unify these ideas by providing a framework for cohesive development as much as we are a robust, user-level library. It is my hope that this will encourage the D community to continue amazing us with their work rather than stifling development because Tango “already does that.” Once Tango reaches 1.0, I suspect much of our library development work will shift into separate projects designed to integrate with or to extend Tango, but they will not be bundled with Tango releases. This places our work on non-essential features on the same footing as that of the community as a whole, and will encourage us to make the distribution and maintenance of external packages as easy as possible.
Aside from Tango, which D libraries and/or tools do you regularly make use of?
Almost none, to be honest. There is a lot I would like to do with D, but currently my free time is dominated by my work on the Tango core. I hope that once Tango reaches 1.0 that I will be able to spend more time on projects that are more immediately visible to users.
Are there any specific, and currently unimplemented, libraries or tools that you would like to see developed in the future? Any you’re thinking of implementing?
Most of my work involves network and database programming, so either of those are likely candidates for future development. I am also very interested in concurrent programming, artificial intelligence, and compiler design, so any of those are possibilities as well.
I’d like to thank Sean for taking the time to participate.