3 ms·

It's a balance, most things in live are. Seeing things in absolutes sets you up for failure, or at least limited success. --- As a side note if we speak abou

It's a balance, most things in live are. Seeing things in absolutes sets you up for failure, or at least limited success. --- As a side note if we speak about dependencies instead of code reuse in general: dependency pinning and not updating is thoroughly underutilized. Sure you probably don't want to do it for idk. openssl, or your web framework. But reviewing, pinning and forgetting about small self contained dependencies as long you don't run into bugs can be a pretty good idea (through depends a lot on the language, immutability of dependencies, etc.). Edit: Also making it easy to change code when requirements change doesn't mean adding all kinds of generic abstractions to your code. It mean keeping code clean and simple and avoiding implicit logic dependencies enough to make code changes easy. Adding a lot of generic abstractions can make it harder to change things instead of easier.

alfalfasprout 4y ago
Pinning and forgetting is also a fantastic way to be riddled with security vulnerabilities in a not so short span of time! And a great way to make it a pain for people to upgrade to newer versions of dependencies since they'll need to jump several major versions in some cases.
- dathinab 4y ago
  that's why I said for small self contained libraries and depending on the language and tooling obviously you should never pin openssl or frameworks or similar but you anyway should have tooling in place to report security vulnerabilities in you supply chain, so as long as you don't use a language where simple bugs are prone to be security vulnerabilities this isn't a problem for security similar because they are small self contained dependencies upgrading across multiple major versions doesn't matter and if your language has a proper module system you might never need to upgrade at all (i.e. allowes sainly multiple versions of transitive dependencies, ie. not C or python) like think about dependencies so simple that you are considering you copy paying them into your code (with attribution). Maybe not as absurdly simple as leftpad but still very simple. Or in other words the kind of single source file libraries which rarely ever have any updates because shortly after being written they are "complete". Or at least are wrt. the features you use.
toast0 4y ago
> Edit: Also making it easy to change code when requirements change doesn't mean adding all kinds of generic abstractions to your code. It mean keeping code clean and simple and avoiding implicit logic dependencies enough to make code changes easy. Adding a lot of generic abstractions can make it harder to change things instead of easier. Exactly, when you have two parts of your system that do the same thing but for different reasons, when one of them gets a new requirement, you'll be in a better place with code that was previously redundant than if both places called into a single implementation.

alfalfasprout 4y ago

Pinning and forgetting is also a fantastic way to be riddled with security vulnerabilities in a not so short span of time! And a great way to make it a pain for people to upgrade to newer versions of dependencies since they'll need to jump several major versions in some cases.

dathinab 4y ago
that's why I said for small self contained libraries and depending on the language and tooling obviously you should never pin openssl or frameworks or similar but you anyway should have tooling in place to report security vulnerabilities in you supply chain, so as long as you don't use a language where simple bugs are prone to be security vulnerabilities this isn't a problem for security similar because they are small self contained dependencies upgrading across multiple major versions doesn't matter and if your language has a proper module system you might never need to upgrade at all (i.e. allowes sainly multiple versions of transitive dependencies, ie. not C or python) like think about dependencies so simple that you are considering you copy paying them into your code (with attribution). Maybe not as absurdly simple as leftpad but still very simple. Or in other words the kind of single source file libraries which rarely ever have any updates because shortly after being written they are "complete". Or at least are wrt. the features you use.

toast0 4y ago

> Edit: Also making it easy to change code when requirements change doesn't mean adding all kinds of generic abstractions to your code. It mean keeping code clean and simple and avoiding implicit logic dependencies enough to make code changes easy. Adding a lot of generic abstractions can make it harder to change things instead of easier. Exactly, when you have two parts of your system that do the same thing but for different reasons, when one of them gets a new requirement, you'll be in a better place with code that was previously redundant than if both places called into a single implementation.