Top 5

[dsimcha]

== Quote from Benji Smith (dlanguage at benjismith.net)'s article
> Anyhow, I'm not going to keep chasing this point. For people new to D,
> the subtle differences between static and dynamic arrays can be a source
> of confusion. I still have my share of gotcha moments with them, and I
> think D would be well served by minimizing those differences.
> --benji

I disagree, not only specifically on this issue but on a more philosophical level
about a lot of stuff that's been mentioned here in the past few days about
simplifying D.  The fact is that D is a performance language that retains the
ability to program close to the metal.  It may be a relatively friendly, modern,
easy to use performance language, but it's still a performance language.  It's
also a multiparadigm language.  These two things necessarily means that some
tradeoffs have to be made in terms of simplicity to allow for more efficient code
to be written, and for procedural, functional, metaprogramming and OO paradigms to
be mixed and matched.

If people can't or don't want to understand the difference between a static,
stack-allocated array and a dynamic, heap-allocated array, they probably don't
need a performance language.  They probably want Python or Ruby and they know
where to find it.  If they can't or don't want to learn more than one programming
style, they probably don't need a multiparadigm language.  They probably want Java
and they know where to find it.

The bottom line is that yes, D is becoming a fairly complicated language, but it's
complicated because it's powerful, unlike for example C++, which is complicated
because it's full of cruft from before people like me were even born, or Haskell
(disclaimer:  I've never actually used Haskell before, though I've heard a decent
amount about it), which is complicated because it rigidly emphasizes theoretical
purity.