Home

D Programming Language Conference

The first annual D Programming Language Conference is being held in Seattle this week.

You can get a taste by following the live blogging here.

By Ehud Lamm at 2007-08-25 09:46 | General | other blogs | 12754 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Summary ...

It may be interesting that D, as a system level programming language, designed as successor of C++, is getting features that mostly count for functional languages features. D currently supports optional lazy evaluation of function arguments and experimental implementation of variables immutability.

The presentation of Walter Bright and Andrei Alexandrescu presents plans for implementation of pure functions (limiting side effects only to scope of the function). Additional presented features and improvements are hygiene AST macros, compile time reflection, "polysemous" values (delaying identification of expression result type) and others. The Design objectives of planned D features and improvements are:
  • Make writing generic code easier
  • Improve robustness and auditability of code
  • Add support for more programming paradigms
  • Facilitate large-scale development
  • Lay groundwork for supporting parallel programming

All conference presentations can be found here.
By Michal Minich at Sun, 2007-08-26 10:58 | login or register to post comments

Not really a successor of C++

While this language is undoubtly C++-inspired, it can't really be considered a successor since it dropped the very good thing of C++: value-based programming. Simply because it adopted full reference semantics, which have a number of issues (shared ownership -- which was solved with GC, which introduces its own issues --, side effects, and of course concurrency hazards).

Even RAII, one of the other good points of C++ which is still available in D, becomes annoying -- because variables need to be declared as 'scope' variables -- if not dangerous to use. RAII is better with value-based programming, because copying the variable means copying the resource, rather than just aliasing it (and causing dangling pointers).

By Mathias Gaunard at Mon, 2007-08-27 01:57 | login or register to post comments

Re: Not really a successor of C++

I think a language ca aspire to be a successor of another if it provides tools for solving the problems in domain of it's wished predecessor. Not necessarily by implementing all of the features.

It can be understandable that D, as a language designed by evolutionary process (rather than designing before implementation), did not adopted all C++ features. Rather it evolved its own traits (and some issues).

The presentation mentions planned improvements in object model of D – adding overload-able default operators for copy, assign and implicit casts from/to. If I’m not mistaken, this will quite enhance existing value semantics of structures.

I personally don't see a problem using scope keyword when declaring function variables to achieve RAII for objects.
By Michal Minich at Mon, 2007-08-27 10:02 | login or register to post comments

I think it doesn't make much

I think it doesn't make much sense to call it a "successor" since C++ is still evolving as well.

By snk_kid at Tue, 2007-08-28 12:53 | login or register to post comments

What about C++0x? I'd say

What about C++0x? I'd say C++ is still evolving..

By Gavin Harrison at Tue, 2007-08-28 22:10 | login or register to post comments

Interesting

Thanks for the links, I'm eagerly awaiting the macro feature: the current enum in D is quite underpowered (no easy way to print the enum label instead of its value in logs), but current trials to fix this with mixin are too ugly to be useful..

By renox at Mon, 2007-08-27 15:20 | login or register to post comments

Not quite functional either.

D's closures are broken.

The environment of a nested function points to the outer function's stack and continues to do so after the outer function has returned. When a dynamic closure is called, its vars may refer to a now defunct part of the stack (or worse, belonging to some other call). Horrors.

Unfortunately, it isn't merely a problem with the implementation; it is explicitly mentioned in the language reference.

I like many of the language's features. However, looking at the slides, I can't escape the feeling that this is another Groovy-style language kitchen sink in the making.

By Sriram Srinivasan at Tue, 2007-08-28 15:32 | login or register to post comments

Unfortunately, it isn't

Unfortunately, it isn't merely a problem with the implementation; it is explicitly mentioned in the language reference.

Is a reson for this design choice given, or is this simply an error that worked its way into the specification?

By Ehud Lamm at Tue, 2007-08-28 19:44 | login or register to post comments

No reasons.

No, there are no reasons given.

I have the utmost respect for Walter Bright. I suspect, however, that the essential mindset behind the requirements and design is that one shouldn't lose any performance ground to C/C++, and it would be undesirable to go to the heap to allocate a closure.

All speculations, of course. The D folks have run into this problem already and it may be fixed.

By Sriram Srinivasan at Wed, 2007-08-29 07:05 | login or register to post comments

Thanks for the info.

Thanks for the info.

By Ehud Lamm at Thu, 2007-08-30 07:10 | login or register to post comments

D closures fixed

D's closures are broken.

Full closures for D -- "D 2.007 brings full closures to D. I was tired of D being denigrated for not having 'real' closures."

Hmm, maybe you tipped the balance, Sriram? :)

Implementation notes here.

By Jeff Nowakowski at Sat, 2007-11-03 16:51 | login or register to post comments

reason is performance

Walter Bright has mentioned that the reason is indeed to avoid heap allocation. Closures (as delegates) are stack allocated, very fast. There have been discussions to get proper closures without losing the option for stack allocation, through escape analysis or some sort of explicit syntax. I doubt this is a high priority atm though.

By Lutger at Sun, 2007-09-02 12:59 | login or register to post comments