On 2 April 2018 at 22:08, Titus Winters <titus_at_[hidden]> wrote:
> At the recent evening session in Jacksonville, many many things were brought
> up in the realm of "tooling." These ranged all across the spectrum of
> engineering tools, from IDE support, dependency management / discovery,
> distribution, refactoring, and a host of other things.
>
> On the fly, I tried to cobble those into a coherent goal for SG15 and the
> committee to aim toward. It's currently phrased very much for the committee
> audience (that's been part of my delay in re-summarizing here), but as with
> any good mission statement I think it gets direction and incentive
> structures aligned with the greater good. Put another way: it's phrased
> selfishly, but hopefully produces great results for the entire community.
>
> So, here is that proposed mission statement:
>
> In 10 years, the committee should be able to run compiler-informed queries
> against a significant fraction of the open-source C++ community and use that
> to inform deployment of refactoring tools to mitigate.
>
> Consistent build understanding
> Consistent package distribution / identification
> Provide static analysis and refactoring to help provide users easy upgrades
> and modernization
>
>
> Obviously this would be a huge task that requires support from many chunks
> of the community - WG21 cannot be solely responsible, and it's outside of
> what WG21 is normally great at. But we can help set direction, plan,
> prioritize, and lend support to ideas that emerge along these lines.
>
> So, I'd like to hear from everyone a bit: is this a good direction? Does it
> capture what we'd like? Can we phrase it less selfishly?
>
> If we're happy with holding this up as the long-term goal, we'll need to
> break it down into more manageable pieces. I've privately asked a couple
> people to sketch out what they envision it would take to get from where we
> are to that proposed future. I'd like to broaden that call, and we'll look
> collectively at those break-downs to try to formulate next steps.
>
> Thoughts?
> -Titus
>
> PS: I've also just completed a big round of offloading in my day job, so
> hopefully I'll have more cycles to pay attention to discussion on this list.
> My apologies for my scattered attention so far.


To me, that mission statement sounds like "let's build tooling that
helps us make breaking changes
in a more educated fashion". The problem I have with that is that I do
not believe tooling will solve that problem.

Alright, them's fighting words, so before I explain why, I'll add some
more fighting words. :) The problem with
compatibility breaks, especially ones that are of the ilk "someone
somewhere was confused by this so let's make
a breaking change and provide, for some values of superior, a superior
new way to write the code". Based on what
I've seen and encountered, that means breaking valid and correct code
because users the authors of that valid
and correct code have never heard about nor care about think that's
the right solution.

Now, onto a less fighting-words mode. Compatibility breaks are
expensive. When they occur, I have two choices:
1) split the code into legacy version(*) and a new-and-shiny version,
with or without the help of tooling.
2) do the conversion on the fly somehow, at build time, probably with
the help of tooling.
With (1), I'll end up with a maintenance headache any which way I snap
it, and tools may or may not help
with that headache - the current tools don't, much. With (2), I'm now
exposed to unknown bugs in the additional
tools I run, and my builds are slower.

(*) I bet you and I, for example, have very different exposure to
having to support legacy systems. In your workplace,
supporting them is probably fairly rare, comparatively. In my case, I
have had to support legacy systems *everywhere*
in *every project* throughout my whole career. The code that runs on
them is large in quantity, and rewriting it for newer systems
is not something that can be explained to beancounters as a good investment.

How expensive is this? I don't have good quantifications of it, but
anecdotally, anything resembling (1) is fairly expensive.
It almost doubles the effort bug fixes require. Assuming, of course,
that there are just two different versions to support
(and yes, language/library breaking changes are not the only things
that cause such problems, but they are yet another
doubling factor).

I'm not suggesting that we should never make breaking changes. I am
suggesting that we should have bloody strong and good
reasons for them, and "this was found to be confusing to some users
here and there" doesn't even begin to cut it, and
"you can migrate with a tool" is an answer that gets laughed/scoffed
at or derided in my usual stomping grounds.

Now, let's move to something else, what *I* want from the tooling SG;
I want it to

1) figure out what kind of language/library changes improve tooling -
either by making tools easier to write, or more powerful
2) figure out what kinds of language/library changes are unnecessary
or less than necessary, and can better be handled by tooling

That is, what can SG15 do for WG21, and what can WG21 do for SG15's
constituents. Compiler-informed queries are nice,
but they are nice if they are useful for programmers doing programming
work (*); I actually care far less if they are a tool for
the committee to educate their guesses about what change breaks what where.

(*) like find declaration, find definition, find callers, show call
hierarchy.. that sort of stuff.

I realize that the goals I suggest above are vague. To shock you a
bit, I can give you a goal that is much more radical:
In 10 years' time, we will have a standard library API for compiling
and analysing C++ source code, modules, libraries
and packages.

What, too rad for you? :) Okay, feel free to take smaller steps in the
areas of the smaller suggestions I made. :P