D and the world

[Walter Bright]

Don Clugston wrote:
> I think Nemerle will suffer from this. IMHO, being able to define 'for' 
> in the language itself, has no benefit in practice; the set of useful 
> control constructs is very well known. If it's useful to everyone, it 
> should be rigidly controlled by the language; otherwise you get 
> confusion and incompatibility.
> I suspect that in D, metaprogramming will be used almost exclusively for 
> domain-specific languages.

I agree that too much flexibility in a language is a bad thing. Imagine 
if you could redefine everything in D. Taken to the limit, that means 
that every random sequence of characters could be a valid program! This 
is just not useful.

C++ suffers from this problem somewhat with the preprocessor. The 
problem is recognized, and C++ programs that do things like:
    #define BEGIN {
    #define END }
are frowned upon.

Back in the 80's when people wrote a lot of assembler, MASM had a fairly 
powerful preprocessor. Lots of people essentially invented their own 
languages, that preprocessed down to assembler. Microsoft shipped one of 
these as an include file with MASM.

Lots of people found it impenetrable. A friend of mine had a lot of 
difficulty with it, and finally resolved the problems by assembling the 
code with MASM, running OBJ2ASM on the result, and then using OBJ2ASM's 
output as his new source code. *Then* he understood what was going on <g>.

A language needs to have common reference points, some reliable 
touchstones that people can look at and say "I understand that". It's 
why D, for example, has the debug statements. Sure, you can do the same 
thing with version and other constructs. But if you've managed C++ code 
for a while, everybody comes up with a different way of doing #ifdef 
DEBUG, all different, but all functionally about the same. It just 
causes problems when combining projects. So by wiring a debug statement 
in to the compiler, one encourages a common way of doing the common task.

The same goes for unit tests.