Super-dee-duper D features

[James Dennett]

Walter Bright wrote:
> kris wrote:
>> Walter Bright wrote:
>>> 3) Less code == more productivity, less bugs. I don't mean
>>> gratuitously less code, I mean less code in the sense that one can
>>> write directly what one means, rather than a lot of tedious bother.
>>> For example, if I want to visit each element in an array:
>>>
>>>     foreach(v; e)
>>>     {...}
>>>
>>> is more direct than:
>>>
>>>     for (size_t i = 0; i < sizeof(e)/sizeof(e[0]); i++)
>>>     { T v = e[i];
>>>      ... }
>>>
>>
>> Yep, that's great! One of the reasons I like D so much, along with
>> array slicing.
> 
> The C++ version is even *worse* than the C one (for wordiness bother):
> 
>     for (std::vector<T>::const_iterator i = e.begin(); i != e.end(); i++)
>     {  T v = *i;
>     ... }

C++ can, of course, also do (with type-safety)
  for (size_t i = 0; i < size(e); ++i)

> I mean I know the reasons for every bit of the syntax there, and in
> isolation they make sense, but put it all together and it seems to go
> backwards.

C++, of course, has std::for_each(e.begin(), e.end(), do_x);
in its library (though that's weaker than it could be because
of lack of support for convenient anonymous functions/lambdas).

C++0x is very likely to have for(v: e).  It's implemented
in ConceptGCC already. Java already has essentially that,
as does C#.  This really doesn't set D apart (but at least
D isn't falling behind here).

>>> 5) Lisp gets things right, according to what I've read from heavy
>>> Lisp users, by being a language that can be modified on the fly to
>>> suit the task at hand, in other words, by having a customizable
>>> language one can achieve dramatic productivity gains.
>>
>> Yet, Lisp will always remain a niche language. You have to wonder why.
> 
> I'm pretty sure it's the syntax.

Yup, syntax does matter.

[snip]

>>> 8) I've never been able to create usable C++ templates. Notice that
>>> the DMD front end (in C++) doesn't use a single template. I know how
>>> they work (in intimate detail) but I still can't use them.
>>
>> Same here.
> 
> But I have been able to create usable D templates <g>.

The problems are mostly syntactical; writing C++ templates
isn't much harder, by and large, than writing other robust,
reusable, flexible code.  (Which is hard, by most measures.)

Familiarity with Lisp does help when working with C++
templates, it seems.  That might also be true for templates
in D.

[snip]

> It's like Paul Mensonidas being recognized as the "World's Leading
> Expert on the C Preprocessor." Obviously, something is seriously wrong
> with the preprocessor if there's an ecological niche for a world's
> leading expert on it. (By the way, Paul is a very nice fellow and has
> been kind enough to help me iron out several subtle bugs in the DMC++
> preprocessor. As long as we're saddled with that preprocessor spec, I'm
> glad there is a Paul to help!)

I'll second that, though it's offtopic.  My knowledge of
the dark corners of the C++ preprocessor was heavily
influenced by Paul's writing.  (Most of what I learned
just reconfirmed the view that this tool is a beast.)

-- James