Comment by darawk
11 years ago
Everything in this article is categorically wrong and antithetical to every principle of good programming ever articulated. The only problem here, as others have already noted, is that NPM allows people to delete published packages.
Small modules are not evidence of a problem, and they certainly aren't evidence of an inability to implement these things on the part of the people depending on them. Why would I implement left-pad myself when there is already a well-tested implementation that I can install? Building up an ecosystem of tiny abstractions, bit by bit, iteratively and evolutionarily, is how we get robust, well-designed complex systems. We don't get there by everyone reinventing the left-pad function to sate some misplaced appetite for self-reliance.
The author seems to make some arbitrary distinction between things that are 'large enough' to be packaged and 'pure functions' which are 'too small' to be their own modules, and I just couldn't disagree more. Tiny, pure functions are ideal modules. They facilitate the greatest degree of re-use, most clearly articulate what they ought to be used for, and stateless things are, in general, more composable than stateful things. There is no better unit of re-use than a tiny, pure function.
I don't know why you were downvoted, but I agree with you 100%.
Pure functions are indeed a good target for modularity and deserve proper documention and proper testing, at the very least.
For the readers of this comment:
* How many functions did you not commented last time you wrote some code?
* How many functions do you leave untested?
* How many functions did you wrote more than once?
* How many "trivial" functions did you wrote that actually took you 3 hours, because it's actually tricky, so you checked other implementations and tried to wrap your mind around it.
Check haskell's hoogle to a small sample of this concept.
> Why would I implement left-pad myself when there is already a well-tested implementation that I can install?
You call 4 basic assertions "well-tested"?
https://github.com/azer/left-pad/blob/master/test.js
a) I think that's a fine number of tests for a module this simple, which is itself an argument in favor of small modules. And I think it's four more assertions than anyone implementing this inline in a project would have.
b) The details of this particular project are orthogonal to the philosophy of small modules generally. Whether or not this module is well implemented or well tested has no real relation to whether or not it is a good idea to compose tiny modules.
a) It's about half of what I'd write for my own, where I would make sure to test all edge cases (e.g. input string being longer than padding length) as well as Unicode characters. Writing expectations is cheap, fixing bugs later isn't.
b) I agree, but you were the one offering "well-testedness" as an argument :)
You are assuming well tested is referring to unit tests, rather than the wealth of developers depending on and running it in their projects daily.
Don't forget how many different targets there are for JavaScript, even if you had a test environment with limitless budget, it wouldn't compare to having a popular package on NPM.
What if it was well-tested?
What if it was well-typed?
What if it was awesomely documented?
Would that be ok? I'm asking, because a lot of the discussion in this post comes a single simple function being a dependency.
I wish I could say you were joking. At best it comes off as ivory tower idealism, at worst the complete naivete of someone who doesnt code.
I'm not sure if you're saying this of my comment or the OP, but I code professionally every day in this style and it's working out just fine. And the smaller my modules get the better it seems to work.
It's not working out fine. You just haven't been around long enough to understand it.
JS code is the most disposable piece of any infrastructure. In all companies(mine included) that I know of, npm and the JS jenga tower of hell is the most brittle element that breaks every fucking day. It's the constant pain you can count on being around.
The stack and the dependencies are a moving target. Like.. every minute. If you had coded in any other language other then JS you would know that.
Come to me after 5 years and tell me if your "professional" JS code you're writing today is used by anyone and then we'll talk.
I'll be waiting.
2 replies →
"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function."
--John Carmack
He wouldn't put that small function in a package (or even a separate file) though.