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

271–280 of 887 posts

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

#271

Post by zbuttram »

brudgers wrote: post #137
zbuttram wrote: post #16

Earlier quoted context omitted.

So many people use lodash as a drop-in standard addon library that I'm surprised people aren't just using the padding functions that are right in there... Some of the packages that broke yesterday even have lodash included as dependencies already!

Looking at the changelog, there have been more than 70 versions of Lodash in less than four years. The first was in April 2012. [1] _.padleft does not exist. It was added as part of version 3.0.0 January 26, last year and renamed to _.padstart in Version 4.0 on January 12, this year. So in less than a year "padleft" came and went away because all strings don't start on the left and someone decided that "left" means "…

Damn, yeah, that's a totally valid reason. I was under the impression that lodash was more stable than to have that kind of stuff happen.

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

#272

Post by haddr »

While in general I agree with the article I must admit that I also strongly DISAGREE with the overall message. Especially with this: "Finally, stringing APIs together and calling it programming doesn’t make it programming."

Stringing APIs together is what actually programming is. This is building software and for instance when i use .toString() method I can easily forget how it is done, focus on other high level things and don't care about dependencies, as long as everything works fine.

Let's admit that the main problem here is with broken npm, rather than packages themselves. If someone has written the "leftpad" function, it is so I don't have to write it again, and I can save probably 15-40 min programming and checking some corner cases.

Also please note that javascript can be really tricky down in the details. So if there's anything that can help, it's better that it exists, rather than not.

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

#273

Post by formula1 »

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.

Im of the mind most employers are looking for "have you done stuff" "can you do stuff". Veey rarely are they looking for anyone extraordinary, simply a tool that works

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

#274

Post by zbuttram »

zbuttram wrote: post #23
NathanKP wrote: post #6

I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a solution available? However, I agree it is ridiculous to have a dedicated module for that one function. For most nontrivial projects I just include lodash, which contains tons and tons of handy utility functions that save time and provide efficient, fast implem…

Some of the libraries people were mentioning broke yesterday already have lodash as dependencies, I have no idea why they wouldn't have just been using this...

Someone mentioned below that lodash had some breaking changes related to the padding functions a couple times, which could be a totally valid reason to avoid using those. I was under the impression that the lodash API was more stable than to have that kind of thing happening.

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

#275

Post by jessaustin »

adrusi wrote: post #257
jessaustin wrote: post #132

Earlier quoted context omitted.

...you're making your code incompatible with anything that requires a higher or lower version of that library. Actually that's not correct when using node/npm (or anything else in the ecosystem like browserify). That is one of the impressive things about this platform: any number of different versions of the same module can be required by the same app. It would be nuts to do that in your own code, but as long as the…

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.

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

#276

Post by mdavidn »

sillysaurus3 wrote: post #235
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.

I'm not sure dead code elimination works in that situation. Consider: var obj = { a: ... b: ... c: ... } If a, b, and c are functions, there is not necessarily a way to determine at compile time whether they will be used at runtime. var prop = webrequest(); obj[prop](); In that scenario, a, b, and c cannot be eliminated. But it would be worth testing Google Closure Compiler to see what it does in what scenarios. I've…

In simple mode, Closure Compiler would rename the local variable "prop" but not alter the properties.

In advanced mode, Closure Compiler would globally rename properties and statically eliminate dead code. In your example, it would remove a, b, and c and break the dynamic invocation.

This behavior is all outlined in Closure's documentation with examples.

[1]: https://developers.google.com/closure/compiler/docs/limitati...

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

#277

Post by sago »

superuser2 wrote: post #141
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.

This sounds like a symptom of an inadequate standard library. I do expect to be able to call "average" on a list of numbers without writing it myself, but I expect that to be part of the language not a 3rd party package.

> I do expect to be able to call "average" on a list of numbers without writing it myself

Just out of interest, what kinds of functions would you expect to have to write yourself, if you're not happy about calculating the average of a list of numbers?

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

#278

Post by [deleted] »

monitron wrote: post #212
sdegutis wrote: post #155

Earlier quoted context omitted.

Every once in a while, I come to HN, and inevitably find a post about some new JavaScript technology on the front page, wherein I find some comment that gives me a new appreciation for the web app language I use at work, which fortunately is not JavaScript.

What is the web app language you use at work? I assume you're talking about something that runs on the client -- a web browser -- so it probably compiles down to JavaScript, right? JS literally has no numeric type that isn't a float, so how does your language escape this fundamental limitation?

[deleted]

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

#279

Post by Alupis »

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…

Can we ever achieve this?

We can't exactly search the code to find out what it does, otherwise you'd basically be reading all the code to discover it's true behavior, which negates the usefulness of modules in the first place...

Any search will have to rely on developer-made documentation, and/or meta data. This is great in theory, but documentation is rarely well maintained, and/or someone changes the code but neglects to update the documentation.

This leaves us with the situation we have today. A search that somewhat works kindof, and mostly you rely on googling the feature you need and looking for what seems to be the most popular choice.

I'm not sure how this situation can be made better, especially if we continue down a path of having all these "one-liner" libraries/modules that anyone can make and stick out there into the unsuspecting world. When I need a square root function, and my search returns 800 one-liner modules, how am I supposed to pick one that I know is reasonably well done, and does what it says it will do, without looking under the hood - you'll end up just picking whatever seems to be popular...

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

#280

Post by ep103 »

nly wrote: post #134

Nobody has forgotten. These people never knew to begin with. NPM/JS has subsumed the class of programmer who would have previously felt at home inside PHPs battery-included ecosystem. Before that, a similar set of devs would have felt at home with Visual Basic. Seriously, go visit the comments section on archived copies of the PHP documentation. You'll find code of a similar nature. If PHP had had a module system 10+…

This is the answer, 100%. All it takes to publish an npm package, is the command npm publish, and you're done. So of course it is no surprise that there are tons upon tons of seemingly useless or tiny projects (gotta pad out that github profile for those recruiters!), or that there are then plenty of packages that use them.

Add into that the fact that:

1) Javascript has a huge number of developers, and is often an entry-level language

2) The developers on this thread (I like to think of HN as at least slightly above average) are divided whether having small packages / large dependencies trees is a good or bad thing

3) Dependency management is something that matters mostly to long term (professional / enterprise / etc) applications, which is a subset of programming, and I wonder if not a minority subset of node.js projects in general.

4) If I'm writing a throwaway app or proof of concept, and therefore don't care about dependency maintenance, using as many dependencies as possible is a major time savor,

and of course you get this situation, and it seems to make perfect sense.

Personally, I wish there was an NPM Stable, where packages underwent much more scrutiny and security in order to get it, but nonetheless, nothing I've read so far about npm really scares me given the the above context. If you are a dev creating an unmanageable dependency tree for your enterprise app, you're a shitty dev. That doesn't necessarily mean that NPM is wrong for being so open in allowing others to publish their packages, or that smaller / more worthless packages shouldn't be allowed to publish.

That said, I would really like to hear a response to this post, as I have limited experience with different package management systems.

Post reply on HN