Issue 5362: Generalize context searches

https://sourceforge.net/p/testlilyissues/issues/5362/

Combine code for \new, \context, and various internal searches.  This includes a small block of disabled code which will fix input/regression/context-find-parent.ly once it is enabled.  I want the reviewers to see it, but I don't want to mix the behavioral change into this major reorganization.

Separate the following from the act of finding a context:
1. forbid access to the Global context
2. prevent creation of multiple Scores under the Global context
3. warn if the desired context is not found or created

I've tried to judge where to do or not to do these three things based on the previous implementation.  Let me know if you think I've judged poorly or where the previous implementation was not worth following.

In a second commit: Rename the music property descend-only to search-direction; change its type from a boolean to a direction.

[Dan Eble, 2018-06-29 01:19:20]

fix typo in comment

[dak, 2018-07-01 13:21:45]

In summary: at the current point of time the added complexity because of the
employed constructs does not make the impression of being a good tradeoff for
understanding and maintaining the code.

I think you need to define the goals you want to achieve, then focus on the
simplest way of implementing a version in line with your goals.  The current
version uses considerably more complex code and constructs than the previous
version without achieving a tangible goal in that manner.

If you want to unify code, farming out into 9 separate function template
instantiations that could be individually retemplated is a debugging
complication for the sake of rather minimal constant expression/deadcode
elimination (we are talking about gains here that don't offset a single
additional call of Music::origin by far).

NLGTM

https://codereview.appspot.com/344050043/diff/1/lily/context-specced-music-it...
File lily/context-specced-music-iterator.cc (right):

https://codereview.appspot.com/344050043/diff/1/lily/context-specced-music-it...
lily/context-specced-music-iterator.cc:44: Input *origin = get_music ()->origin
();
Personally, I'd not get this in advance.  It is only needed when warnings are
emitted.  And in that case, saving one access for each of at least two warnings
is irrelevant.

https://codereview.appspot.com/344050043/diff/1/lily/context-specced-music-it...
lily/context-specced-music-iterator.cc:63: a = a->check_access (origin);
What is this for?  Comment?

In the spirit of avoiding unnecessary access of "origin", could we pass
something else here?  The music maybe?  Would that be in line with possible
other uses of check_access?

https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc
File lily/global-context.cc (right):

https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc#newcod...
lily/global-context.cc:129: return get_score_context ();
If I understand correctly, this will cause different behavior depending on
whether or not a Score context has already been created.

https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc#newcod...
lily/global-context.cc:143: return score;
So if there already is a Score context, it will be returned in lieu of _any_
request for creating any kind of context?  That sounds weird.

\new Score \context Global \context Voice << c d >>

would create two different Voice contexts since \context Voice is remapped to
\context Score ?

What is that good for?  Or am I completely mistaken here?

https://codereview.appspot.com/344050043/diff/1/lily/include/context.hh
File lily/include/context.hh (right):

https://codereview.appspot.com/344050043/diff/1/lily/include/context.hh#newco...
lily/include/context.hh:61: template <FindMode mode, Direction dir>
This creates a family of 9 different functions for each of the two functions you
include here.  Since the dir argument is actually being read from the command in
question rather than being fixed at compile time, you then need to hardcode a
farmout to the various variants since the actually called variant cannot, after
all, be determined at compile time in general.

That's a lot of complication for no discernible gain.  Why not pass the
respective parameters into the function?  Would that cause some kind of problem?

https://codereview.appspot.com/344050043/diff/20001/lily/change-iterator.cc
File lily/change-iterator.cc (right):

https://codereview.appspot.com/344050043/diff/20001/lily/change-iterator.cc#n...
lily/change-iterator.cc:67: Context::warning_cannot_find (origin, to_type,
to_id);
Having a separate function for each different warning text seems clumsy.  Can
this be factored into a more generic warning function and possibly something
formatting to_type and to_id?

https://codereview.appspot.com/344050043/diff/20001/lily/context.cc
File lily/context.cc (right):

https://codereview.appspot.com/344050043/diff/20001/lily/context.cc#newcode250
lily/context.cc:250: Context::find<Context::FIND_ONLY, UP> (SCM, const string &,
SCM);
The cure seems worse than the ailment.

[dak, 2018-07-01 13:25:35]

On 2018/07/01 13:21:45, dak wrote:

> NLGTM

Man, I use this stuff too rarely.  Maybe

