Live data from Hacker News

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

haneycodes.net

571–580 of 887 posts

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

#571

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…

> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/ama/issues/10#issuecomment-1... . If anything looking at sindresorhus's activity feed: ( https://github.com/sindresorhus ) perfectly supports the author's point. Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line f…

> Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though...

Rather than copy paste someone else's unmaintained thing and handle all the bugs, or write their own code and unit tests, they use the same library as a few thousand other people?

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

#572
The author missed the point about modularity in Javascript.

Small packages done right, well tested = maintenable, reusable, stable code.

The problem does NOT comes from packages. The problem comes from un-publishing public packages and centralized repository server.

I have a java project with a lot of dependencies. Does it mean it's bad ? No, but if maven repos are closing tomorrow, my project will not build as well.

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

#573
post #566

Earlier quoted context omitted.

Do you seriously think that "word starts with a capital letter" is an easy function to write? I feel like you haven't spent enough time with Unicode.

return string[0] === string[0].toUpperCase(); You're welcome!

TIL 1 is a capital letter.

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

#574

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?

If those functions are reusable or complex enough (partly due to deficiencies in javascript the language, sure) then why not?

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

#575
post #512
post #441

Earlier quoted context omitted.

Oh, but javascript is dynamically typed, so it doesn't matter if your sin-module works with a different kind of arbitrary-precision decimal number module than your geolocation module, your cosine module or your openg-draw-triangle or opengl-draw-circle modules... /sarcasm

It's not sarcasm if it's true!

OT but apt to this community - That's what I thought, but after a lifetime of 'correcting' people, I looked up the definition of sarcasm. Turns out that the sarcastic-sounding truths I'd been deploying for decades were indeed by-the-book sarcasm rather than 'I can't believe it's not sarcasm'.

Key quote from brilliant word-talking-guy Henry Fowler: "Sarcasm does not necessarily involve irony [but it often does] ... The essence of sarcasm is the intention of giving pain by (ironical or other) bitter words."

So, we circle back to Node.js by way of pain and bitterness. Sounds about right.

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

#576
post #515

Earlier quoted context omitted.

what you describe is the "-flto" option in GCC and I believe the equivalent in JS is donr by Google Closure compiler.

He described not Link Time Optimization (-flto), but the very basic linker functionality: to only include required functions. C/C++ has a weird compilation model where each source file is translated to machine code separately, with placeholders for unknown function addresses. Thus it is trivial to take only required functions. -flto, on the other hand, allows to reverse this process to allow interprocedural optimizat…

@TickleSteve below me: "without this, removal is only performed within the compilation-unit"

Not quite. When you link to a static library (.a) with lots of .o object files in it, only those object files will be linked that are actually used by your program.

I first learned about this when I looked at the source of dietlibc, and wondered about every function being in a separate file. That enables the aforementioned trivial optimization, even without -flto.

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

#577
post #264

Earlier quoted context omitted.

Discoverability though is... poor seems like an argument for improving discoverability, not against having small modules.

Discoverability happens with standardization. Why search through millions of unknown packages when a standard library would have it all right there?

Because the standard library is where modules go to die. Slaving the release cycle of a library to the release cycle of the language is bad for the health of that library, especially in the case of javascript where code often has to be written to run on old browsers with old versions of the standard library.

Now having a metalibrary that depends on a curated collection of popular/useful utilities is probably a good idea - but isn't that exactly what many of the libraries that broke due to depending on left-pad were?

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

#578
post #442

Earlier quoted context omitted.

Perhaps another reason for this is that Javascript is inherently unsafe. By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors. Other languages handle this with compilers, may be strongly typed, and/or have features that don't allow nulls. Javascript doesn't exactly have that luxury. So maybe it makes sense in J…

> By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors. In practice, many, if not most, of these one-line modules don't even work correctly, and it is difficult to get people to care to collaborate on fixing them instead of just replacing them with a new one-line module that works slightly better as the concept…

Odd, the ones I use all have tests, thousands of downloads, and active bug trackers. If I reinvented the wheel, or copy pasted, I wouldn't get those things.

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

#579
This isn't forgetting to program, it's a deliberate choice as to how library code needs to be organised. We can disagree about choices made, but let's not assume other people aren't able to code as well as we think we can code.

That being said, I think this is a perfect example of where a good concept (small, tightly scoped modules) is applied dogmatically at the cost of the codebase. It's the node.js equivalent of AbstractRequestFactoryFactoryFactory stuff you see in Java, and the Mock Messes you see in Ruby.

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

#580
post #503

...maybe it's time a committee of really smart people sit and sip through all the most used modules below N lines of code or smth, and just write an opensource JS-stdlib, hopefully merging in top 30% most used methods of Lodash too? Node/NPM is a great example of why too much democracy and decentralization is bad . Just gather some experts and have them centrally plan a "standard library" then impose it as "industry…

There is also a big programmer efficiency to be gained by having batteries included library: The new person coming to a project has learned the same batteries already, and it need not to re-learn new set of minipackages the last person working on a project has used.

In fact this should be the key selling point for stdlib to JavaScript. It actually saves money from their employers if trivial functions are mostly in the same place.

However pushing a stdlib is difficult there is a lot of hate for Python's "kitchen sink" library in JavaScript world which is totally misplaced. It maybe founded on fact that you should then minify the whole package to use one function in it, but this could be solved with dead code elimination (with proper type checking) in the minifier.

Post reply on HN