Live data from Hacker News

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

haneycodes.net

41–50 of 887 posts

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

#41
This is from a client-side web dev perspective:

I'm hoping that proper support for ES6 modules to enable tree-shaking bundle builds (in the short term), and HTTP2 with client support for modules (in the long term), will allow us to head towards a world where we converge around a handful of large utility libraries.

In theory, tiny dependencies was supposed to allow us to only include code we actually needed in our bundled code. Bu the reality is that everyone uses different tiny dependencies for solving the same problem. So you end up with enormous bundles made up of different solutions to the same tiny problems.

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

#42
When I was prevented from upgrading Xcode/Swift for a project last year because of podfile dependencies, that cemented in my mind that every time I include a dependency, I'm putting myself at risk.

If I can spend half a day writing the code myself, I will -- because I know it will prevent headaches down the road. Yes, yes, I know any code I write adds the probability of bugs down the road. But at least the roadblock would be of my own doing, and not dependent on if/when the package maintainer upgrades their stuff.

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

#43
One of the things I've enjoyed the most while programming in Go for the past couple years is the standard library and how much the Go community emphasizes keeping external dependencies to a minimum. For most projects I find myself using few if any external packages.

Now of course there are times you'll want to reach for a library, say for something like an http router, and up until recently the dependency management side of Go has been lacking. But when a pattern or library arises that many find useful the core team is open to pulling that in to the standard library if a strong enough case is made, for example in the context package (https://github.com/golang/go/issues/14660).

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

#44
post #19
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 ;-) This is your fault for expecting free resources to remain free forever. If you care about build reproduction, dedicate resources to maintain a mirror for your dependencies. These are trivial to setup for any module system worth mentioning (and trivial to write if your module system is so new or esoteric that one wasn't already…

I agree. But I find two problems with your proposal:

1- Maintaining a mirror of dependencies can be a non-trivial overhead. In this app that I was working on, the previous devs had forked some gems on github, and then added that specific github repo to the requirements. But they did not do it for every dependency, probably they did not have time/resources to do that.

2- As a corollary to the above, sometimes the problem is not the package itself but compatibility among packages. E.g. package A requires version = 2.8 of package B. Now I hear you asking "then how did it compile in the frist place?" probably the requirement was for package A v.2.9 and package C latest version, so while A was frozen, C got updated. This kind of problems is not solved by forking on Github, unless you mantain a different fork of each library for each of your project, but that's even more problematic than maintaining dependencies themselves.

P.S. At least for once, it wasn't "my fault", I didn't build that app LOL ;-)

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

#45

Earlier quoted context omitted.

No, no, no Left padding is (almost in all languages) built-in, even C can do it with printf (edited) The problem is not having a library that offers that, but having this micro-module thing as a whole NPM module . No other language does that. If it was inside a string helpers, that's great. But don't make me one single module for just left-padding (or is-integer-number)

Uh, no Left Padding is NOT built-in in JavaScript. The proposal to add `String.prototype.padLeft()` was just added to ECMAScript 2016. JavaScript had a very minimal standard library, it's pretty asinine of you to compare it to C or any other language with a pretty extensive standard library.

I wanted to say that it's built-in in pretty much every other language apart from JS

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

#46
post #29
post #19

Earlier quoted context omitted.

> Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-) This is your fault for expecting free resources to remain free forever. If you care about build reproduction, dedicate resources to maintain a mirror for your dependencies. These are trivial to setup for any module system worth mentioning (and trivial to write if your module system is so new or esoteric that one wasn't already…

Most of the time this is something you inherit. Not something you wrote.

Yes that was my case.

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

#48
post #9

Nearly everyone has had it drilled into them the "Don't reinvent the wheel." nonsense for better or worse. I use lodash in almost every javascript project I start, big or small because it makes my life easier. I'd rather use the lodash isArray than roll my own. https://lodash.com/docs#isArray

Yeah but you're loading an entire library to use one function?

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

#50

Earlier quoted context omitted.

Uh, no Left Padding is NOT built-in in JavaScript. The proposal to add `String.prototype.padLeft()` was just added to ECMAScript 2016. JavaScript had a very minimal standard library, it's pretty asinine of you to compare it to C or any other language with a pretty extensive standard library.

I wanted to say that it's built-in in pretty much every other language apart from JS

But alas, here we are, talking about the JavaScript language and it's ecosystem.

It's easy to say "I don't see why there's a need for an 11 line module to pad left on a string" when your language of choice has a robust standard library with such abilities built in.

Post reply on HN