Per Bothner <xxxxxx@bothner.com> writes:

> For example:
>   "I've been looking at the srfi-64 reference implementation and I
>   find the structure a bit complicated and hard to understand.
>   I also found what appears to be some bugs and inconsisteniesy from
>   the specification.  I tried to see how if I could simplify the
>   implementation; I'm happy with the result, and I'm hoping the result
>  [see link] might replace   the existing implementation.  What do you think?"
>
> See how much less obnoxious that sounds, while still conveying
> the same message?

Yes, I see.  However, while I don't want to be rude, I don't want to be
blatantly dishonest either, and I can't choose what does and doesn't
frustrate me. :-) I would need to suppress a lot of frustration building
up from working on (and using) the code to be able to write like that.
Though I guess I can work on getting less frustrated in first place, by
trying harder to not be too perfectionist.

>> Well, it clearly wasn't very well tested,
>
> Can I suggest you re-read and think about what you write before
> you post it?  This is another confrontational statement that
> you should expect would produce more heat than light.
>
> Thousands of tests have been written using the reference implementation.
> These have not exhaustively tested very corner case (far from it),
> but saying "wasn't very well tested" leaves out the question of who
> was supposed to test it, and how.

As soon as I started using SRFI-64, the bug where the test name
expression doesn't get evaluated was one of the first things to hit me.
I guess it was just a very bad coincidence; I can see that most people
don't use that feature.

(FWIW here's how it's used in my case:
https://github.com/TaylanUB/scheme-srfis/blob/master/test-all.scm )

> There is a srfi-64 meta-test.  I tried your implementation, and it had
> 4 unexpected failures.  This could be  a bug in srfi-64-test.scm,
> but I suggest you take a look at it.
>
> You could also try running the Kawa test suite ('make check') replacing
> gnu/kawa/slib/testing.scm with your version,

I'll look into it.

>> I don't use any of the words I use as slander.  I believe I made a
>> reasonable job of pointing out concrete issues with the code's style and
>> how these lead to actual bugs.
>
> No you didn't.  You pointed out some concrete issues (bugs), but there
> is little reason to ascribe those to the code's style.  At most, the goal
> of supporting non-portable features where possible [leads] to some
> conditional code not getting tested.

I think there is good reason to ascribe at least some of the bugs to
overall style:

- If the 'test-assert' definitions had used either of cons or quoting
  uniformly instead of switching styles, then the name-evaluation bug
  would have either surfaced much earlier (because it would have
  happened in Kawa, MzScheme, and Guile 2.x as well), or it wouldn't
  have happened (the subtler/maybe harmless bug of evaluating the name
  twice would have happened in both).

- Same thing if it hadn't been cond-expand'ed in first place.
  Cond-expand is also especially nasty in that a (meta-)test suite will
  have no possibility of catching the bug unless the test suite is run
  with multiple implementations.

- There is a dedicated "on test end" procedure, yet the on-test-end hook
  of the runner is called by the "report test results" procedure.  In my
  opinion, this has good bug-inducing potential in further work with the
  code, even if it's not a bug yet.

Since I'm normally very perfectionist/idealist/pedantic, but strain
myself to be pragmatic instead, I jump immediately when I notice that
pedantry *would* have had a pragmatic benefit after all.  Test suites
are the most important way to achieve confidence in lack of bugs as I
see it, but in this case we have a couple of bugs that escaped the test
suite for the library (the meta-test suite), as well as thousands of
programs using the library (test suites), and yet they would have been
prevented by some pedantry in code style.

Therefore, please allow me to conclude that a fair share of pedantry in
code style is beneficial in programming.

(For something related but slightly different: I happen to have a
similar pedantry-rooted analysis in the first section of this document:
http://taylanub.github.io/doc/scheme-values.txt re. "unspecified" return
values vs. zero-value returns in Scheme, and how it relates to real
issues that came up in GNU Guix's code-base.  Pedantry is under-rated!)

Taylan