Date: Thu, 5 Apr 2018 12:06:43 -0400
I don’t control any of my customers. They pretty much have free will. :-)
Howard
On Apr 5, 2018, at 11:46 AM, Titus Winters <titus_at_[hidden]> wrote:
>
> How many people have experience providing tools to customers or code they don't control? I'd like to get a sense of where this is concrete and where this is assumption?
>
>> On Wed, Apr 4, 2018 at 6:08 AM Mathieu Ropert <mro_at_[hidden]> wrote:
>> I agree that a long term goal would be to require as little configuration as possible to build a project.
>>
>> I believe one thing we could look at is why so many projects rely on complex configuration, macros and whatnot.
>> (For example in my experience it was mostly due to portability concerns, either to work around compiler/platform quirks or because C++ didn't offer a portable solution to the problem)
>>
>> From there we could make recommendations to improve the language based on what we found lacking or requiring some workaround.
>> As Gaby said, if something (or lack thereof) is making tooling (and building) hard, we should try to address it.
>>
>> Cheers,
>> Mathieu
>>
>> On Wed, Apr 4, 2018 at 9:17 AM, Corentin <corentin.jabot_at_[hidden]> wrote:
>> But that's specifically why I think current tooling don't work reliably.
>> Of course compilers are seeing the code a certain way.
>> But developers work on all of the code. A project being a cohesive set of files.
>> There should be ( on new code ) no need for any more external information that "this is a set of files".
>> Point the tool towards a directory and refactor to you heart content.
>> Build systems are extremely important but should not be necessary for anything but building.
>>
>> Indexing, symbol renaming, doc generation, etc should probably not require a full blown build system to work.
>> And it should work on the code rather than a partial, incomplete view of the code.
>> Do we really think sidestepping this issue by running the tool for each known configuration ( a number which explodes exponentially as you mentioned) is a satisfactory long term solution ?
>>
>> Can we make source files self-sufficient sources of truth ? That's a goal I would like to see explored.
>>
>> We of course agree that tooling implies having a solid continuous integration / test suite.
>>
>>
>> PS : I didn't receive Gaby's email either.
>>
>>
>> Le mer. 4 avr. 2018 à 08:31, Peter Sommerlad <peter.sommerlad_at_[hidden]> a écrit :
>> Another CHF0.02:
>>
>> One important aspect for all kind of tooling is to have a way what consists of a 'build' or project. A lot of tooling as well as IDE suffer from the user experience for setting up a 'project' and get all settings correctly, so that tools see the same code in the same way as the ultimate compiler and linker are seeing it. The separate compilation model inherited from C that was rooted in the limited hardware platforms of the 1970s might no longer be appropriate, but separation of work is still important.
>>
>> May be this should even be a short term goal to standardize:
>> * what makes the whole executable program/object code?
>> * what build modes exist for a specific chunk of code? How do they combine with other chunks' build modes? How to reign the explosion of potential combinations to a practical limit?
>>
>> Regards
>> Peter
>>
>>
>>
>> Sent from Peter Sommerlad's iPad
>> +41 79 432 23 32
>>
> On 4 Apr 2018, at 02:03, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>
>> I will add my piece about long term goals later, but I just want to emphasize Titus here:
>>
>>
>>
>> • Refactoring isn't near impossible, it's just hard.
>>
>>
>> Absolutely.
>>
>> It would a fundamental mistake for SG15 to make, and WG21 to copy, in thinking that a tooling capability is an issue only if it is (nearly) impossible. If we are making something hard, or harder, we must think twice. Or thrice. When you make tooling harder, you are potentially reducing its availability. Think about it.
>>
>>
>>
>> -- Gaby
>>
>>
>>
>> From: tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> On Behalf Of Titus Winters
>> Sent: Tuesday, April 3, 2018 12:40 PM
>> To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>> Subject: Re: [Tooling] Proposed mission
>>
>>
>>
>> Refactoring isn't near impossible, it's just hard. (See most of the talks that Google has given at CppCon for the last few years - there's massive refactoring mentioned in most or all of 'em.)
>>
>>
>>
>> Macros are hard, but not that hard. Inappropriate/unsupported usage of an API causes far more pain - you can see stories about that in https://www.youtube.com/watch?v=u5senBJUkPc or the rules we've had to come up with in Abseil compatibility (https://abseil.io/about/compatibility) or my proposal at the standards level (http://wg21.link/p0921). But the tools we rely upon internally work because we control the build system and toolchain. If an arbitrary project's build isn't understandable, tools won't work. Similarly, if a project is deeply dependent on the quirks of a single compiler and that vendor doesn't provide refactoring tools, then we (as the committee or as the community) cannot rely on the existence of those tools.
>>
>>
>>
>> But all of that is fairly tactical - I'd really like to think about this as a far bigger picture thing. Setting a good long-term mission that gets us all of these shorter-term goals as a side effect is a good way to structure things - if we agree on the long term, then minor chaos in the short term still leads us in the right direction without getting too hung up on people's differences in priorities for tactical decisions.
>>
>>
>>
>> On Tue, Apr 3, 2018 at 2:32 PM Corentin <corentin.jabot_at_[hidden]> wrote:
>>
>> I wasn't at Jacksonville.
>>
>> Were the current issues discussed ?
>>
>> Aka what makes refactoring near-impossible today ?
>>
>> Of course, I have an answer to that ( macros ) - but it's probably not the only pain point.
>>
>>
>>
>> I don't believe anything added after 98 made things fundamentally more complicated for tools.
>>
>> (Exporting-macro modules might...)
>>
>>
>>
>> Once we identify the actual pain points it will be easier to work around them.
>>
>> Probably by introducing new language constructs - Lots of very smart people tried to make refactoring work over the past 30 years, I don't believe SG15 can improve on the state of the art without taking a completely new approach.
>>
>>
>>
>> So, here is an attempt to reformulate Titus' goal:
>>
>>
>>
>> Refactoring tools that people can trust blindly. (either because the tool works 100% of the time or notifies the user about 100% of the failure cases).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Le lun. 2 avr. 2018 à 22:08, Timur Doumler <cpp_at_[hidden]> a écrit :
>>
>> Hi Titus,
>>
>>
>>
>> While I think this is a great long-term mission, I believe this leaves out a big area where SG15 can provide value today, in the more immediate term.
>>
>>
>>
>> I believe we should spend some time on questions like:
>>
>>
>>
>> - What language features, that WG21 is working on today, make it harder (or easier) to write good tools for?
>>
>> - Are there areas where SG15 can provide guidance to WG21? Think about this scenario. New shiny language feature X has two possible design directions, A and B. Both seem to solve the problem similarly well. However, direction A would create a major pain-in-the-butt for tools vendors, whereas direction B wouldn’t. Should we not monitor, detect, and discuss such cases and then feed our insights back into WG21?
>>
>> - Are there areas where, instead of adding more stuff to C++, the problem would be more adequately solved with tooling?
>>
>> - Are there areas where language features pose significant challenges for tool vendors, and where it could be good for everyone if we had a platform to synchronise on those challenges? (*cough* *cough* modules *cough*)
>>
>>
>>
>> Cheers,
>>
>> Timur
>>
>>
>>
>>
>>
>>
>> On 2 Apr 2018, at 21: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.
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
Howard
On Apr 5, 2018, at 11:46 AM, Titus Winters <titus_at_[hidden]> wrote:
>
> How many people have experience providing tools to customers or code they don't control? I'd like to get a sense of where this is concrete and where this is assumption?
>
>> On Wed, Apr 4, 2018 at 6:08 AM Mathieu Ropert <mro_at_[hidden]> wrote:
>> I agree that a long term goal would be to require as little configuration as possible to build a project.
>>
>> I believe one thing we could look at is why so many projects rely on complex configuration, macros and whatnot.
>> (For example in my experience it was mostly due to portability concerns, either to work around compiler/platform quirks or because C++ didn't offer a portable solution to the problem)
>>
>> From there we could make recommendations to improve the language based on what we found lacking or requiring some workaround.
>> As Gaby said, if something (or lack thereof) is making tooling (and building) hard, we should try to address it.
>>
>> Cheers,
>> Mathieu
>>
>> On Wed, Apr 4, 2018 at 9:17 AM, Corentin <corentin.jabot_at_[hidden]> wrote:
>> But that's specifically why I think current tooling don't work reliably.
>> Of course compilers are seeing the code a certain way.
>> But developers work on all of the code. A project being a cohesive set of files.
>> There should be ( on new code ) no need for any more external information that "this is a set of files".
>> Point the tool towards a directory and refactor to you heart content.
>> Build systems are extremely important but should not be necessary for anything but building.
>>
>> Indexing, symbol renaming, doc generation, etc should probably not require a full blown build system to work.
>> And it should work on the code rather than a partial, incomplete view of the code.
>> Do we really think sidestepping this issue by running the tool for each known configuration ( a number which explodes exponentially as you mentioned) is a satisfactory long term solution ?
>>
>> Can we make source files self-sufficient sources of truth ? That's a goal I would like to see explored.
>>
>> We of course agree that tooling implies having a solid continuous integration / test suite.
>>
>>
>> PS : I didn't receive Gaby's email either.
>>
>>
>> Le mer. 4 avr. 2018 à 08:31, Peter Sommerlad <peter.sommerlad_at_[hidden]> a écrit :
>> Another CHF0.02:
>>
>> One important aspect for all kind of tooling is to have a way what consists of a 'build' or project. A lot of tooling as well as IDE suffer from the user experience for setting up a 'project' and get all settings correctly, so that tools see the same code in the same way as the ultimate compiler and linker are seeing it. The separate compilation model inherited from C that was rooted in the limited hardware platforms of the 1970s might no longer be appropriate, but separation of work is still important.
>>
>> May be this should even be a short term goal to standardize:
>> * what makes the whole executable program/object code?
>> * what build modes exist for a specific chunk of code? How do they combine with other chunks' build modes? How to reign the explosion of potential combinations to a practical limit?
>>
>> Regards
>> Peter
>>
>>
>>
>> Sent from Peter Sommerlad's iPad
>> +41 79 432 23 32
>>
> On 4 Apr 2018, at 02:03, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>
>> I will add my piece about long term goals later, but I just want to emphasize Titus here:
>>
>>
>>
>> • Refactoring isn't near impossible, it's just hard.
>>
>>
>> Absolutely.
>>
>> It would a fundamental mistake for SG15 to make, and WG21 to copy, in thinking that a tooling capability is an issue only if it is (nearly) impossible. If we are making something hard, or harder, we must think twice. Or thrice. When you make tooling harder, you are potentially reducing its availability. Think about it.
>>
>>
>>
>> -- Gaby
>>
>>
>>
>> From: tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> On Behalf Of Titus Winters
>> Sent: Tuesday, April 3, 2018 12:40 PM
>> To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>> Subject: Re: [Tooling] Proposed mission
>>
>>
>>
>> Refactoring isn't near impossible, it's just hard. (See most of the talks that Google has given at CppCon for the last few years - there's massive refactoring mentioned in most or all of 'em.)
>>
>>
>>
>> Macros are hard, but not that hard. Inappropriate/unsupported usage of an API causes far more pain - you can see stories about that in https://www.youtube.com/watch?v=u5senBJUkPc or the rules we've had to come up with in Abseil compatibility (https://abseil.io/about/compatibility) or my proposal at the standards level (http://wg21.link/p0921). But the tools we rely upon internally work because we control the build system and toolchain. If an arbitrary project's build isn't understandable, tools won't work. Similarly, if a project is deeply dependent on the quirks of a single compiler and that vendor doesn't provide refactoring tools, then we (as the committee or as the community) cannot rely on the existence of those tools.
>>
>>
>>
>> But all of that is fairly tactical - I'd really like to think about this as a far bigger picture thing. Setting a good long-term mission that gets us all of these shorter-term goals as a side effect is a good way to structure things - if we agree on the long term, then minor chaos in the short term still leads us in the right direction without getting too hung up on people's differences in priorities for tactical decisions.
>>
>>
>>
>> On Tue, Apr 3, 2018 at 2:32 PM Corentin <corentin.jabot_at_[hidden]> wrote:
>>
>> I wasn't at Jacksonville.
>>
>> Were the current issues discussed ?
>>
>> Aka what makes refactoring near-impossible today ?
>>
>> Of course, I have an answer to that ( macros ) - but it's probably not the only pain point.
>>
>>
>>
>> I don't believe anything added after 98 made things fundamentally more complicated for tools.
>>
>> (Exporting-macro modules might...)
>>
>>
>>
>> Once we identify the actual pain points it will be easier to work around them.
>>
>> Probably by introducing new language constructs - Lots of very smart people tried to make refactoring work over the past 30 years, I don't believe SG15 can improve on the state of the art without taking a completely new approach.
>>
>>
>>
>> So, here is an attempt to reformulate Titus' goal:
>>
>>
>>
>> Refactoring tools that people can trust blindly. (either because the tool works 100% of the time or notifies the user about 100% of the failure cases).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Le lun. 2 avr. 2018 à 22:08, Timur Doumler <cpp_at_[hidden]> a écrit :
>>
>> Hi Titus,
>>
>>
>>
>> While I think this is a great long-term mission, I believe this leaves out a big area where SG15 can provide value today, in the more immediate term.
>>
>>
>>
>> I believe we should spend some time on questions like:
>>
>>
>>
>> - What language features, that WG21 is working on today, make it harder (or easier) to write good tools for?
>>
>> - Are there areas where SG15 can provide guidance to WG21? Think about this scenario. New shiny language feature X has two possible design directions, A and B. Both seem to solve the problem similarly well. However, direction A would create a major pain-in-the-butt for tools vendors, whereas direction B wouldn’t. Should we not monitor, detect, and discuss such cases and then feed our insights back into WG21?
>>
>> - Are there areas where, instead of adding more stuff to C++, the problem would be more adequately solved with tooling?
>>
>> - Are there areas where language features pose significant challenges for tool vendors, and where it could be good for everyone if we had a platform to synchronise on those challenges? (*cough* *cough* modules *cough*)
>>
>>
>>
>> Cheers,
>>
>> Timur
>>
>>
>>
>>
>>
>>
>> On 2 Apr 2018, at 21: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.
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
Received on 2018-04-05 18:06:48