Generality creep

[Andrei Alexandrescu]

On 4/4/19 1:50 AM, Nicholas Wilson wrote:
> On Thursday, 4 April 2019 at 04:25:59 UTC, Andrei Alexandrescu wrote:
>> On 4/4/19 12:24 AM, Andrei Alexandrescu wrote:
>>> On 4/3/19 11:09 PM, Nicholas Wilson wrote:
>>>> I don't think we are going to be able to do this without iterating 
>>>> on the design and closing holes and nuisances that we discover. I'm 
>>>> not saying that it is a bad idea to design up front as much as we 
>>>> can, but we shouldn't wast time getting hung up on design when 
>>>> implementation can give gains to users and guidance to the design.
>>>
>>> I don't think this works for programming language design. In fact I'm 
>>> positive it doesn't. It's the way we've done things so far.
>>
>> Well I'm exaggerating. I mean to say every time we did it that way,
> 
> Examples please?

Shared itself, the postblit, lazy, properties, alias this - are all 
"first-order thinking" ideas that are not bad, but fail to take into 
consideration second-order interactions and their consequences.

(A good read: https://fs.blog/2016/04/second-order-thinking/)

Language design is all about second-order thinking.

>> the result hasn't been good.
> 
> e.g. DIP1000 was bad, not because it was iterated upon to fix the holes 
> in it, but because the changes were not communicated properly and not 
> documented. I suggest we don't make those same mistakes again.

DIP1000 is actually an example of second-order thinking. Walter pored 
over it for months before writing and implementing it.

So are the recently-introduced copy constructors. We had what we thought 
was a workable design at probably one dozen times during the process. 
All had large flaws.

Incrementalism is an anti-pattern in language design.