dsimcha wrote:
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.
Yup. The hard part, though, is figuring out what the magic set of
seminal features should be.
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.
Right. A "simple" language pushes the complexity onto the programmer, so
he has to write complicated code instead. D programs tend to be
dramatically shorter than the equivalent C++ one.
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.
I tried programming in Java.
A friend of mine had an unexpected insight. He used Java a lot at a
major corporation. He said an IDE was indispensable because with "one
click" you could generate a "hundred lines of code". The light bulb came
on. Java makes up for its lack of expressiveness by putting that
expressiveness into the IDE!
In D, you generate that hundred lines of code with templates and mixins.
