5 ms·
You'd have a good point, if all of those tiny but probably useful modules were given the use you're describing. Discoverability though is so poor that most of
by idlewan 11y ago
You'd have a good point, if all of those tiny but probably useful modules were given the use you're describing.
Discoverability though is so poor that most of those modules are most likely just used by the author and the author's co-workers.
If a typical npm user writes hundreds of packages, how the hell am I supposed to make use of them, when I can't even find them? Npm's search is horrendous, and is far from useful when trying to get to "the best/most supported module that does X" (assuming that random programmers rely on popularity to make their choice, which in itself is another problem...).
- foobarian 11y agoAnother benefit of small well understood components is that they are easier to write tests for. Do these npm modules have good test coverage? Did the leftpad module have a unit test that would have caught the issue?
- lugg 11y agowhich issue? I thought we were talking about the random removal of left-pad and a couple hundred others.
- zachrose 11y agoNo, leftpad has four test cases and they are all obvious, given the leftpad API. Would I write tests for my own leftpad implementation if I were not farming it out to a dependency? Its possible. More likely I would want to understand the intent behind using leftpad in my application or library, and have test for "formatTicket" or whatever it is that I'm actually doing. But for all the talk about tiny modules that cover surprisingly tricky edge cases, this is not one of them.
- lewisl9029 11y agoYou're totally right. Most developers don't develop this way, and that makes the benefits of this approach far less pronounced than they would be if they did. It also doesn't negate the benefits entirely, of course.
- jt2190 11y agoDiscoverability though is... poor seems like an argument for improving discoverability, not against having small modules.
- MaxGabriel 11y agoDoesn't apply to Javascript, but something like Haskell's hoogle (stackage.org/hoogle could help with a small module approach. It lets you query for functions matching a certain type signature, like this: https://www.stackage.org/lts-5.9/hoogle?q=%5Ba%5D+-%3E+a+-%3E+Bool https://www.stackage.org/lts-5.9/hoogle?q=%5Ba%5D+-%3E+a+-%3...
- mozumder 11y agoDiscoverability happens with standardization. Why search through millions of unknown packages when a standard library would have it all right there?
- 80286 11y agoYeah, I think the natural question here is: why doesn't TC39 round up all these basic packages and add them to the standard library? I've seen other languages criticized for having too large a standard library, but if this is the alternative... left-pad was released under WTFPL, so in this particular case there'd be no legal barriers to it. (And I'd assume that, for any libraries with a restrictive enough license, it wouldn't be a hard sell on TC39's part -- if they put out an announcement that they were going to do that, I'd go panning for street cred, and I wouldn't be the only one.) An alternative could be to pull all this stuff together into one big bucket of Legos and package it with a code analysis tool at the beginning of your build process to strip out everything you don't need from the bucket... but I'd guess that's either already been done or a stupid idea for reasons I don't know yet.
- spion 11y agoIts not about legal barriers, its about the incredible amount of work to precisely specify everything, which is required for any web standard.
- Alupis 11y agoCan we ever achieve this? We can't exactly search the code to find out what it does, otherwise you'd basically be reading all the code to discover it's true behavior, which negates the usefulness of modules in the first place... Any search will have to rely on developer-made documentation, and/or meta data. This is great in theory, but documentation is rarely well maintained, and/or someone changes the code but neglects to update the documentation. This leaves us with the situation we have today. A search that somewhat works kindof, and mostly you rely on googling the feature you need and looking for what seems to be the most popular choice. I'm not sure how this situation can be made better, especially if we continue down a path of having all these "one-liner" libraries/modules that anyone can make and stick out there into the unsuspecting world. When I need a square root function, and my search returns 800 one-liner modules, how am I supposed to pick one that I know is reasonably well done, and does what it says it will do, without looking under the hood - you'll end up just picking whatever seems to be popular...
- PeCaN 11y agoWe could have something similar with full dependent types a la Idris: you could write a proof and search for a function that satisfies it. If such a thing were popular and huge amounts of Idris code were written, you could write only proofs for your program and the Idris system could go download and piece together your program! That would be very cool, but I'm not sure how much easier it would actually turn out to be. Also to do anything useful you'd probably have to restrict the language to be non-Turing-complete.
- andy9775 11y agoSimilar idea but what if you were to write your tests first and then upload them to a site that pieces together the required modules to pass them and generates an API against the modules.
- PeCaN 11y agoBecause finding code that passes arbitrary tests is undecidable in the general case. (Same reason the pseudo-Idris language would have to be non-Turing-complete)
- CGamesPlay 11y agoThe isArray package has 72 dependent NPM packages, it's certainly not undiscoverable. The leftpad package gets 5000 downloads a month, that's quite a bit of testing for edge cases, compared to the none that I would have gotten had I implemented this myself. Intuitively, this thread wouldn't exist if your assertion were correct.
- vacri 11y agoAnd when a bug is found, instead of fixing it in one place once, you now have to hope that all of your deps and all of their deps update themselves appropriately.
- rycfan 11y agoWhich is great if you are one person and you fix the bug in your own code. What you're ignoring is that if everyone writes their own version, then the same problem exists. That bug has to be fixed across every (buggy) implementation. A well-defined dependency system where it is easy to discover and update to a new version isn't a matter of hope.
- hacknat 11y agoEdge cases for a padding function? Your comments make me think that the author's point is valid.
- mirekrusin 11y agoEdge case for left padding - when you provide empty string as padding filler. It can go into infinite loop if not written correctly.
- deleted 11y ago[deleted]
- kislotnik 11y agoWrite a damn unit test for your padding function. We should share unit tests, not one-line libs. Libs with unit tests can be one-liners and be as fine-grained as we like, since it's something your users don't have to download