2015 H1 Vision

Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Sun Feb 1 16:58:51 PST 2015


On 2/1/15 3:52 PM, Jerry Morrison wrote:
> On Sunday, 1 February 2015 at 22:40:49 UTC, Dicebot wrote:
>>>> - Create the D Language Foundation
>>
>> btw I personally think this is single most important point in the list
>> that is necessary to actually moved forward with others in focused
>> manner. But it really depends on how it is defined.
>
> Yes, a production language requires staffing the grunt work like release
> planning & management, soundness analysis, usability, documentation, bug
> fixing, testing, support, library development, tool development, and
> administration. (This must be a common issue for volunteer open-source
> projects.)
>
> But first, people need to get on the same page about whether D is going
> to “cross the chasm” [1] to a production language with many more users
> than developers or remain what looks like a base for language
> experiments and hobby projects. I think a lot of grumpiness in the
> forums stems from this communication gap.

Well put.

> The other big thing missing from the Vision doc is picking a niche,

That may as well come later - or not at all. We don't think it is now 
time to commit to a particular niche.

> *for
> example* a compelling destination for programmers & projects currently
> stuck in C++.
>    * can call a wide range of C++ code [practical transition]
>    * real-time, can run w/o GC pauses [projects that are OK with GC
> already moved off of C++]
>    * familiar, multi-paradigm, fast builds, meta-programming,
> concurrency that doesn't kill you
>    * simpler, predictable, few pitfalls, few special cases, few design
> quirks, orthogonal features
>    * memory-safe, overflow-safe, reliable, secure, low maintenance costs
>
> If you're up for that, it may require an incompatible transition (D3?)
> e.g. to make const non-transitive for C++ compatibility, to rethink
> memory management, and to change or remove incomplete features.

We're not planning for an incompatible revision. I see const 
transitivity a small problem; good style C++ code enforces transitive 
const semantics, and guarantees of STL containers have improved in that 
direction in C++11 (STL containers don't need write locks for const 
methods).


Andrei



More information about the Digitalmars-d-announce mailing list