[saurik]

If you find yourself copying code someone else in your organization wrote rather than abstracting it to a function in a shared library or building a more declarative framework to manage the problem, something horrible has happened.

[maccard]

Sometimes boilerplate is unavoidable. As an example, how do you send a GET request with libcurl in C with an authorization header? I can't tell you offhand, but I can tell you the file in my codebase that does have it, because I've duplicated the logic for two separate systems.

[saurik]

So you are saying you would rather every project in the world have at least one--if not, thanks to making it easier via Copilot, many--copies of this code rather than one shared library that provides a high-level abstraction for libcurl?... At least for your own code, how did you end up with two copies of duplicated logic rather than a shared library of functionality?

[maccard]

> So you are saying you would rather every project in the world have at least one--if not, thanks to making it easier via Copilot, many--copies of this code.

Absolutely not, not at all. I'm suggesting that copying and pasting happens, particularly in the context of a single project.

> At least for your own code, how did you end up with two copies of duplicated logic rather than a shared library of functionality?

At what point is it worth introducing an abstraction rather than copying? Using my libcurl example, you can create an abstraction over the~ 10 lines of initialization, but if you need to change it to a POST, then you're just implemnenting an abstraction over libcurl, which is just silly.

[saurik]

If you have 10 lines of repeated code with one line changed to make it GET vs POST, introducing an abstraction isn't "silly": it is simultaneously both ergonomic and advantageous, as not only is libcurl's API extremely verbose (as it is a low-level primitive), if you ever need to add another line of code to that initialization--which totally happens over the years, due to various security extensions you might need to either enable or disable with respect to acceptable TLS settings, or to tune performance parameters related to connection caching, or to add a header to every request (for any number of reasons from debugging to authentication)--you can do it in one place instead of umpteen number of places. The libcurl API is itself a leaky abstraction of the underlying TLS libraries in places, so if you ever realize you need to switch SSL libraries (a space in which there has been absolute upheaval in recent years) you are going to reach for shared abstractions; and like... to take this to its ultimate conclusion: I use libcurl as a fallback for Linux, but if you want to correctly support the user's settings for proxy servers--which are sometimes needed for your requests to work at all--my code is abstracted so I can plug in entirely different HTTP backends instead of libcurl, such as Apple's CFNetwork (which you absolutely should be using if at all possible on iOS). You act like abstraction is somehow a bad thing or some inherent cost you want to avoid, when it should absolutely take you less time to wrap duplicated code into a function than to duplicate it in the first place, and if IDE features (including Copilot) are somehow making you think it is easier to throw a ton of duplicated code everywhere, that is part of the argument for why those features are dangerous... they are apparently undermining all the work people did onto refactoring code browsers that are designed to help users locally manage abstraction instead of mitigating poor architecture :/.