Just an example, why D rocks, and C++ s***s...

[H. S. Teoh]

On Wed, Mar 16, 2022 at 04:33:30PM +0000, IGotD- via Digitalmars-d wrote:
[...]
> There is nothing stopping C++ from implementing a read function
> similar to D and it can coexist together with the existing interface.
> I think it is some kind of tradition preventing the standard library
> to be user friendly. Many companies use Qt-core (despite they don't
> use any GUI part of it) instead because that library is more usable .
>
> Also the idea that std::istreambuf_iterator<char>() is a good name for
> an end iterator further proves that point. There must be another
> better name for it though.

A lot of this is historical baggage. C++ was designed back in the days
when user-friendliness was not a big concern (even less so for
programmer-facing interfaces -- programmers were expected to just deal
with it).  Back then, there was also little precedent for what we see
today in, e.g., D's streamlined range API.  Even the idea of traits was
brand new, nobody had experience with it so no one knew what was a good
design or not.  Once the initial APIs were designed, unfortunately, the
naming conventions kinda stuck: newer APIs had to at least be somewhat
similar to previous APIs, in order to keep whatever level of consistency
existed in C++ (which wasn't very much, though, admittedly).  So you
have this inherited poor naming scheme / API style that just keeps
perpetuating.

By today's standards, of course, a lot of this was poor design
decisions. D learned from C++'s mistakes (at least some of it anyway)
and had the benefit of prior art to base design decisions on.  As they
say, hindsight is always 20/20.


T

-- 
Amateurs built the Ark; professionals built the Titanic.