DMD 0.170 release

[Bill Baxter]

Walter Bright wrote:
> Oskar Linde wrote:

>> It could also simplify the core language.
> 
> 
> foreach_reverse was pretty trivial to implement. All the machinery was 
> already there.
> 
>> What is design if not the pursuit of simplicity?
> 
> 
> Simplicity is sometimes an elusive goal. For example, D started out with 
> a simple syntax for function literals. Nobody used it, nobody even 
> noticed it, people kept asking for the feature even after I pointed it 
> out to them that D had it. Then, I figured out a way to eliminate some 
> of the extra syntax for it, and voila! suddenly it gets noticed. This is 
> even though the newer style is harder to parse and implement.
> 
> I also remember a thread here about D versus Ruby, and how everything 
> was so simple in Ruby. It didn't matter that I showed how it could be 
> done in D, it appeared to be simpler in Ruby, and that apparently made 
> all the difference.

Definitely.  Simplicity of the language and simplicity of the 
implementation are NOT the same thing.  What matters most to USERS is 
the the conceptual simplicity of the language itself.   Not how many 
hoops the compiler writer had to jump thorugh to make it look simple. 
Sometimes a simple conceptual model goes hand-in-hand with simple 
implementation.  Sometimes it doesn't.  A good example of the former is 
Scheme.  A good example of the latter is maybe Boost::Spirit, to pick an 
example from recent discussion, though it doesn't do that great a job of 
appearing simple (but much simpler than the underlying implementation). 
  A better example is probably pure OO languages that make everything an 
object, including things like number literals.

The thing to strive for is a simple conceptual model.

Hmm, rereading this though, I think you'd argue that you didn't change 
or simplify any "concepts" you just changed syntax.  Could be.  But I 
think there is a connection between the two.  Clumsy syntax can cloud 
the underlying clarity of the concepts.   Just like the boost::spirit 
parser,
    real_p >> *(char_p(',') >> real_p)
is the same thing as EBNF
    real (',' real)*
but one makes the concept a lot easier to see than the other.

Also -- and I think you've noted this before yourself -- end users often 
go for local optimizations.  In the short term they want a fix to the 
immediate problem they see.   But that's not a good way to design a 
language.  You want the global optimum.

--bb