I'm afraid the issue is bigger.
One major criterion, for instance, is the basic question how we
attribute weights to the involved entities.
C had a clear background. There was a new system (PDP11) and a
need to use it. Memory was little and strongly limited, the
typical use was quite modest (considerably less than what we
today have on our mobile phones), processor power and capability
was very low and very expensive, etc.
This, ladies and gentleman, is quite simple not anymore and
adequate approach.
Don't get me wrong, I'm not on the side of the other extreme
("Who cares about processor time and memory"). But the world has
very considerably changed and so has computing. Features that
would have seemd miraculous in 1970 are low standard today and -
very importantly - the whole world had very considerably gained
in complexity.
If I need to programm a MPC430 or even an STM32F4, I'll use C,
period. There *is* a solution for jobs with very tight
constraints, we just don't need a new language for that.
If, however, I have to design and build a solution that works on
different OSes incl. mobile phones and spans over a large network
then I won't use C.
Furthermore, we have seen again and again how unreliable humans
are at certain jobs. Just think "virus","buffer overflow" and a
gazillion of other problems stemming from two reasons, a) lack of
professionality and b) lack of perfection, where perfection is
very much dependant on working tediously diligently and
stubbornly (in other words, somethings that computers are *way*
better at than humans).
Templates just don't cut it, period. Templates are
ultra-yesteryear and proven to be troublesome, no matter how
smartly you implement them. It's just not acceptable that a
language in 2013 (in that regard) doesn't offer dimensionally
more and better than what I could do with Brief or the like in
1985.
So: Are D templates ugly loat? Yes, sure. Do I care? No, not at
all. Why should I complain about D being unsatisfying as an
editor?
