4 ms·

What’s wrong with a function? Here’s an interesting discussion on the topic, btw: https://github.com/sindresorhus/ama/issues/10 https://github.com/sindresorhus

by dfee 3y ago

What’s wrong with a function? Here’s an interesting discussion on the topic, btw: https://github.com/sindresorhus/ama/issues/10 https://github.com/sindresorhus/ama/issues/10

tsimionescu 3y ago
Code is much harder to maintain than it is to create, overall. Adding lines of code to a project is a net negative in the long run if they are not actively maintained by the original author. So as a project maintainer, you don't really want lots of small contributions from random people who don't stick around, at least not when they are adding new behavior to your project. And having thousands of one-line dependencies is actually much worse than having one thousand-lines dependency, since you now depend on the whims of each of those creators not to stop distributing their work, not to change their license, not to inject malicious code, to address zero-days etc.. Ultimately external dependencies are a form of collaboration, and it's very hard work to efficiently collaborate with thousands of people.
- dfee 3y ago
  Ok. So you don’t like single line node modules. I don’t think I’ve ever used one. Maybe as a transient dependency, though. But a function could be written in multiple ways, and I’m not sure we actually mean “single line” here. You’re referring to something of arbitrarily small complexity. But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks. Now, I’m sure I’ve leaned on these sorts of dependencies. Especially ones that have a peer dependency on a broken release, where they monkey-patch the problem. Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break.
  - tsimionescu 3y ago
    > I don’t think I’ve ever used one. Maybe as a transient dependency, though. The left-pad debacle proved that much of the ecosystem actually depends on such packages, at least indirectly. > But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks. I'm not sure what the point is here. Of course a huge module might only expose one public function. That's perfectly OK. The context we were discussing was the question of whether an open-source project should be happy to accept a PR that only adds one (small) function to the project. And the same question then extends to publishing that single small function as a separate module that others should add dependencies on, since that is essentially what TFA is arguing for. But either way, the discussion was about modules that expose a small amount of (simple) functionality. And you're right, I'm saying "one line" as a proxy for that. > Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break. I don't understand this part at all. Perhaps what wasn't clear was what "ideal" I am proposing instead. My ideal is having a dependency tree that is both small (few direct dependencies) and flat (my direct dependencies should also have a small and flat dependency tree of their own). That necessarily gravitates towards fat modules that include lots of functionality under the maintenance of a single team. Of course, this also presupposes a package manager and build system that can efficiently ignore parts of those modules that are not being used in a particular program.
  - uxp8u61q 3y ago
    You mean transitive dependency?
    - dfee 3y ago
      Ha! Yes :)
- vineyardmike 3y ago
  Counter argument: 1000 one-liners may each need less maintenance. And bugs are more self contained. The example in the article is the Fibonacci algorithm and general helper methods. A “remove whitespace” method could easily be set and forgotten (esp with testing). A 1000 line library probably needs maintenance because there is more moving parts and if there’s a bug, you’ll have to test/update a lot more things. I think the solution to the problems raised are not small libraries but a large standard library with good composable tools. I don’t know the specifics of erlang but in many programming languages things like remove a string whitespace is easy to do inline with the STDLIB instead of downloading a helper method, either in a bigger context or alone.
deleted 3y ago
[deleted]
crabmusket 3y ago
I'm very familiar with that specific discussion. I find Sindre's arguments very convincing in regard to small modules. But he then assumes that small modules ~= small NPM packages. That's where his argument fails, IMO. Let's assume the alternative to "small NPM packages" is not "large NPM packages", but "small modules, vendored into my own repository". In this comparison, the benefits of small NPM packages become: - Transient dependencies are automatically managed for you - You can pull updates from the repository to get new features and bug fixes, and when you do this, as above, changes in transient dependencies are automatically managed for you - The package gets a vanity download count on npmjs.com There are meaningful tradeoffs here, but they're different to trying to rehash the benefits of modular code. Of course modular code is good. But packaging and distributing code is a whole different story. EDIT: I'm having a bit of a reaction against the excesses of the NPM ecosystem at the moment. As, I think, are a lot of developers. I hope the pendulum swings from its current state more towards "fewer, better dependencies". Not towards "dependencies the size of a single function".
- crabmusket 3y ago
  Darn it, s/transient/transitive