PTAL

[Dan Eble, 2018-07-01 14:09:28]

(initial feedback—more later)

https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc
File lily/global-context.cc (right):

https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc#newcod...
lily/global-context.cc:143: return score;
On 2018/07/01 13:21:42, dak wrote:
> So if there already is a Score context, it will be returned in lieu of _any_
> request for creating any kind of context?  That sounds weird.

The missing information is that this method is called to create an immediate
child after acceptability has been verified, so it is only a Score.

The assumption that Global has a single child which is a Score (well, that if
Global has a Score, no other children are of interest, which is slightly
different), was present in the old code (see the first few lines of of
create_unique_context and find_create context).  I wouldn't call this any worse,
but a comment would still be beneficial.

https://codereview.appspot.com/344050043/diff/1/lily/include/context.hh
File lily/include/context.hh (right):

https://codereview.appspot.com/344050043/diff/1/lily/include/context.hh#newco...
lily/include/context.hh:61: template <FindMode mode, Direction dir>
On 2018/07/01 13:21:42, dak wrote:
> Since the dir argument is actually being read from the command in
> question rather than being fixed at compile time, you then need to hardcode a
> farmout to the various variants since the actually called variant cannot,
after
> all, be determined at compile time in general.

You're focusing on the context-specced music iterator which has the runtime
direction.  There are other callers using a hard-coded constant direction.

This is something I vacillated about.  At first, I had 7 public methods (2 modes
do something consistent but not really useful) with direction in the method
name.  That has long been my preference over providing constant arguments.  Then
I got to the context-specced music iterator and thought, maybe I should go the
other way in this case, inline the switch(dir) and trust the compiler to
optimize it in the cases that direction is known at compile time.

> That's a lot of complication for no discernible gain.  Why not pass the
> respective parameters into the function?  Would that cause some kind of
problem?

I don't know.  In terms of meaning, I have no problem with it.  I'll do it and
post an update.

[Dan Eble, 2018-07-01 16:48:09]

https://codereview.appspot.com/344050043/diff/20001/lily/change-iterator.cc
File lily/change-iterator.cc (right):

https://codereview.appspot.com/344050043/diff/20001/lily/change-iterator.cc#n...
lily/change-iterator.cc:67: Context::warning_cannot_find (origin, to_type,
to_id);
On 2018/07/01 13:21:43, dak wrote:
> Having a separate function for each different warning text seems clumsy.  Can
> this be factored into a more generic warning function and possibly something
> formatting to_type and to_id?

