Leancode

The Future of D talk by Walter Bright and Andrei Alexandrescu was spread into two parts: kicking off the first day, and closing out the second. A brilliant ploy to keep everyone at the conference in their seats through both the days. So this post is notes just from the “Day 1″ potion of the talk.

The features discussed in this talk are not in D 1.0, and they’re just under consideration for D 2.0. In many cases, it was clear there was ongoing discussion on the details. I believe slides will be posted for all talks, and possibly video. Links will be provided in future posts.

The notes for these posts were taken live, but the posting came a day or two after. And I’m just a part-time language junkie, so I may encode some of my own misunderstandings or bad vocabulary here — those errors are mine, not any of the speakers! And apologies in advance for any errors, as the notes were raw. Now back to the talk …

D 2.0’s Design Objectives

While D obviously has its roots in being a “better C++”, the goal is to be non-religious and do what’s simplest and what works. That includes providing features to support other programming paradigms.

Someone from the crowd asked, “What paradigms are you missing?” Walt answered, “For example, more support for functional programming” — especially for the purposes of compiler-supported parallel programming. And promised more info through the talk.

D’s Design: Principled Approach

• “No issue left behind”
• Leave as few dark corners as possible
• Have good engineering rationale for those that do exist (e.g. what’s the type of adding a signed and unsigned integer?)
• Avoid the “onion in the varnish” syndrome (loosing reasons why things were done) — hope to move beyond old mistakes that were encoded by inertia
• Avoid the “what the heck we were thinking?” question

The Rule of Least Astonishment – when you learn a rule, it’s generalizable

One funny term showed up on a slide. “polysemous values” – Some confusion, then laughter from the crowd when walt and andrei admitted this was a newly created word (in this case, to describe values with late determination of type). Must be meaningful in Romanian. [actually, as pointed out in comments, it is a real word, and an apropos one at that]

Features for Modular Development

• Unified Function/Template Overloading
• Uniform Function Call Syntax

  The definition of foo(a, args …) allows the function to be called as a.foo(args, …)

  Enables more of a model where the class designer implements the minimal amount that works. Extra sugar can be implemented outside of the class. (e.g. import matrix; import eigens;)

• Function Overload Sets
• nothrow

  Java does static checking of exception specifications. C++ does mix of static/dynamic. People hate both. nothrow decorates that a function does not throw exceptions.

• Pure Functions – “pure” keyword

  Can’t read any non-const global data. Can’t write any global data, can’t modify anything reachable through its arguments, may modify only its own variables and stack. May throw exception.

  What can we do with Pure Functions: common subexpression elimination (don’t need temporary variables to call same fn with same params multiple times), can be reordered and scheduled by the compiler, can be automatically parallelized, can be memoized (prior calls stored in hash cache), can be tabulated (all possible values pre-calculated at compile time for lookup)

Part 2 (upcoming)

Object Model Improvements, Simplifying Code, Generic Programming, and Standard Library will be covered in part 2 of the talk.