by dfee 3y ago

What’s wrong with a function? Here’s an interesting discussion on the topic, btw: https://github.com/sindresorhus/ama/issues/10 https://github.com/sindresorhus/ama/issues/10

tsimionescu 3y ago

Code is much harder to maintain than it is to create, overall. Adding lines of code to a project is a net negative in the long run if they are not actively maintained by the original author. So as a project maintainer, you don't really want lots of small contributions from random people who don't stick around, at least not when they are adding new behavior to your project. And having thousands of one-line dependencies is actually much worse than having one thousand-lines dependency, since you now depend on the whims of each of those creators not to stop distributing their work, not to change their license, not to inject malicious code, to address zero-days etc.. Ultimately external dependencies are a form of collaboration, and it's very hard work to efficiently collaborate with thousands of people.

dfee 3y ago
Ok. So you don’t like single line node modules. I don’t think I’ve ever used one. Maybe as a transient dependency, though. But a function could be written in multiple ways, and I’m not sure we actually mean “single line” here. You’re referring to something of arbitrarily small complexity. But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks. Now, I’m sure I’ve leaned on these sorts of dependencies. Especially ones that have a peer dependency on a broken release, where they monkey-patch the problem. Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break.
- tsimionescu 3y ago
  > I don’t think I’ve ever used one. Maybe as a transient dependency, though. The left-pad debacle proved that much of the ecosystem actually depends on such packages, at least indirectly. > But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks. I'm not sure what the point is here. Of course a huge module might only expose one public function. That's perfectly OK. The context we were discussing was the question of whether an open-source project should be happy to accept a PR that only adds one (small) function to the project. And the same question then extends to publishing that single small function as a separate module that others should add dependencies on, since that is essentially what TFA is arguing for. But either way, the discussion was about modules that expose a small amount of (simple) functionality. And you're right, I'm saying "one line" as a proxy for that. > Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break. I don't understand this part at all. Perhaps what wasn't clear was what "ideal" I am proposing instead. My ideal is having a dependency tree that is both small (few direct dependencies) and flat (my direct dependencies should also have a small and flat dependency tree of their own). That necessarily gravitates towards fat modules that include lots of functionality under the maintenance of a single team. Of course, this also presupposes a package manager and build system that can efficiently ignore parts of those modules that are not being used in a particular program.
- uxp8u61q 3y ago
  You mean transitive dependency?
  - dfee 3y ago
    Ha! Yes :)
vineyardmike 3y ago
Counter argument: 1000 one-liners may each need less maintenance. And bugs are more self contained. The example in the article is the Fibonacci algorithm and general helper methods. A “remove whitespace” method could easily be set and forgotten (esp with testing). A 1000 line library probably needs maintenance because there is more moving parts and if there’s a bug, you’ll have to test/update a lot more things. I think the solution to the problems raised are not small libraries but a large standard library with good composable tools. I don’t know the specifics of erlang but in many programming languages things like remove a string whitespace is easy to do inline with the STDLIB instead of downloading a helper method, either in a bigger context or alone.

deleted 3y ago

[deleted]

crabmusket 3y ago

I'm very familiar with that specific discussion. I find Sindre's arguments very convincing in regard to small modules. But he then assumes that small modules ~= small NPM packages. That's where his argument fails, IMO. Let's assume the alternative to "small NPM packages" is not "large NPM packages", but "small modules, vendored into my own repository". In this comparison, the benefits of small NPM packages become: - Transient dependencies are automatically managed for you - You can pull updates from the repository to get new features and bug fixes, and when you do this, as above, changes in transient dependencies are automatically managed for you - The package gets a vanity download count on npmjs.com There are meaningful tradeoffs here, but they're different to trying to rehash the benefits of modular code. Of course modular code is good. But packaging and distributing code is a whole different story. EDIT: I'm having a bit of a reaction against the excesses of the NPM ecosystem at the moment. As, I think, are a lot of developers. I hope the pendulum swings from its current state more towards "fewer, better dependencies". Not towards "dependencies the size of a single function".

crabmusket 3y ago
Darn it, s/transient/transitive