Live data from Hacker News

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

haneycodes.net

631–640 of 887 posts

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

#631
post #497
post #110

Functions are too small to make into a package and dependency. Pure functions don’t have cohesion; they are random snippets of code and nothing more. Who really wants a “cosine” dependency? We’d all really like a “trigonometry” dependency instead which encompasses many “tricky” functions that we don’t want to have to write ourselves. This is a pretty weak argument. What is "cohesion" and why do we care that modules h…

I would retort with: Packages are too big to make into a functional dependency. In the end, in this functions-as-dependencies world, a trig package would be something like: (name) => switch (name) { case 'sin': (x) => sin(x); break; case 'cos': (x) => cos(x); break; }

Packages are only too big if your infrastructure makes them too big.

A trig package like yours could be implemented on top of sin and cos packages if it's something you find useful.

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

#632
post #611
post #570

Earlier quoted context omitted.

So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?

> What's not to like? That depends; in the case of mathematics libraries they have to be bundled together because of functional dependencies. It's either that or ignoring DRY principles -- which if you do that, you're ignoring the entire point of what breaking things into submodules is intended to do .

Separate interface and implementation. cos and sin might well use common underlying code (by depending on the same module), but they should expose orthogonal interfaces.

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

#633

Earlier quoted context omitted.

A lot of javascript is going to be deployed to a website. Every line of code that isn't used is bytes you're sending to every user unnecessarily > Surely it's far less bloat than one submodule per function? How is that bloat? It's the same LoC whether it's 1000 modules or 1 after it's been compiled/minified

Bloat in the source code, build system, dependency management, overheads per submodule, complexity. I'm not arguing that there shouldn't be a math module but that you shouldn't split it up into such (imho) crazy small parts. Closure Compiler can remove any unused functions.

It's not bloat in the source code - if you don't care which pieces you depend on you declare a dependency on math, if you do care you list the specific pieces.

It shouldn't be (impactful) bloat or overhead in the build system or dependency management. That stuff should just handle it.

Most of the time you don't care and can just declare the dependency on math and let the closure compiler handle it. But sometimes it might be really important that a project only used cos and not sinh, in which case you want to enforce that.

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

#634
post #544
post #528

This is why one guy can now compete with say Google or Microsoft, because that guy uses code written and managed by more engineers then both Google and Microsoft have combined. Instead of paying hundreds of dollars to said companies, you can just NPM install "what you need".

Libraries/modules should help to solve complex problems where writing your own version is not optimal. Single line functions as modules, on the other hand, won't help you compete with Google or Microsoft and result in more problems than they solve. If a simple padding or "is this int positive?" is a complex problem, well, there are different professions than programmer's..

The less code you write, the less code you have to maintain. Even if it's just one less thing, it's a win.

The comonJS module pattern also helps tremendously, as your requires are block/function scoped. It makes it trivial to refactor (remove/rewrite) code.

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

#635
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…

I have an extremely hard time believing this module is not a joke, ditto for many other NPM modules.

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

#636
post #479

Earlier quoted context omitted.

FYI, you can reply to my comments if you click on their timestamp, in case the reply box isn't showing up > So if you're going to troll a solid argument by nitpicking, do it properly and get the details right. First of all, I don't appreciate you calling me a troll. Someone who mentions "5kb functions" clearly has no idea of what 5kb represents, period. And second, this is not a solid argument at all . There is logic…

You're mixing up development time & bandwidth used by client browser. I was addressing the latter. Not having to download a 500 kilobyte library in order to use a single function is a big reason why the node.js ecosystem is the way it is today. Yet it is completely unaccounted for in the article. The author did not go into how the Node.js community came about to this practice in the first place, before going on a ran…

I'd respect your comment quite a lot more if you'd stop calling people who disagree with you "trolls".

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

#637
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…

I get that author's point, but do you REALLY need a dependency module that tells you the type of something?

That's not a Lego block; that's an excuse.

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

#638
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…

I get that author's point, but do you REALLY need a dependency module that tells you the type of something?

That's not a Lego block; that's an excuse.

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

#639
post #595

Earlier quoted context omitted.

It's quite ironic how you're lecturing people about dependencies and bandwidth when you yourself don't seem to have a good grasp in your mind of how immense even 5 kilobytes is (you talk about 5kb functions). 5 kilobytes (well, KiB) is 5120 bytes. That's about 200-300 lines of code. If you're talking about minimized code, maybe up to 500 lines.

While a 5kb function is immense, I work on a legacy code base and I have seen functions up to 2000 lines long. You possibly overestimate the quality of code that people in business actually write. I've worked in a few places and all have parts of the code which I would thought were made up if submitted to the dailywtf. Also, have you ever seen a commercial library require >2MB of minified JS? Here's an example: http:…

I've dealt with such functions, but they're seldom the type of functions that other GGP is talking about (small, simple, exportable functions).

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

#640
post #589

Earlier quoted context omitted.

It's easy to write code that does the wrong thing quickly in any language, and IME that tends to be the usual result of choosing C.

ok, you are aware that the vast majority of the worlds software is written in C.... yes there are problems with it but it is still suitable for real-time, embedded, safety critical software of the sort I've been making quite successfully for close to 30 years. Don't fall into the 'C is the devil' trap, any tool can be misused.

Straight-up C is not at all suitable for safety-critical software. C plus various bolt-on tools for static analysis and the like can be usable, but is always going to be less effective (IMO) than a unified language where every tool is working according to the same rules.

There might be a few legitimate use cases for C, but I've seen people pick it for the wrong reason so often (and using C because "it would be performant" is entirely invalid IME).

Post reply on HN