Super-dee-duper D features

[Andrei Alexandrescu (See Website For Email)]

Walter Bright wrote:
> Nicolai Waniek wrote:
>> The main problem I have with mixins/templates and so on is that it
>> enables a programmer to change the "look and feel" of the language
>> completely. What is bad about it? That if you're working in a team
>> someone has a "great idea" and invents his own MyDSL. So what? Everyone
>> else has to "learn" this new DSL. So they spend time on something they
>> would've better spent on coding something else, or fixing bugs... I
>> worked in a team of about 8 persons bugfixing a project with
>> approximately 1.000.000 LoC. The former programmers just seemed to not
>> know how to code (and we programmed using Delphi!!! a language most
>> people like to tell you: "oh, that's a language that shows you how to
>> work structured" - that's totally bullshit!).
>> So on one hand, we had to improve the software as it was used by just
>> too many companies to completely rewrite it - on the other hand we had
>> to bugfix it with a syntax that even didn't look like Pascal. Now what?
>> If we had someone "just for the sake of it" implementing something with
>> his MyDSL, i would've probably killed him!
> 
> I hear you. I also find most uses C++ templates are put to to be 
> incomprehensible - either from programmers showing off, or from working 
> around the severe limitations of C++ templates.
> 
> Another big part of the problem is that templates are just hard to read 
> and understand. If they were as easy to deal with as regular functions, 
> then that difficulty would (I hope) melt away. This is what we're 
> working towards.
> 
> I agree with you on another level - programmers showing off their 
> understanding of the language by some need to use every feature of the 
> language, MAKING SIMPLE THINGS COMPLICATED. To me, *real* programming 
> skill is expressing complicated things in a simple manner.
> 
> One of my (unfavorite) examples of the making simple things complicated 
> is the simple linked list concept:
>     struct Foo
>     {    Foo *next;
>         ...
>     }
> voila, a linked list. But nooo, for some reason (just for the sake of 
> it? <g>), this has to be made complicated, with templates, macros, 
> iterators, akk. There's a place for iterators, but they are overused.

Boy is that not a good example.

 From http://mitpress.mit.edu/sicp/chapter1/node18.html, a quote that
has stayed with me since I first read it (in illegal copy) back in
Romania many years ago:

"We have seen that procedures are, in effect, abstractions that describe
compound operations on numbers independent of the particular numbers.
For example, when we

(define (cube x) (* x x x))

we are not talking about the cube of a particular number, but rather
about a method for obtaining the cube of any number. Of course we could
get along without ever defining this procedure, by always writing
expressions such as

(* 3 3 3)
(* x x x)
(* y y y)

and never mentioning cube explicitly. This would place us at a serious
disadvantage, forcing us to work always at the level of the particular
operations that happen to be primitives in the language (multiplication,
in this case) rather than in terms of higher-level operations. Our
programs would be able to compute cubes, but our language would lack the
ability to express the concept of cubing. One of the things we should
demand from a powerful programming language is the ability to build
abstractions by assigning names to common patterns and then to work in
terms of the abstractions directly."

Your example shows that you are able to make a list, but it gives zero
indication on whether you can express what a list _is_.


Andrei