== Quote from Walter Bright (newshou...@digitalmars.com)'s article > dsimcha wrote: > > Sometimes I feel like there should be a law similar to Greenspun's Law for > > language design: > > > > Any sufficiently long-lived language that promises to be "simpler" than C++ > > and D > > will grow to contain an ad-hoc, bug-ridden, informally specified, slow > > implementation of half of C++ and D. > The dogged inventiveness of the C++ community never ceases to amaze me. > Someone always finds a way to make a library to support some paradigm. > Look at all the things Boost does. > The problem, though, is the result is often just so strange I'd rather > do without. Sometimes, you just need to improve the language to support > things better.
Right, but sometimes (though certainly not always) it's better to provide a meta-feature that solves a whole bunch of problems (like better templates) and then solve the individual problems at the library level, rather than add a language feature specifically to address each need. One thing D does very well is allow you to do the same kind of metaprogramming solutions you would do in C++, except that the result doesn't suck. For example, std.range implements functional-style lazy evaluation as a library, and does it well. The point is that, if you can't deal with the complexity of having real templates, you better be prepared for the complexity created by not having them. Having never done it before, I really cannot imagine how people get any work done in a language that doesn't have either duck typing or good templates. It's just too rigid. It seems like modern statically typed languages like Java and C# end up adding tons of ad-hoc workarounds for lacking either of these as well-integrated language features. The best/worst example is auto-boxing.