Trusted Manifesto

[Zach the Mystic via Digitalmars-d]

On Monday, 9 February 2015 at 11:43:00 UTC, Walter Bright wrote:
> On 2/9/2015 2:54 AM, John Colvin wrote:
>> It seems to me that rules 2 and 3 could be helped along by 
>> tooling (compiler or
>> external).
>
> Sounds good, but I'd like to see how this works in practice 
> before going further with it. The nice thing about this 
> proposal is it involves no language changes. It'll allow us to 
> gain experience before committing to language changes.

Until you said this, I was feeling bad that language changes were 
just completely off the table. I'm not a long-term member of the 
D community, but a lot of the excitement I get from following D 
is its "relentless pursuit of perfection", to borrow someone 
else's slogan. I see a surprising willingness from the early 
adopters to endure breaking changes for the sake of the long run, 
and I feel like the pursuit of perfection should utilize this 
willingness as much as possible. (This might be one of the 
language changes which is "dfixable", granting it significantly 
lower switching costs.)

That said, I really like your approach. It's like you're building 
the scaffolding first, and willing to build the statue itself 
(i.e. language changes) later, should the scaffolding prove too 
shaky.

I think the risk here is that a number of users will commit to 
the scaffolding, only to find their code saturated with it when 
it is found to be inadequate. To accommodate this risk:

1. Adopt a tone of experimentation, rather than a tone of 
authority, when imposing these rules. This will help people 
understand the risks and encourage them to give feedback.

2. Bear in mind an escape hatch. Try to imagine how a codebase 
which enforces these rules might transition out of them, should 
it become necessary.

As to the rules themselves, they seem like an admirable attempt 
to do what's possible within the existing language, to which I 
have no opposition, assuming they are found in unbiased 
assessment to work.