Does D have too many features?

[Alex Rønne Petersen]

On 29-04-2012 01:41, Peter Alexander wrote:
> On Saturday, 28 April 2012 at 23:29:35 UTC, bearophile wrote:
>> Peter Alexander:
>>
>>> f(x) ---> x.f() is not progress in language design.
>>
>> I used to think the same. But Haskell offers "." and $ to chain
>> functions and remove parentheses, F# has the |> pipe operator. In D
>> UCFS is almost equally useful to turn nesting of function calls in a
>> more readable chain. In functional-style code this makes a lot of
>> difference, turning:
>>
>> foo(bar(copy(baz(a), spam(b))))
>>
>> Into:
>>
>> baz(a).copy(b.spam()).bar().foo()
>>
>> When I see 3+ nested parentheses I find it hard to read the
>> expression. While a chain is easy to read.
>
> What D does and what Haskell does are very different things. D has (at
> least) two types of functions: free functions and member functions. UFCS
> makes free functions look like member functions. In Haskell, $ just
> gives you a way of re-ordering precedence -- it doesn't hide anything.
>
> This matters because UFCS in D is deceitful. It makes you think the free
> function is a member function when it is not.
>
> struct Foo { void bar() {} }
> void baz(Foo f) {}
>
> Foo f;
> f.bar(); // ok
> f.baz(); // ok, looks like baz is a member function
> auto pbar = &Foo.bar; // ok
> auto pbaz = &Foo.baz; // error!
>
> IMO, D would be better with Haskell's function calling syntax (of
> course, this would require many, many other syntactical changes).
>
>
>> But in D the main purpose of "pure" is not as optimization tool, but
>> more as a tool to enforce a better coding style, that makes code
>> understanding (and testing simpler), and helps avoid some bugs, coming
>> from using variables from outer scopes.
>
> True, but I'm quite happy to write pure functions without the static
> checking. I do not believe that the safety provided by the static checks
> outweighs the development cost of ensuring you have the correct
> qualifiers everywhere.

In my experience, pure is only hard to use in D due to the runtime and 
standard library not being properly annotated. I don't think anything is 
wrong with the language feature itself.

-- 
- Alex