My Little Dustmite: Bisect is Magic
Ethan
gooberman at gmail.com
Fri Jul 26 15:02:43 UTC 2019
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.
More information about the Digitalmars-d
mailing list