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

311–320 of 887 posts

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

#311

Post by overgard »

Here's the funny thing that gets forgotten: in a lot of commercial software, 3rd party dependencies need to go through legal to get properly vetted and attributed and so on. This also usually requires an engineer (to be able to answer things like if it's dynamically linked or not, etc.).

As staid and corporate as it might sound initially, it's a very smart thing to do. One screw-up with licenses could be catastrophic. Are you all really checking that carefully?

I can't even imagine how any sort of proper legal checks could be done with a trillion micro libraries.

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

#312

Post by Someone »

anexprogrammer wrote: post #208
elwell wrote: post #154

Earlier quoted context omitted.

Sounds like the author was aiming for something to put on his resume: e.g., "Author of 25 libraries on NPM, some with more than 500K downloads." etc...

Well if I was interviewing the guy, my second or third question would be "tell me about these packages you published on NPM" It's going to be damn hard to make an average function sound impressive.

In JavaScript, the API could be fairly complex. Thing is, JavaScript doesn't have arrays of numbers. So, what should the function do if the array passed in contains a null, an undefined, a string such as "7", "012", "008", or "2+3", a function, another array, a hash, etc?

I can easily see this grow into a function accepting options indicating such things as "null values are zeroes", "ignore null values", "evaluate string arguments", etc, or maybe into a factory that produces customized averaging functions.

For example, average([null,1,2,3],[4,5]) could either be 3 (the average of all numbers), 2.5 (sum of numbers divided by number of 'root' items), undefined (input format error), 3.25 (average of average of [1,2,3] and average of [4,5]), etc.

And what if it gets passed arrays of equal size? "average([1,2,3],[7,4,5])" could easily be interpreted as a vector average, and produce [4,3,4]

Silly? Yes, but if you want to write a robust library in JavaScript, you have to think about what to do with all these kinds of input.

And of course, there are the simple variants of harmonic mean, arithmetic mean, and geometric mean, and several others (https://en.m.wikipedia.org/wiki/Average)

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

#313

Post by jdminhbg »

adambard wrote: post #5

I think it speaks to just how lacking the baseline Javascript standard library is. The libraries that come with node help, but all of this stuff seems like it should be built-in, or at least available in some sort of prelude-like standard addon library. The lack of either leads to all these (apparently ephemeral) dependencies for really simple functions like these. That said, I work with Java, Clojure and Python most…

This seems like the right answer to me. It's not that we forgot how to program, it's that Javascript forgot a stdlib. You could easily write your own left-pad function in any language, but a stdlib (or this module) gives you a standard way to reference it, so you don't have to look up what you named it or which order the args go in.

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

#314

Post by danneu »

jestar_jokin wrote: post #114
nathancahill wrote: post #84

Earlier quoted context omitted.

I think there's two points related to that: 1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart). 2) JS's "standard" library is so small, because it's the intersection of all of the browser implementations of JS dating as far back…

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.

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

#315

Post by CGamesPlay »

idlewan wrote: post #230
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…

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…

The 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.

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

#316

Post by mozumder »

jt2190 wrote: post #264
idlewan wrote: post #230

Earlier quoted context omitted.

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…

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?

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

#317

Post by iamleppert »

I couldn't agree more. I've been using the new ES6 style module syntax for a few days now because a co-worker forced me to, so he would use my library.

I'm not convinced its worth it compared to the simplicity of commonjs and module.exports. You have to pull in babel, which has over 40k files to do all this.

Why are people destroying the beautiful simplicity that is javascript? Can those people please go back to java?

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

#318

Post by adrusi »

jessaustin wrote: post #275
adrusi wrote: post #257

Earlier quoted context omitted.

And that kind of works in a dynamic language. You could make it work in a statically-typed language, but then the problems will become more apparent. If X depends on Y and Z1 and Y depends on Z2, and Y exposes an object created by Z2 in its public API, the X developers might look at the Y api docs and try to call Z1 functions on that Z2 object! Worst of all, it might very well work in the normal cases, and the issue…

Yeah I'm sure it sucks for distro packagers. Why are they using npm, though? It's not designed for their use case. Actually though you're just talking about some bugs in X, or possibly some design flaws in Y. Passing [EDIT, because bare objects are fine:] class instances around like that is the real code smell. So much coupling, so little cohesion. We call them "modules" because we like modularity.

It's not that packagers are using npm. It's that they might want to package a node application for their distro's package system, and now they have to sift through thousands of npm packages (already a nightmare). They can't just make a system package for every npm package, not just because that would violate packaging guidelines for any reasonable distro, but because one project can pull in multiple versions of a single package. The Nix and Guix crews can handle that (and that they can is as much of a bug as it is a feature).

There is no clean way of packaging a typical node application.

Passing class instances around like that is the real code smell.

Often, yes, but not always. Allowing fine-grained control over performance is one good reason that a library might expose class instances from one of its dependencies.

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

#319

Post by Gigablah »

lintiwen wrote: post #251

I see two kinds of programmers here. Good programmers understand the risks of making your system depend on something you don't have control really well; They know how keeping system complexity low is like an good investment which makes your life later easier (low maintaining costs). Bad programmers stacks up technical debts such as including unnecessary dependencies until the system no longer works.

> Good programmers understand the risks of making your system depend on something you don't have control really well

For example, the quality of your own code.

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

#320

Post by overgard »

mastazi wrote: post #3

Usually, dependency hell doesn't bite you, until it does. Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-) I recently had to rebuild a large RoR app from circa 2011 and it took me longer to solve dependencies issues than to familiarise myself with the code base. Excessive dependencies are a huge anti-pattern and, in our respective developers communities, we should try to circul…

> Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-)

Let's be honest though, in the current trendy javascript ecosystem these people will already be two or three jobs away before the consequences of their decisions become obvious. Most of the stuff built with this is basically disposable.

Post reply on HN