Johannes Schindelin [off-list ref] writes:
And I agree that this sidetrack is totally irrelevant for the patch
under discussion.
I do think, however, that the discussion of "we wanted to do it the
other way, but when we tried, it did not work" is relevant, even if I
shortened it to "we use a different approach than previous conversions,
because that previous approach would not work".
Regardless of the language the scripted version was written in, I
think the '--helper' approach is always the poorer choice between
the two [*1*]. It limits the modular decomposition to what suits the
original language, the impedance mismatch between the original and
target language forces us to unnatural style of inter module
communication, and the unnatural interface layer, which we know has
to be discarded at the end, must be written [*2*].
So, I'd prefer to see "because this is a better way in the longer
term" over "because the --helper approach would not work".
[Footnote]
*1* In only one case I would recommend using "--helper" approach,
though. When you are not expecting the developer to be able to
come up with a better split of the program into modules than how
the scripted version is, and you want to ensure that the
developer have something to show when they faild to complete the
project after N weeks. You are a more experienced developer
than an average GSoC student, and there is no pencils-down time,
so the exception would not apply.
*2* In "git submodule" for example it was quite natural for the
module that gives a list of submodules with its traits the
program cares about to be written as a shell function that
writes the data to its standard output. And consuming modules
sit at the downstream of a pipe, accepting its output. When you
are writing these modules both in C, you wouldn't connect them
with pipe to carry the list of submodules, but a piecemeal
conversion using the "--helper" approach meant that there always
remained _some_ consumer that wants to read from the pipe, so
long after the module lister was rewritten in C, it still needed
to support a mode where it sends its output to the pipe, instead
of just passing an array of structures.
Hi Junio,
On Mon, 11 Nov 2019, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
And I agree that this sidetrack is totally irrelevant for the patch
under discussion.
I do think, however, that the discussion of "we wanted to do it the
other way, but when we tried, it did not work" is relevant, even if I
shortened it to "we use a different approach than previous conversions,
because that previous approach would not work".
Regardless of the language the scripted version was written in, I
think the '--helper' approach is always the poorer choice between
the two [*1*]. It limits the modular decomposition to what suits the
original language, the impedance mismatch between the original and
target language forces us to unnatural style of inter module
communication, and the unnatural interface layer, which we know has
to be discarded at the end, must be written [*2*].
So, I'd prefer to see "because this is a better way in the longer
term" over "because the --helper approach would not work".
Hmm. I feel distinctly unheard.
It may appear compelling, conceptually, to shun the `--helper` approach,
but the more important reality is that it is the only one that makes an
incremental conversion possible at all.
It took an entire month of 60-hour weeks to complete the conversion of
`git add -i`/`git add -p` to C, and only at the very end was I able to
run the test suite with `GIT_TEST_ADD_I_USE_BUILTIN=true` and see it
pass.
That is an awfully long time, and you know fully well that this amount
of work equates to three to four Outreachy/GSoC seasons. That would be
an insane amount of time to go without the confidence of a passing test
suite.
In contrast, we were able to complete the conversions of the interactive
rebase as well as of `git stash` within _a single season_. I attribute a
large part of that success to the ability to keep the tests green during
the incremental conversion _because of_ the `--helper` approach.
So no, I do not think that your suggestion to reword the commit message
is something we want to do. Instead, I think the commit message needs
to be rephrased until I get the point across clearly.
It is indeed _in spite of_ the success of the `--helper` approach that
we cannot use it here.
Ciao,
Dscho
[Footnote]
*1* In only one case I would recommend using "--helper" approach,
though. When you are not expecting the developer to be able to
come up with a better split of the program into modules than how
the scripted version is, and you want to ensure that the
developer have something to show when they faild to complete the
project after N weeks. You are a more experienced developer
than an average GSoC student, and there is no pencils-down time,
so the exception would not apply.
*2* In "git submodule" for example it was quite natural for the
module that gives a list of submodules with its traits the
program cares about to be written as a shell function that
writes the data to its standard output. And consuming modules
sit at the downstream of a pipe, accepting its output. When you
are writing these modules both in C, you wouldn't connect them
with pipe to carry the list of submodules, but a piecemeal
conversion using the "--helper" approach meant that there always
remained _some_ consumer that wants to read from the pipe, so
long after the module lister was rewritten in C, it still needed
to support a mode where it sends its output to the pipe, instead
of just passing an array of structures.