Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

On Saturday, 9 July 2016 at 22:20:22 UTC, Timon Gehr wrote:
> On 09.07.2016 06:39, Andrew Godfrey wrote:
>> On Friday, 8 July 2016 at 21:23:24 UTC, Timon Gehr wrote:
>>> On 08.07.2016 04:25, Andrew Godfrey wrote:
>>>>
>>>> Another example is "return" used for monads in eg Haskell - 
>>>> even if it
>>>> only has one meaning in Haskell, it is too mixed up with a 
>>>> different
>>>> meaning in other common languages. D's "static if" - which 
>>>> is a killer
>>>> feature if I ignore the keyword - gives me a similar feeling 
>>>> (though
>>>> it's much less egregious than "return" in monads).
>>>
>>> 'return' in Haskell is perfectly fine.
>>
>> This (long) talk does a good job of explaining the problem 
>> with using
>> the name 'return' in monads.
>>
>> https://www.infoq.com/presentations/functional-pros-cons#downloadPdf
>> ...
>
> The reason you linked to this (long) talk instead of a more 
> digestible source is that the presenter manages to bring across 
> his flawed argumentation in a way that is charismatic enough to 
> fool a biased audience.
>
> It's a reasonable name. 'return' creates a computation that 
> returns the given value. This is a different corner in language 
> design space, why should C constrain Haskell's design in any 
> way?
>
>> Others have said it shorter.
>
> Thanks for providing the links to that material.
>
>> I took this example because it crosses
>> languages. Of course we can't avoid clashing with other 
>> languages, there
>> are only so many keywords to use. But there's definitely a 
>> principle
>> here worth considering, that is if you care about D adoption.
>> ...
>
> I was complaining about the cheap shot at Haskell. This has 
> become way too fashionable.

Sorry I chose such a charged example. It's not a cheap shot in my 
case, I have waded through a number of "monad tutorials" and 
criticisms of monad tutorials, and that talk summed up my 
experience. But I really can't claim that monads would be easy to 
learn if they used better naming.
Easier maybe, but they could still be difficult.

Actually maybe Haskell is more relevant as an example to talk 
about "overreaching features" - like Haskell's lazy evaluation. 
In D, GC, auto-decode, and dynamic arrays have overreached IMO. 
But I'm hard pressed to think of something to write in a 
long-term vision about that. (E.g. I like how Phobos is adopting 
ranges. Wouldn't want to slow that down. But maybe we're blind to 
the downsides!) So... you're right, I have no useful suggestions 
to make after beating on Haskell. :)