> I don't buy that a tool that's being sold for money would do that
If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not.
> if the tools are internal then by definition you have the ability to make changes to them.
This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool.
> Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling
The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.
If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not.
> if the tools are internal then by definition you have the ability to make changes to them.
This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool.
> Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling
The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.