Re: Issue 5362: Generalize context searches (issue 344050043 by address@hidden)

[dak]

On 2018/07/02 00:16:31, dan_faithful.be wrote:
> On Jul 1, 2018, at 16:40, mailto:address@hidden wrote:
> >
> > Premature optimization is the root of all evil.  I'm going to
> > pontificate now in the hope that you'll have some opportunity in
your
> > work life to take karmatic revenge by passing this kind of "wisdom"
> > on.

> I sense some frustration.

No no, trepidation.  I can pontificate all day long.  That's when I am
being in my element.  It's just rarely popular with my listeners.  So I
tried wrapping it into a package I need to deliver only once.


> Understood.  In return, please try to understand the perspective of a
> contributor who has not developed a good sense for how any given
change will be
> received and is working hard to navigate contributing in spite of it.
The
> current implementation without templates also has separate functions
for
> create_unique_context, find_create_context, find_context_above,
> find_context_below, and find_context_near.  The contributor has a
choice: if he
> maintains the separate instances of these functions by using
templates, will the
> reviewers react to the syntax?  If he combines the separate functions
into one
> function with new new branches controlled by new parameters, will the
reviewers
> react to the potential change in performance?  In the future, I will
try to
> approach such questions from the perspective you’ve presented.

There is no hard and fast rule.  But basically one should use templates
when they solve a particular problem, not just because one can.  Of
course, different people set different rules for different projects, and
I don't even "set the rules" but do a review here.  It would be easier
in some way if we had dozens of reviewers with a certain variety of
opinions so that you'd get a better gut sense of general consensus
rather than just the same single annoying person obsessed with having
everything his way.

I do believe that I have some reasonable grasp of tradeoffs for code
that is likely to be looked at by multiple people.  In general, one
should aim for light reading rather than world literature.  Of course it
turns out that a lot of world literature actually _is_ light reading
while still carrying substance.  That's what keeps it popular.

> > We have to keep what we think we are going to be able to achieve in
> > relation with how hard to maintain the code becomes to a programmer
> > being somewhat comparably versed in Scheme and C++ because only
those
> > programmers will actually have the required view of the whole to
work
> > effectively on the LilyPond code base.

> I will have to rely heavily on your judgment in this regard.

Writing for the bin is frustrating so I hope that this is mostly
transitory.

> I do not have the
> perspective of a casual C++ coder, and for years I have worked in a
group in
> which the principal software engineer is passionately devoted to using
the most
> recent tools available to achieve the highest performance possible,
and in which
> there are (sadly and happily) no junior coders to be concerned about.

C++ obsession about offering tools for doing anything statically that is
possible, never mind the monstrosity of the required constructs, is not
a good thing.  Just in time compilation of more dynamically typed
language will become increasingly important, with type signatures
selecting a usually precompiled bit of code.  At some point of time,
this paradigm will start getting hardware support, like stack frames for
potentially recursive functions with local data became an omnipresent
thing that old Fortran architectures just didn't have.  Also garbage
collection is bound to become more integrated with processors.

I might be wrong here.  But I consider myself writing code that doesn't
look too silly no matter how the future ends up.  That implies
introducing complexity where it solves or at least encapsulates a
complex problem, to a degree where you need to worry about it only in
one place in the code, not when using it.

> The next time this happens (it seems nearly certain) you only need to
say
> something like, “Dan, you’re worrying too much about preserving X;
just go ahead
> and do Y and it will be simpler.”

Let's hope we find the sweet spot where we don't feel like wasting the
other's time.

https://codereview.appspot.com/344050043/