On Tuesday, 26 February 2013 at 19:53:11 UTC, Walter Bright wrote:
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.
All of the above describes the benefits of having standardized
documentation and I agree with that. That has nothing to do with
DDoc's specific design compared to other similar efforts. A quick
survey of languages shows that Ruby, Python, Java, C#, and many
others all have the same benefits but non has the doc generator
built into the compiler/vm with all the problems this entails.
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.
Same as above. You compare again to C++ and ignore the provably
successful models of _many_ other languages. Ruby for instance
really shines in this regard as its community is very much
oriented towards TDD. Java has such a successful model with its
JUnit that it inspired a whole bunch of clones for other
languges and you completely ignore this. Instead you discuss the
design of a new car based on experiences of horseback riders.
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.
I'm familiar with the history of AAs in D and how they came to be
this horrible mess. Yet, templates in D are ancient news by now
and the problem hadn't been fixed and not due to lack of effort.
The problem is again - applying common c++ wisdom and trying to
maintain inconsistent semantics.
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.
Yes, but this conflicts with your statement of intention towards
verification machinery for safety. Of course I can implement
whatever I need myself but what ensures safety is the fact that
the default is safe and the language forces me to be explicit
when I choose to sacrifice safety for other benefits. You see,
*defaults matter*. I can use an option type in D and still get
null pointer segfaults whereas in Rust I cannot get a null value
without an explicit option type which I am forced to check.
Another case in point - both Germany and Austria have an option
to sign an organ donor card when getting a driver's license.
Germany requires to tick the box if you want to join the program,
Austria requires to tick the box if you do *not* want to join.
Austria has a much higher percentage of organ donors.
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.
irrelevant. See previous comment.
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?
I'm not sure rust has such a feature as it is much more
functional in style than D. If I'm not mistaken, "debug" in Rust
is used as one of the logging macros.
