Timeline for Why should we reuse code as binary modules instead of copy/pasting?
Current License: CC BY-SA 4.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21, 2023 at 1:49 | comment | added | RonJohn | @Alexander "is designed to be extensible" that's the hard part. Which is, of course, why we get paid so much money!!! :D | |
| Oct 20, 2023 at 15:38 | comment | added | supercat | @candied_orange: There can be significant performance advantages to access fields directly versus through get/put functions. A useful feature of some kinds of "binary module" designs is that client code can load multiple modules which represent different forks of the same code base and use matching names but with different semantics, provided that objects created by each module are only used with that module. | |
| Oct 20, 2023 at 14:53 | comment | added | Alexander | @ChrisPeacock Imagine a one-off script that you delete within 15 minutes of it doing its job. But that's besides the point, I'm clearly not arguing that's lots of code that will never need changes. The text is bolded and italicized for a reason :) | |
| Oct 20, 2023 at 14:10 | comment | added | Chris Peacock | "No changes ever needed" = not real life. What about a bug fix? | |
| Oct 20, 2023 at 13:06 | comment | added | RonJohn | The first thing I did when becoming lead DBA was to unify a dozen backup scripts -- all of which did the same thing, except for different number of tape drives, or full-vs-incremental backups -- into one heavily parameterized script. It made my life a lot easier, although early on I had to add a couple of more parameters. | |
| Oct 19, 2023 at 20:58 | comment | added | candied_orange | @supercat yes, that could be disastrous. That's why we have the private keyword, The law of Demeter, and leading underscores. Duping isn't the only way to keep strangers out of your code. | |
| Oct 19, 2023 at 20:54 | comment | added | supercat | ...the whereabouts of all code that accesses the field directly, it may be hard to make performance improvements without breaking things. | |
| Oct 19, 2023 at 20:54 | comment | added | supercat | ...via the aformentioned function, changing that function compute the value if needed would be an easy change. If, however, many client programs whose whereabouts are unknown to the library authors read the field directly, such a change could be disastrous. If client code that uses the field directly uses a version of the library that eagerly computes it when an object is created, such code will work fine, and client code which accesses the field via library function would work fine even with a library version that computes it lazily, but if the library author doesn't know... | |
| Oct 19, 2023 at 20:51 | comment | added | supercat |
@candied_orange: My point was not to pass any judgment about whether using separate copies of code is better or worse than using shared functions, but rather to note that code sharing often extends outside the control of individual maintainers. Further, if code to manage some kind of object has a function like int get_woozle_fnord(struct woozle *p) { return p->fnord; } it may not be clear whether client code should always chain through that function, or sometimes do something else. If it would become desirable to have field fnord be lazily computed and all client code accesses it...
|
|
| Oct 19, 2023 at 19:09 | comment | added | candied_orange | @supercat that problem is only made worse when code is duped to avoid creating a library. No the problem with the library is it must use some abstraction. And if you picked the wrong abstraction adapting to the new change is hard. That is, unless you just go ahead and dupe even while using a library. In fact, duping is a good first step if you need to adjust the library's abstraction. | |
| Oct 19, 2023 at 18:32 | comment | added | supercat | In many cases, multiple applications whose authors know nothing about each other will use a the same revision-controlled source files. Such scenarios make it essentially impossible to find all the places that might need to be changed if some aspect of a library changes. | |
| Oct 19, 2023 at 17:04 | comment | added | Alexander | "is designed to be extensible" that's the hard part. | |
| Oct 19, 2023 at 17:03 | comment | added | S.D. |
Benefits a library still has, no matter the case: no duplicated unit tests, no chance of accidental edits, lesser lines of code ( in dependent project ). Also the 1 case = Hard is not true if library is designed to be easily extensible, customizable and configurable.
|
|
| Oct 19, 2023 at 16:41 | comment | added | Tomeamis | As an addition to the "no changes ever needed" point: changes also include bugfixes, which, in 99% of cases will need to be changed in all the places the code is used. So unless you expect that the code you just wrote has no bugs whatsoever (ha ha), you should lean towards deduplication by default. | |
| Oct 19, 2023 at 15:50 | history | edited | Alexander | CC BY-SA 4.0 |
added 8 characters in body
|
| Oct 19, 2023 at 15:34 | history | edited | Alexander | CC BY-SA 4.0 |
added 26 characters in body
|
| Oct 19, 2023 at 15:14 | comment | added | Alexander | @NotThatGuy A questionable premise indeed. Predicting the kinds of changes you'll need to make is always hard. Nonetheless, you're forced to make your best guess, to inform what's relevant to abstract, and what's not. | |
| Oct 19, 2023 at 15:13 | comment | added | Alexander | Hehe sorry for the suspenseful asterisk. Peter's right, it was a stray syntax error from the bolding I used. | |
| Oct 19, 2023 at 15:11 | history | edited | Alexander | CC BY-SA 4.0 |
added 11 characters in body
|
| Oct 19, 2023 at 13:13 | comment | added | NotThatGuy | For "No changes ever needed" (a questionable premise), there is still a relatively small benefit of limiting the size of your code base. If there is significant amounts of duplication, it could take more time to understand the code, to track down bugs and to find some code you're looking for. When you need to change 1 case, that can often be a fairly easy case of adding a parameter to a method (although it depends on the nature of the change). It can also often be really hard to judge how often something would need to be changed in future, and how big those changes would be. | |
| Oct 19, 2023 at 12:12 | comment | added | Peter Cordes |
@Thomas: Perhaps a stray * in the markdown after ending **bold** with the end of an italic also nearby.
|
|
| Oct 19, 2023 at 7:48 | comment | added | Thomas | @gerrit Wondering about that too. I guess the footnote could just say "Ha ha." in a sarcastic tone. | |
| Oct 19, 2023 at 6:18 | comment | added | gerrit | Was the asterisk after "No changes ever needed" meant to refer to a footnote of some kind? | |
| Oct 18, 2023 at 18:53 | comment | added | Alexander | @candied_orange Yes, we're agreeing with each other. That's the point my post is making. | |
| Oct 18, 2023 at 18:50 | comment | added | candied_orange | That's the rub of using any abstraction, not just libraries. It's easy to set up the wrong abstraction that doesn't adapt well to change. A good hedge against that is don't use libraries that are deep. Before adding anything external ask yourself, "If I have to scrap this and write the parts of it we really need myself is this how I'd want to be talking to it?" This is why adapters are so popular. | |
| Oct 18, 2023 at 18:41 | comment | added | Alexander | "One way to "decouple things" in "hard" is to just duplicate." Yep! But the this can actually get really difficult. Say you need to modify some tiny bit of behaviour really deep into an entire library, which doesn't have any built-in customization options, seams, etc.. You probably don't want to fork the entire library just to change one small bit, so you'll have to find a way to introduce a seam or customization point. This can be hard. | |
| Oct 18, 2023 at 17:29 | comment | added | candied_orange | One way to "decouple things" in "hard" is to just duplicate. You can duplicate deduplicated code. As for "very hard" you can mark your duplicated code by saying where it came from. But yeah, that's still error-prone. | |
| Oct 18, 2023 at 16:19 | history | answered | Alexander | CC BY-SA 4.0 |