Difference between revisions of "Vision/2016H1"

From D Wiki
Jump to: navigation, search
m (AndreiAlexandrescu moved page Vision/2016H1 (draft) to Vision/2016H1)
m (Fix link)
Line 15: Line 15:
 
;Participation
 
;Participation
  
:We fell short of our 2000 pull requests goal in H2 2015. We have had only [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3AD-Programming-Language+created%3A2015-07-01..2015-12- 1 1378 pull requests]. This is a 10% decline year-over-year compared to the [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3AD-Programming-Language+created%3A2014-07-01..2014-12-31 same period in 2014]. We attribute this to the long time of reviewing many pull requests, which works against a good contributor experience.
+
:We fell short of our 2000 pull requests goal in H2 2015. We have had only [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3AD-Programming-Language+created%3A2015-07-01..2015-12-31 1378 pull requests]. This is a 10% decline year-over-year compared to the [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3AD-Programming-Language+created%3A2014-07-01..2014-12-31 same period in 2014]. We attribute this to the long time of reviewing many pull requests, which works against a good contributor experience.
  
 
;Safety and Memory Management
 
;Safety and Memory Management

Revision as of 09:23, 25 January 2016

Meta

This document discusses the high-level vision for D. It is revised every six months (January and July).

Note: This document focuses on goals the D leadership will personally enable or make happen. Other contributions that don't require their help are always welcome.

Progress in H2 2015

Progress is discussed and measured in comparison with the goals established in the H2 2015 vision document.

The D Language Foundation
The Foundation has been incorporated during H2 with the state of Washington, USA. The employer ID is 47-5352856. We failed to file during H2 for non-profit status, moving this item to 2016H1.
Participation
We fell short of our 2000 pull requests goal in H2 2015. We have had only 1378 pull requests. This is a 10% decline year-over-year compared to the same period in 2014. We attribute this to the long time of reviewing many pull requests, which works against a good contributor experience.
Safety and Memory Management
std.experimental.allocator has been approved and pulled into the standard library.
Created an open mailing list for discussing language design matter in a confined circle of interested participants, initially focusing on lifetime management. Discussions have been stalled after a few dozen posts.
Tooling
Progress on tooling (Brian Schott, Vladimir Panteleev) has been steady but slow. The pattern followed by tools has been to integrate on code.dlang.org, i.e. outside the official tools distributed with dmd.
Library additions
std.experimental.allocator, std.experimental.ndslice.
Brand awareness
Walter and Andrei held a very successful conference in Brasov, Romania. Andrei also gave a talk on D at code::dive in Poland (video, slides).
C++ integration
There has been significant progress on integration of C++ exceptions with D, which is instrumental for tighter integration.
Objective C integration
Significant support for Objective C has been added in 2.069. Currently it’s possible to create bindings for classes and instance methods. DIP43 guides the integration.
Porting the reference compiler to D
The process has been successful and the aftermath very positive.

H1 2016 Priorities

The D Language Foundation
The plan is to file for non-profit status by the end of H1 (approval takes up to 6 months).
Raising participation
We continue being shorthanded with all aspects of D development: top "general", middle "lieutenant", and bottom "soldier". Although a good few programmers in each category have a level of interest in D, most of these don't have adequate amounts of time to commit to working on the language.
We plan to attract steady contributors and teams of contributors to care of specific operations: website, social media, build and test, release process, teaching materials, managing DIPs and submissions, and more. Currently a small core group carries most of these tasks followed by a long tail of occasional contributors. Because for many of these roles there is no clear accountability, the core team needs to solve various unrelated problems on a regular basis, which disperses the focus of the best contributors. Conversely, annoyances such as poor documentation for specific artifacts, typos on the website, minor implementation bugs, etc. go unresolved for a long time and create the false perception that care is not being exercised.
Forum discussions often get into large debates on popular topics, such as naming things or what areas should be the focus of the core team. This may be the effect of many participants having only small quanta of time each. Our approach to improve on that will be to focus conversation on meaningful technical topics, promote contribution over debate, and converting collective insight and participation into progress.
We aim to make it easier for would-be contributors to start improving D, by means of better tooling, better automation, and better documentation. Ideally any programmer getting acquainted to the D ecosystem would get a good understanding of how exactly they could add value to it.
At top level we need to expand the circle of key contributors with power hitters with similar design sensibilities. Currently there is no clear path of "rank advancement" for contributors who want to strengthen their positive impact on D. We aim at encouraging larger and more courageous contributions, such as entire libraries or tools. Part of this is spending time on helping weak contributions. This needs to be balanced with the false notion that any contribution must receive attention in proportion to the effort expended on it. "I wrote a DIP therefore it must be worked on" quickly becomes "There's no purpose in trying a DIP, nobody will look at it".
We're aiming at exceeding 2000 pull requests in H1 2016. Follow this link to track progress. In order to achieve a good rate of improvements for the compiler, runtime, and standard library we need to (a) attract good contributors; (b) make it easy to get involved; (c) give a good sense of growth, accomplishment, and excellence so as to encourage repeat and ever-improving participation.
Safety
Safety remains a primary concern of all work, especially work involving early memory reclamation (below).
Memory management
"No GC" remains a primary concern going forward for the standard library and client code.
We need good language+library support and robust idioms to follow for good no-GC code.
Tooling
Lack of tool support is often invoked by would-be adopters of D. We should focus on adding tooling to the D distributions, starting with dfmt and dfix. Longer term, one key part of it is exposing compiler components (lexer, parser, various checkers) as libraries.
Continue fostering brand awareness
This remains a priority going forward. DConf 2016 in Berlin is slated to be a larger event than before. Andrei will deliver a keynote and a D tutorial at ACCU 2016. Andrei may also give a D talk at NDC 2016 in Oslo. Private courses, video tutorials, and more conference participation are also planned.
Improve language stability and specification
We need a more rigorous writeup of the language specification. At best we'll start a background work of redoing the spec from start that uses "standardese" language, has examples, and covers all of the language properly.
Any language change must be initiated with a DIP that is properly scrutinized.
C++ integration
D code can now catch exceptions raised from C++ code in Linux64. The first header to support in the C++ standard library will be <exception>.
Using from D staple elements from the C++ standard library (e.g. std::vector, std::string, std::unordered_map) is a major direction.
Library additions
Strong library additions should drive both language fixes and improvements, and serve as examples to follow for the entire community. The trio dmd/druntime/phobos should set a powerful benchmark in code quality, project management, and operations.
Smartphones (iPhone/Android)
Alternative compilers already have some level of support for smartphones. That should continue in stride and be accompanied by the appropriate air support from the leadership and community.
Objective-C interfacing is an important aspect as well.

In Search of Champions

Embedded systems
Some community members have expressed interest in using stripped-down versions of D on embedded systems. Work will need to be done to modularize the compilers and runtime to enable such use in tightly constrained systems.