Reddit: why aren't people using D?

[Walter Bright]

Knud Soerensen wrote:
> Some time ago I need a script to get and process some data.
> I trough why not use D, but I couldn't find a function in the standard 
> library which would get a simple web page with http.
> Instead of find and downloading other libraries I switched to peal and 
> had it running in no time.
> 
> I think it is the choice of problem domain for D.

I'd love to have some functions in Phobos that do this. Can you write a 
module and contribute it? Phobos is definitely short on a lot of 
networking functionality.


> I know the real focus for D system programing and the C++ people.
> 
> I think one of D's strongest points for people to make the switch is 
> build in unit testing. (at least this is the strongest point for me)
> But the very simple implementation of unit testing in D nearly ruin the 
> advantage it gives. (see suggestion from the wishlist below)

Even at its very simple support, it's a huge win. It raises the bar on 
what is minimally acceptable, and has been responsible for a big 
improvement in the quality of Phobos.


> A simple way to ensure that could if the compiler issued a error/warning 
> if a function had no unit tests or contracts.

I worry that such would be crying wolf. But dmd does have a coverage 
analyzer built in - which I think is more useful. It'll show which lines 
were executed by the unit tests, and which were not.


> 
> What follows is some unit test suggestions from 
> http://all-technology.com/eigenpolls/dwishlist
> Because I would like to hear your opinion about them.
> 
> ** unit test & code separation
> I think it would be more useful if the code
> and the unit test where two separate binaries.
> 
> Sometimes you need to move the production binary to another 
> machine/environment.
> It would be nice if one could move the test binary with it and test that 
> everything works.
> 
> It would also allow for arguments to the test binary,
> so that you would be able to run a specific unit test.

I made the decision at one point that unit tests weren't there to test 
that the compiler generated code correctly, they were to test the logic 
of the user code. Hence, one does a separate build for unit tests than 
production release.

The release version should get the black box tests, not unit tests.



> ** black box unit testing
> The d compiler should enforce black box unit tests.
> 
> Which is unit tests that only use the classes exposed interface.(public, 
> protected)
> 
> Together with 100% unit test coverage it helps ensure that
> the code is modular,decoupled and that you can change
> the private parts without changing the unit tests.
> 
> For those how is not ready for this high code standard,
> there might be a --allow-white-box switch.

The compiler doesn't need to help here. There's nothing preventing one 
from using unittests in this manner. Just import the .di file, which is 
the exposed interface, then write a unit test block.

> ** Unit test isolation
> I would like to be able to isolate the unit test,
> so that if one fail the next still runs.

You can do this by simply not using "assert" for the actual test. Use:
   if (!x) writeln("test for x failed");
instead of:
   assert(x);
You can, of course, make a template like Andrei's enforce() to make the 
if test and message a bit more convenient.


> ** Unit test measurements
> In combination with test isolation
> it would be nice to have d output
> memory and time used in each unit test.

Use the -profile switch.