On Friday, 19 December 2014 at 11:39:08 UTC, Joakim wrote:
On Friday, 19 December 2014 at 10:04:34 UTC, Walter Bright
wrote:
On 12/18/2014 1:39 PM, Vic wrote:
But this is not the culture of the creators. They think
adding features is fun.
I spent most of my time saying "no" to new features and trying
to find ways to support things without adding features.
I think his point is that you haven't said "no" enough. ;) A
tough job, but then BDFL doesn't come without its pains.
I don't think the problem is saying no here.
The problem is that many feature are incomplete or have holes or
are not orthogonal to each others. Let me take 2 simple examples :
- type qualifiers are transitive. Except for delegate's context.
- There is no implicit sharing. Except via delegate (because of
the above mentioned point), exceptions and promotion of pure
function's result.
The problem with having these holes, is that you can't rely on
anything. That makes it very hard to write reliable library, or
to add new features as you get a myriad of special cases all over
the place.
Sometime, fixing these holes require adding new feature, or
extending a bit existing ones. That is fine as this new thing
will allow for closure of what is already open. This is a
beneficial addition and saying no would be a step back.
In other situations, adding new feature simply extends the
language and create new specials cases. In which case, no or
later is the appropriate answer at this point.
