On 2/25/2013 11:56 PM, foobar wrote:
DDoc isn't part of the language but rather part of the compiler, nevertheless it
has its downsides. [...]
unittest is worse,
I think you're missing something gigantic. Before D had ddoc, the documentation
for Phobos was TERRIBLE - it was mostly missing, and the rest would describe
something that had no resemblance to what the code did. Adding Ddoc completely
revolutionized this. It's like night and day. Sure, you can pick at Ddoc's flaws
all day, but without Ddoc, the Phobos documentation would have remained utter s**t.
Yes, one could use Doxygen. One could hope an up-to-date version exists on all
the platforms D is on. One could nag people to use it. One could argue with
people who wanted to use a different doc generator. And one could look at
typical C and C++ projects, which use no documentation generator at all, and
pretty much have no documentation or have documentation as bad as the pre-Ddoc
Phobos docs.
Having Ddoc always there, always installed, always up to date, with literally
zero effort, tips the balance. It gets used. It raised the bar on what is
acceptable D code - it looks wrong without Ddoc documentation. By tipping the
balance I mean it *revolutionized* D code.
The same goes for unittest. How many C/C++ projects have you run across that
have unit tests? Again, yes, you can use 3rd party tools (of which there are a
plethora). You can try to use multiple libraries that use different unit test
frameworks. You can look at Phobos before unittest and see that it was pretty
much completely untested.
Unittest in the language, always there, always installed, zero effort,
completely changed the game. I'm very pleased at the depth and breadth of
unittests in Phobos. I have no doubt that would not have happened without unittest.
Sure, you can pick all day at the flaws of unittest, but you'd be missing the
point - without builtin unittest, there'd be nothing to pick at, because people
would not have unit tests.
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.
A little history is in order here. AA's were built in to the language from the
beginning, a result of my experience with how incredibly useful they were in
javascript. This was many years before D had templates. There was no other way
at the time to implement them in a nice manner (try doing it in C, for example).
D's improving generics has enabled them to be redone as library features.
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.
Bartosz' ownership system was intended to support multithreaded programming. It
was and still is too complicated. I've been working on another design which
should serve the purpose and will need nearly zero effort from the programmer
and it won't break anything. There was some discussion last fall on the n.g.
about it.
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,
Yes, and those are bugs, and we have every intention of fixing all of them.
integers has no overflow checks,
This has been discussed ad nauseum. To sum up, adding overflow checks everywhere
would seriously degrade performance. Yet you can still have overflow checking
integers if you build a library type to do it. See std.halffloat for an example
of how to do it. It fits in with your suggestion that things that can be done in
the library, should be done in the library.
ref also has holes,
Yes, and we are actively working to fix them.
Not only D has null pointer bugs but they also cause segfaults.
D now has all the features to create a library type NotNull!T, which would be a
pointer type that is guaranteed to be not null.
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?
I presume rust does not have an official answer to the debug conditional issue
and leaves it up to the user?
