Does D have too many features?

[Peter Alexander]

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.