On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:
On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:
On 2/24/13, Jonathan M Davis <[email protected]> wrote:
Yeah, which just adds the confusion, because all it does is
enable debug
bocks.
The feature almost doesn't pay its weight. I mean technically
you can
use -version=Debug and then use version(Debug) blocks. All
`debug`
does is saves a little bit of typing.
I should explain the reasoning for this.
I've talked to many C/C++ programming managers. They lament
that every C/C++ coding group feels compelled to reinvent their
own debug macro scheme. This makes it pointlessly difficult to
share code between groups.
It's not that unlike how pre-C++98 code bases all had their own
"string" class.
By baking one scheme into the language, people will rarely feel
a need to reinvent the wheel, and will go on to more productive
uses of their time.
This is a fallacy caused by the "culture" of c++ programmers -
there is exactly *zero* benefit in baking this into the language.
Yes, I agree with the sentiment that there should be a standard
way to save programmers the hassle and all that. The correct
solution to that is a culture of cultivating standard conventions
and "convention over configuration". E.g. Java has many such
convections followed to a level of religious zeal, such as using
camelCase everywhere and using PascalCase for types, etc, etc.
None of which is _enforced by the language_.
On the other hand, many major c++ libraries re-invent "string"
even though there exists already std::string and there are even
libraries that advocate _avoiding_ the use of stl entirely, all
for the perceived benefit of efficiency which is a prime example
of premature optimization. Even if there is efficiency gain in a
specific implementation, ideally it should have been used to
improve the standard stl::string but trying to change anything in
the c++ standard is futile - you can't just send a pull request,
you need to pass boat loads of red tape and wait a decade or two
for the next version, thus causeing this major NIH attitude.
All of this is to say, that instead of trying to "fix" the c++
culture in D, we should try to create a *better* D culture. When
you're buying an airplane ticket, what do you say to the travel
agent? The human reflex of "I don't want to go to ___" doesn't
get you a ticket anywhere. This feature is analogous - it's
designed to not allow c++ misbehavior, instead of actually
thinking what we do want and how best to achieve that. In fact
there are many such "not c++" features in D and which is why I
find other languages such as rust a *much* better design and it
evolves much faster because it is designed in terms of - what we
want to achieve, how best to implement that.
