On 2/26/2013 2:10 PM, foobar wrote:
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.
Building ddoc into the compiler means it has access to the semantic information
that compiler provides, and it uses that information. If it is not built in to
the compiler, then the options are:
1. require the user to type the information in twice
2. add parsing and semantic analysis capability to the doc generator
I find (1) to be an unacceptable user experience, and (2) to be not viable given
our limited resources.
BTW, Javadoc apparently can only generate HTML. As Andrei has demonstrated, Ddoc
can generate html, pdf, and ebooks without changing the Ddoc comments. I'm
curious what fundamental advantage you believe Javadoc has over Ddoc.
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.
They're not that much different - except in one significant aspect. JUnit (for
example) has a plethora of websites devoted to tutorials, cookbooks, how-tos,
best practices, etc. D unittest is so simple there is no need for that. Anyone
can be up and using D unittests in 2 minutes. The how-to is one slide in a
presentation about D. Nobody is going to write a book about D unittest:
http://www.amazon.com/JUnit-Action-Second-Petar-Tahchiev/dp/1935182021
That's a 450 page, $30 book on JUnit, in its second edition because it's so
complicated.
I believe the success of unittests in D speak to the value of making it so
simple to use.
That said, with the new UDA in D, you (or anyone else) can write a "DUnit" and
present it to the community. I doubt you'll find it worth the effort, though, as
unittests work very well.
The problem is again - applying common c++
wisdom and trying to maintain inconsistent semantics.
I'm curious how you ascribe builtin AA's, which C++ does not have and will never
have, to applying C++ wisdom. As I said, D's AA's were inspired by my experience
with Javascript's AA's.
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.
Designing *anything* is a compromise among mutually incompatible goals. In no
way are we going to say principle A, worship A, use A as a substitute for
thought & judgement, and drive right over the cliff with a blind adherence to A.
For example, try designing a car where safety is the overriding concern. You
can't design it, and if you could you couldn't manufacture it, and if you could
manufacture it you couldn't drive it an inch.
All language design decisions are tradeoffs. (And to be pedantic, integer
overflows are not a memory safety issue. Neither are null pointers. You can have
both (like Java does) and yet still have a provably memory safe language.)
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 agree they matter. And I doubt any two people will come up with the same list
of what should be the default. Somebody has to make a decision. Again, tradeoffs.
