Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM and Left-Pad: Have We Forgotten How to Program?

haneycodes.net

Post reply on HN
Print view View original

361–370 of 887 posts

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#361

Post by l1ambda »

darawk wrote: post #28

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 implemen…

"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function."

--John Carmack

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#362

Post by thrillgore »

I started out really thinking Kik was wrong to sue this guy but like with all things, the longer this goes on the less sympathetic I grow.

Write your own goddamn utility classes, people. Or learn how to suspend package releases, include them in your projects, and smoke test your releases.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#363

Post by secoif »

danso wrote: post #346
jperras wrote: post #58

Earlier quoted context omitted.

Similarly, the `average` package on NPM is one that I came across: https://www.npmjs.com/package/average var average = require('average'); var result = average([2, 5, 0, 1, 25, 7, 3, 0, 0, 10]); console.log('The average for all the values is:', result); It's hard to not stare at that in complete disbelief; someone thought that it was worthwhile to create a package for determining the mean of an array of numbers.

While it demonstrates the problem of npm lacking namespaces (such that the word "average" is wasted on such a trivial implementation)...it doesn't seem anyone was using that library

npm has namespaces. https://docs.npmjs.com/misc/scope

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#364

Post by joeandaverde »

I completely agree with the author.

The loudest people in the Node community have been evangelizing this practice for as long as I can remember. This shouldn't come as a surprise.

The argument, "If I didn't write it I don't have to think about it" is ludicrous. I just have to point at the left-pad incident disprove the premise of this argument.

The analogy of building things with a bunch of npm lego blocks is laughable. Those responsible for advocating the use of trivial functions by acquiring module dependencies are leading the masses astray.

"But, If I find that there's a bug in a module I can AUTOMATICALLY fix it everywhere!"

No.

You still need to assess how the change to that module impacts any code that depends on it. Just by updating a module and posting a "minor" bug fix can lead to other bugs that RELIED on the behavior as it was originally written.

It's simple, write your own trivial functions. Test them. Maintain them.

P.S.

Another module that can easily be in-lined to every code base you own. (3 million downloads this week).

https://www.npmjs.com/package/escape-string-regexp

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#365

Post by userbinator »

coldtea wrote: post #354
lewisl9029 wrote: post #206

Earlier quoted context omitted.

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…

> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

add-1-to-a-number

This seems to be a very common example in educational materials about how to create a function in some programming language. Perhaps they should all be prefaced with "NOTE: you should not actually make such a function, because its triviality means that every time you use it you will be increasing the complexity of your code", or a longer discussion on when abstraction in general is appropriate and when it is not.

Ditto for any other abstraction --- I've found there's too much of an "abstraction is good so use it whenever you can" theme in a lot of programming/software design books and not enough "why abstraction can be bad" sort of discussion, which then leads to the "you can never have too much" mentality and the resultant explosion of monstrous complexity. Apparently, trusting the reader to think about the negatives and exercise discretion didn't work so well...

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#366

Post by jestar_jokin »

danneu wrote: post #314
jestar_jokin wrote: post #114

Earlier quoted context omitted.

Point 1 was addressed years ago by Google Closure Compiler, which used "dead code elimination". Also, the Haxe language, which compiles to JS, has DCE. Micro-modules is certainly a solution if you don't want to use pre-processing or compilers. So is copy/pasting, or manually writing your own util libs, which seems safer than relying on third parties to provide one-liners for you.

Javascript must be written specifically to anticipate Google Closure Compiler's dead code elimination. Since the vast, vast majority of Javascript doesn't work with it, the issue certainly wasn't addressed years ago.

"Addressed" doesn't mean "solved!" ;)

Yes, you're right, making use of dynamic behaviour will break DCE.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#367

Post by sago »

superuser2 wrote: post #347
sago wrote: post #301

Earlier quoted context omitted.

Okay, but how long would you think it sensible to look for, test and assess a package for being 'well-maintained' before you'd consider it a better use of your time to average a list of numbers? If you had to, say, add a list of numbers together, without averaging them, would your first thought be to go searching for a package, given that you know some languages have a 'sum' function? Some languages have an 'add' fun…

>would your first thought be to go searching for a package No, because if this isn't in the standard library (or a very simple one-liner from standard library functions like "fold +") then I don't want to be working in this language. If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library, or at least a "math" package, particular…

> If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library ... If it's really just this, I'll probably paste a Stackoverflow answer.

Sorry, can I get this straight, we're talking about sum() now, right? I'm genuinely amazed.

> thinking through the pitfalls of the implementations of basic math operations is not a good use of time

I suppose there's a trade off, at some point it is less time to find, check, and invest in a package rather than write its contents. For lots of cases it is definitely faster to use a package. But we're talking about averaging a list of numbers here, or adding them, right? Doesn't this strike you as rather bizarre to be having this discussion over things you should be able to write trivially?

> What would you do if your language didn't have exponentiation?

It depends what I need it for and what kind of exponentiation. I'd use inline exponentiation by small positive integers. I'd be concerned if my team were writing pow(x, 2) + pow(y, 2), for example. If I needed fractional exponentiation (e.g. pow(k, 3.567)), then I know that's beyond the realm of something that could be implemented in a couple of lines. If the language didn't have it, I might write it, certainly, especially if it wasn't part of a bigger suite of functionality I need.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#368

Post by n0us »

coldtea wrote: post #354
lewisl9029 wrote: post #206

Earlier quoted context omitted.

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…

> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

No, you see "is-bigger-than-5" clearly does 4 different things. You need these modules:

module.exports = exec("===");

module.exports = bigger(a, b){return a > b};

module.exports = () => return "than";

module.exports = (a) => a.search('ABCD...');

.. or something like that. These are all plugins of course.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#369

Post by mr_justin »

It's not that anyone has forgotten, it's that a lot of people never learned how to in the first place. Every programmer community is riddled with these problems but the NPM world seems to be the worst. The ruby gem "american_date" annoys me to no end. It's just a highly-specific implementation of Time#strptime. Gah

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#370

Post by masterleep »

lewisl9029 wrote: post #206
runin2k1 wrote: post #7

Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…

This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…

That argument sounds like an enterprise architect explaining why the AbstractReusableBeanFactoryGenerator is going to increase productivity.
Post reply on HN