I'm willing to change this, but it's not perfectly clear to me what you are
asking for.  (The only change I would object to is pushing the logging back into
the find/create functions, and you're obviously not asking for that.)

Would you prefer a generic message saying "cannot find or create ..." even when
only one has been tried?  Would you prefer that the caller provide the mode as a
function parameter?  

I am also having trouble imagining what additional formatting of to_type and
to_id you are thinking of.  One is a symbol and one is a string, and the warning
functions print them as strings.  If you mean you want the caller to provide
some formatting, I would prefer to leave Context in control of the formatting to
help maintain consistency.

[dak, 2018-07-01 17:14:25]

On 2018/07/01 16:48:09, Dan Eble wrote:
> https://codereview.appspot.com/344050043/diff/20001/lily/change-iterator.cc
> File lily/change-iterator.cc (right):
> 
>
https://codereview.appspot.com/344050043/diff/20001/lily/change-iterator.cc#n...
> lily/change-iterator.cc:67: Context::warning_cannot_find (origin, to_type,
> to_id);
> On 2018/07/01 13:21:43, dak wrote:
> > Having a separate function for each different warning text seems clumsy. 
Can
> > this be factored into a more generic warning function and possibly something
> > formatting to_type and to_id?
> 
> I'm willing to change this, but it's not perfectly clear to me what you are
> asking for.  (The only change I would object to is pushing the logging back
into
> the find/create functions, and you're obviously not asking for that.)
> 
> Would you prefer a generic message saying "cannot find or create ..." even
when
> only one has been tried?  Would you prefer that the caller provide the mode as
a
> function parameter?  
> 
> I am also having trouble imagining what additional formatting of to_type and
> to_id you are thinking of.  One is a symbol and one is a string, and the
warning
> functions print them as strings.  If you mean you want the caller to provide
> some formatting, I would prefer to leave Context in control of the formatting
to
> help maintain consistency.

Something like
origin->warning (_f ("Cannot find or create context: %s", ctx->identification
()))

Well, in this case ctx could not created, so we need an alternative
static string Context::identification (id, name)
that would be used internally of string Context::identification () const
assuming that one can overload static and non-static functions.  If not, have a
context_identification (id, name) instead.

That way, the warning text is directly where it gets produced, and the
context-identification formatter might be nice even from Scheme, with either a
context argument or two arguments (whatever it was, symbol or string).  That way
we'd get a uniform format for such messages.

[dan_faithful.be, 2018-07-01 18:17:16]

> On Jul 1, 2018, at 13:14, dak@gnu.org wrote:
> 
> Something like
> origin->warning (_f ("Cannot find or create context: %s",
> ctx->identification ()))

Meh.  Multiple callers would repeat the message “cannot find or create context”
which is part of what I was trying to avoid.  I wouldn’t stake this whole patch
on getting it my way, but let’s mull it over while I work on the other
revisions.

If there were a good example that the message ought to be tailored to each
specific scenario, I’d more willingly let the caller provide the whole text.  I
did think about that and couldn’t justify it to myself.

> Well, in this case ctx could not created, so we need an alternative
> static string Context::identification (id, name)

I like this, but doesn’t it run counter to the guidance in the CG under the
statement "Split up multi-sentence messages, whenever possible” and also “When
translating, it is preferable to put interesting information at the end of the
message rather than embedded in the middle”?  Reading that, I thought that
having the context name and ID each at the end of separate messages would be
preferred.

Consider also that these proposed changes come out of an experiment with adding
a new constraint on find-context operations: properties that must be defined. 
The names of those properties should be logged if the context is not found, but
they are not part of the identity.  So, we could use
Context::format_search_constraints_for_logging (name, id, property_syms), or let
the callers handle the ID constraints and property constraints separately, or
keep the proposed approach of passing the source location and all constraints
into a function that does the rest.

> the
> context-identification formatter might be nice even from Scheme, with
> either a context argument or two arguments (whatever it was, symbol or
> string).  That way we'd get a uniform format for such messages.

Probably worth doing separately for its own sake.  Can you identify one place
you would like to see it used?
— 
Dan

[dak, 2018-07-01 19:08:23]

On 2018/07/01 18:17:16, dan_faithful.be wrote:
> > On Jul 1, 2018, at 13:14, mailto:dak@gnu.org wrote:
> > 
> > Something like
> > origin->warning (_f ("Cannot find or create context: %s",
> > ctx->identification ()))
> 
> Meh.  Multiple callers would repeat the message “cannot find or create
context”
> which is part of what I was trying to avoid.  I wouldn’t stake this whole
patch
> on getting it my way, but let’s mull it over while I work on the other
> revisions.

We currently have

dak@lola:/usr/local/tmp/lilypond$ git grep "find or create" lily
lily/context.cc:      warning (_f ("cannot find or create new `%s'",
lily/context.cc:  warning (_f ("cannot find or create `%s' called `%s'",
dak@lola:/usr/local/tmp/lilypond$ 

That's not multiple callers.  It's two different messages for two different
situations.  Why would a sensible refactoring introduce more callers?

[Dan Eble, 2018-07-01 19:36:50]

ditch templates

[dan_faithful.be, 2018-07-01 19:51:45]

On Jul 1, 2018, at 15:08, dak@gnu.org wrote:
> 
> We currently have
> 
> dak@lola:/usr/local/tmp/lilypond$ git grep "find or create" lily
> lily/context.cc:      warning (_f ("cannot find or create new `%s'",
> lily/context.cc:  warning (_f ("cannot find or create `%s' called `%s'",
> dak@lola:/usr/local/tmp/lilypond$
> 
> That's not multiple callers.  It's two different messages for two
> different situations.  Why would a sensible refactoring introduce more
> callers?
> 

The current code has the messages built into the search methods, so there are
only two.  My patch pulls them out, letting the callers decide whether to warn,
and there are six callers that choose to warn.

change-iterator.cc:        Context::warning_cannot_find (origin, to_type,
to_id);
context-specced-music-iterator.cc:        Context::warning_cannot_create
(origin, ct, c_id);
context-specced-music-iterator.cc:        Context::warning_cannot_find_or_create
(origin, ct, c_id);
context.cc:  Context::warning_cannot_find_or_create (/*source location*/ 0,
name, id);
quote-iterator.cc:        Context::warning_cannot_find_or_create (origin, name,
c_id);
simultaneous-music-iterator.cc:             
Context::warning_cannot_find_or_create (get_music ()->origin (),

It might make sense for the one in context.cc to be pulled out into its callers
as well, but I was not planning to investigate that now.
— 
Dan

[dak, 2018-07-01 20:40:26]

On 2018/07/01 14:09:28, Dan Eble wrote:
> (initial feedback—more later)
> 
> https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc
> File lily/global-context.cc (right):
> 
>
https://codereview.appspot.com/344050043/diff/1/lily/global-context.cc#newcod...
> lily/global-context.cc:143: return score;
> On 2018/07/01 13:21:42, dak wrote:
> > So if there already is a Score context, it will be returned in lieu of _any_
> > request for creating any kind of context?  That sounds weird.
> 
> The missing information is that this method is called to create an immediate
> child after acceptability has been verified, so it is only a Score.

Ugh.  The half-hardwired relation of Global and Score is sort of a
nuisance.  LilyPond does not really want to work with a different
setup but it's still spelled out in {engraver,performer}-init.ly as if
it could.  If someone messes with that, I'd prefer that LilyPond
breaks down in obvious places rather than all over the place.  I'll
readily admit that this isn't the case currently either, but it does
not exactly make review nicer

> I wouldn't call this any worse, but a comment would still be
> beneficial.

Yup.

> https://codereview.appspot.com/344050043/diff/1/lily/include/context.hh
> File lily/include/context.hh (right):
> 
>
https://codereview.appspot.com/344050043/diff/1/lily/include/context.hh#newco...
> lily/include/context.hh:61: template <FindMode mode, Direction dir>
> On 2018/07/01 13:21:42, dak wrote:

> > Since the dir argument is actually being read from the command in
> > question rather than being fixed at compile time, you then need to
> > hardcode a farmout to the various variants since the actually
> > called variant cannot, after all, be determined at compile time in
> > general.

> You're focusing on the context-specced music iterator which has the
> runtime direction.  There are other callers using a hard-coded
> constant direction.

> This is something I vacillated about.  At first, I had 7 public
> methods (2 modes do something consistent but not really useful) with
> direction in the method name.  That has long been my preference over
> providing constant arguments.  Then I got to the context-specced
> music iterator and thought, maybe I should go the other way in this
> case, inline the switch(dir) and trust the compiler to optimize it
> in the cases that direction is known at compile time.

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.

C++ is a statically typed language.  It prides itself on allowing
basic types and data structures to be implemented in-language with an
efficiency near native implementations, to a good degree via its
template programming mechanisms which are totally alien to the
C language in syntax, to the degree that even the token >> requires
being viewed as two separate tokens in some situations.  The
associated cost to the human reader is horrific but there are
situations when this pays off.

Those situations are things like the Complex data type or the STL or
Boost++ libraries, stuff that the "ordinary" programmer never looks
into but "only" uses, stuff which is written once and used hundreds
and thousands of times all over in different systems.  One result is
that there _still_ isn't an efficient standard multidimensional array
type that numeric libraries would consistently use and that would
allow to painlessly write code with the same kind of aliasing
guarantees and possibilities of strength reduction that mathematicians
could work with using Fortran II in, what?, the 1950s?

So cranking out the template stuff is heavy-duty stuff.  There are
heavy-duty situations in the LilyPond code base where we use it,
either as mere users in the case of external libraries like STL, but
also ourselves and there mostly for marrying the static type system
and memory management of C++ to the dynamic type system and garbage
collection system of Guile.  This is stuff that is heavily used in
joints seminal to performance.  It's also very thoroughly used, to the
degree where we could swap out the type system for something different
and everything would follow.

It's unpleasantly dense code, but it keeps stuff in one place and
reasonably efficient.  That's a good tradeoff for using templates.
Trampolines are generated automagically using the template system:
that's a somewhat worse tradeoff but removes a solid bout of clutter,
clutter that would be easy to understand but still requires looking
at.

Now your use of templates possibly saves a few cycles, assuming that
branching out into 8 different versions does not cost more cycles due
to execution cache pollution than the savings are.  We are talking
about few cycles of savings in functions that for better or worse take
easily tens of thousands of cycles to execute.  That's pointless.  We
don't improve how the computer gets along with the code, so our focus
needs to be on how the human gets along with the code.

Template instantiation is a separate compiler pass with complex
semantics that a human needs to stay on top of.  Function arguments
are simple in comparison.

It's not really an equivalent choice.  In fact, the greatest
performance drain to be feared is having code that the average
programmer will be afraid to touch.  All other code will gradually be
refactored and improved over time and kept in a shape compatible with
the rest.  Scary code, in contrast, will not get improved.  The
associated one-time savings in the order of a few thousands of
percents (if at all) are offset against the cost of the code making
programmers less inclined to do further refactoring.  Which is
definite a larger percentage.

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.

That's a social metric of the code.  Keeping sight of that is a much
more fuzzy thing than figuring out whether some version runs 2 cycles
faster than another.  But even given some fuzziness, some comparisons
can be made.

As a rule of thumb you don't go wrong reducing complexity as long as
you do not increase _algorithmic_ complexity.  Reducing algorithmic
complexity does warrant refactoring, and one wants to do it in a
manner where the complexity is condensed into a comparatively small
and general and possibly separately maintainable piece of code, so
that the bulk of the code is again comparatively easy to understand.

That keeps the code in a shape where people can work effectively on it
and cause incremental changes that are not mere window dressing.

I mean, with regard to the LilyPond code base, this is reminiscent of
the joke of the guy taking a broiled chicken to the vet and asking
whether something can be done.  But we are not there yet.

[dak, 2018-07-01 20:44:00]

Dan Eble <dan@faithful.be> writes:

> On Jul 1, 2018, at 15:08, dak@gnu.org wrote:
>> 
>> We currently have
>> 
>> dak@lola:/usr/local/tmp/lilypond$ git grep "find or create" lily
>> lily/context.cc:      warning (_f ("cannot find or create new `%s'",
>> lily/context.cc:  warning (_f ("cannot find or create `%s' called `%s'",
>> dak@lola:/usr/local/tmp/lilypond$
>> 
>> That's not multiple callers.  It's two different messages for two
>> different situations.  Why would a sensible refactoring introduce more
>> callers?
>> 
>
> The current code has the messages built into the search methods, so
> there are only two.  My patch pulls them out, letting the callers
> decide whether to warn, and there are six callers that choose to warn.
>
> change-iterator.cc:        Context::warning_cannot_find (origin, to_type,
to_id);
> context-specced-music-iterator.cc: Context::warning_cannot_create
> (origin, ct, c_id);
> context-specced-music-iterator.cc:
> Context::warning_cannot_find_or_create (origin, ct, c_id);
> context.cc: Context::warning_cannot_find_or_create (/*source
> location*/ 0, name, id);
> quote-iterator.cc: Context::warning_cannot_find_or_create (origin,
> name, c_id);
> simultaneous-music-iterator.cc: Context::warning_cannot_find_or_create
> (get_music ()->origin (),
>
> It might make sense for the one in context.cc to be pulled out into
> its callers as well, but I was not planning to investigate that now.

So what benefit do we get from forking out two different warnings for
two different situations into one warning for six situations?  What does
your code do better after the refactoring making this desirable?

-- 
David Kastrup

[dan_faithful.be, 2018-07-02 00:16:31]

On Jul 1, 2018, at 16:40, dak@gnu.org 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.  First, please take note that I appreciate the time
you spend reviewing my submissions, that I’ve already updated the patch to
remove the templates, and that nothing I’m about to say is meant to increase
stress.

> Now your use of templates possibly saves a few cycles, assuming that
> branching out into 8 different versions does not cost more cycles due
> to execution cache pollution than the savings are.

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.

> 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.  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.

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.”

Regards,
— 
Dan

[dak, 2018-07-02 07:59:30]

On 2018/07/02 00:16:31, dan_faithful.be wrote:
> On Jul 1, 2018, at 16:40, mailto:dak@gnu.org 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.

[Dan Eble, 2018-07-02 23:30:56]

message: On 2018/07/01 18:17:16, dan_faithful.be wrote:
> > On Jul 1, 2018, at 13:14, mailto:dak@gnu.org wrote:
> > 
> > Something like
> > origin->warning (_f ("Cannot find or create context: %s",
> > ctx->identification ()))
...
> Probably worth doing separately for its own sake.

https://codereview.appspot.com/349740043/