On Monday, 25 February 2013 at 22:26:33 UTC, Walter Bright wrote:
On 2/25/2013 2:00 PM, foobar wrote:
On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright
wrote:
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.
On the contrary, I think it has turned out rather well. Another
success story of baking certain things into the language is
Ddoc. Unittest is a third. They've been big wins for D.
None of those strictly has to be in the language - they can be
done by convention and 3rd party tools. Nevertheless,
convenience, standardization and mechanical enforcement of a
convention seem to work better than applying religious zeal to
enforce a convention.
DDoc isn't part of the language but rather part of the compiler,
nevertheless it has its downsides. Being part of the compiler
means that the compiler needs to be changed to address those and
it isn't even written in D! The end result is all sort of
additional auxiliary D utilities to post-process this in order to
address some of those issues. Hence, A prime example of the
failure that I'm talking about.
unittest is worse, it is indeed part of the language so now the
_language grammar_ needs to be changed to fix the problems with
it, such as not having test names. A far better solution
practiced in all other major languages is to use annotations and
in fact, there probably already are similar D frameworks, thus
exhibiting the same problem of multiple conflicting
implementations you wished to avoid.
Additional such problems - the AA issue which has been going own
for years now. The endless discussions regarding tuples.
It seems that D strives to bloat the language with needless
features that really should have been standardized in the library
and on the other hand tries to put in the library things that
really ought to be built into the language to benefit from proper
integration and syntax.
The latest case was the huge properties debate and its offshoots
regarding ref semantics which I didn't even bother participate
in. Bartosz developed an ownership system for D to address all
the safety issues raised by ref *years ago* and it was rejected
due to complexity. Now, Andrei tries to achieve similar safety
guaranties by giving ref the semantics of borrowed pointers. It
all seems to me like trying to build an airplane without wings
cause they are too complex. Rust on the other hand already
integrated an ownership system and is already far ahead of D's
design. D had talked about macros *years ago* and rust already
implemented them.
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.
We do have a significantly better D culture than the C++ one.
For example, C++ relies heavily and unapologetically on
convention for writing correct, robust code. D eschews that,
and instead is very biased towards mechanical verification.
I call bullshit. This is an half hearted intention at best.
@safe has holes in it, integers has no overflow checks, ref also
has holes, Not only D has null pointer bugs but they also cause
segfaults.
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.
How does rust handle this particular issue?
