Difference between revisions of "Vision/2016H1"
m (Category:Vision Statements) |
|||
(One intermediate revision by one other user not shown) | |||
Line 7: | Line 7: | ||
== Progress in H2 2015 == | == Progress in H2 2015 == | ||
− | Progress is discussed and measured in comparison with the goals established in the [ | + | Progress is discussed and measured in comparison with the goals established in the [[Vision/2015H2|H2 2015 vision document]]. |
;The D Language Foundation | ;The D Language Foundation | ||
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% | + | :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%3Adlang+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%3Adlang+2014-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 | ||
− | :<tt>std.experimental.allocator</tt> has been approved and [https://github.com/ | + | :<tt>std.experimental.allocator</tt> has been approved and [https://github.com/dlang/phobos/pull/3405 pulled] into the standard library. |
:Created an open [http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study 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. | :Created an open [http://lists.puremagic.com/cgi-bin/mailman/listinfo/dlang-study 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. | ||
Line 64: | Line 64: | ||
: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". | :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 [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user% | + | :We're aiming at exceeding 2000 pull requests in H1 2016. Follow [https://github.com/pulls?utf8=%E2%9C%93&q=is%3Apr+user%3Adlang+created%3A2016-01-01..2016-12-31 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 | ||
Line 111: | Line 111: | ||
: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. | :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. | ||
+ | |||
+ | [[Category:Vision Statements]] |
Latest revision as of 05:40, 18 May 2018
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 are still shorthanded with all aspects of D development: top leadership, core team, heavy-hitting collaborators, and occasional contributors. Although a good few programmers suitable for 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 is a primary concern of all work, especially work involving early memory reclamation (below). Our main challenge for H1 2016 is to create a combination of language and library support for @safe reference counting. We would also hopefully support ownership patterns such as uniqueness with borrowing.
- Memory management
- "No GC" is 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.
- Foster brand awareness
- Still 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.