D and the world

[Robert Fraser]

Walter Bright Wrote:

> 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.

So, no obfuscated D code contest?