My Little Dustmite: Bisect is Magic

[Ethan]

On Friday, 26 July 2019 at 13:02:21 UTC, FeepingCreature wrote:
> I would like to voice a very enthusiastic recommendation for 
> Dustmite for reducing programs to tests. Since it just requires 
> a pass/fail test, it's easy to write a shellscript that checks 
> that DMD's output matches a specific pattern, such as 
> "COMPILE:.*".

Honestly, hot take/opinion time here. But every time I hear 
someone say "Dustmite" my immediate reaction is "Well I guess D 
isn't ready for production code."

Let's have a for real example.

I have a static assert in my receive function. If it detects that 
you've defined a message but haven't provided an implementation 
for receiving that message, it'll helpfully tell you exactly what 
you need to do.

For the sake of my C# bindings, I'm doing a mixin within a mixin 
to generate correct message responses for an entire class of 
messages dealing with creating/syncing/deleting objects.

Inside these functions, of course I write errors. Outside of {} 
braces, I almost never write any given line of code once. Things 
I haven't imported, typos, whatever. Nothing ever compiles first 
time.

So I hit compile expecting to see what kind of problems are going 
on now.

My static assert fires saying that this message isn't defined, 
compile stops dead in its tracks.

I sit there going "what the Zod" for twenty minutes, double 
checking template definitions, rewriting template declarations, 
before I finally decide to go in to my send function and comment 
out the static assert and just let the compiler error on the 
receive call.

Errors start showing up as normal in my templated functions.

So what's going on here? Internally, the compiler knows my 
templated function won't compile. It knows there's an error. It 
knows the symbol can't be defined. But instead of giving me the 
errors for what's going on there first, it sees my static assert 
and jumps off a rather tall cliff taking everything it knows with 
it.

Now, I could Dustmite my project. Which currently sits at 73 .d 
files and 6,447 lines of D code and growing. (There's more C# at 
the moment, but I autogenerate a bunch of it and depenency 
properties are responsible for a ton of pointless bloat - but 
that's a digression.) Throw in Binderoo as well since I can't use 
C# without Binderoo giving me bindings for my code. Copy it all 
off somewhere I won't touch and let it run for potentially days 
finding a minimal reproducible set.

Or maybe I could spend the time to isolate and work out what 
makes the compiler do these weird things.

Or I could do what I do daily in a production environment - fix 
or workaround the bug and get on trying to meet a deadline.

I'll take door number three thanks. That potential customer isn't 
going to care how many bug reports I write, especially since I 
inevitably come across something a couple of hours later that 
should be Dustmited... Dustmote... Dusted. Whatever. I don't have 
that much CPU power to spare.

Now.

I know that's also a counter-productive viewpoint to have. "I got 
a bug!" Great, submit a bug report with a reproducible case. "I 
don't have the time!"

Who else but me, right?

But the overall point I started making at the start of this post 
is that door number three point. Get D in to a production 
environment, people aren't going to engage in jolly community 
co-operation. They want to get their job done, meet their 
goals/targets, get paid, eat, and generally just complain to 
their co-workers about the latest weird <yeah, imagine I broke 
the white-collar forum protocol here> that D is doing. Like every 
other colleague you've ever known using every other language 
you've ever used professionally.

Wrapping up. Short of ye olde corporate "sign this NDA and get 
the keys to my codebase" approach to look at, I'm not sure what 
the middle ground is.