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

841–850 of 887 posts

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

#841

Post by ssalazar »

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…

Im not really sure how this is an argument against DCE. If theres no way to tell at compile time if these functions will be used, then you have to include them in the final delivered code, whether or not you are using monolithic or micro packages or dead code elimination.

DCE will help you if you pull in huge-monolithic-package and only use one function from it. In that case its basically the same as if you had used the micro package.

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

#842

Post by ksenzee »

pcwalton wrote: post #245
ksenzee wrote: post #75

Earlier quoted context omitted.

> every line of code I write myself is a commitment That's true. However: Every dependency you add to your project is also a commitment. When you add a dependency, you're committing to deal with the fallout if the library you're pulling in gets stale, or gets taken over by an incompetent dev, or conflicts with something else you're using, or just plain disappears. If you add a dependency for just a few lines of code,…

> If you add a dependency for just a few lines of code, you're making a way bigger commitment than if you'd just copy/pasted the code and maintained it yourself. This is a problem with NPM, not with dependencies. With different package management systems with stable builds and lockfiles, then you pin to a specific version and there is no way upstream can cause problems. A lockfile is a pure win over vendoring.

You're talking about the purely technical aspects of package management that keep your build from breaking. My point is that there's a lot more to it than that. Lockfiles do not keep software from requiring maintenance. Introducing a dependency means handing off a chunk of your software project to someone else to maintain. If they do it wrong, you're on the hook for it.

For example, I was a maintainer for an admin UI component of the last version of Drupal core, and we decided to pull in a query string handling library written by Ben Alman. It was a good decision, and it hasn't caused any problems. But it still meant we were trusting him to maintain part of our codebase. It was also an implicit commitment to every user of Drupal that if Ben quit maintaining that library, we would step in and fix any problems that came up. You don't get rid of that commitment with a lockfile.

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

#844

Post by lotsoflumens »

dang wrote: post #840
userbinator wrote: post #350

Earlier quoted context omitted.

Small modules are easy to reason about Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are effici…

> By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand Well put. I've noticed a curious blind spot in how people account for complexity: we count the code that 'does' things much more than the code that glues those things together. This distorts our thinking about system complexity. A cost/benefit analysis that doesn't consider all the costs i…

I just saw this insanity a couple of days ago:

https://youtu.be/l1Efy4RB_kw?t=343

He refactored a Java application into 1400 classes!

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

#845

Post by lmm »

BinaryIdiot wrote: post #813
lmm wrote: post #648

Earlier quoted context omitted.

> Regardless I don't think I'd ever call very elementary code a "maintenance burden". Ever. Every line is another line that maintainers have to read and understand. > The point being: where it's possible to mitigate and remove dependencies I think you'd be crazy not to. Every dependency you can lose is another potential build issue or attack surface you're removing from your project. Disagree. If there are issues wit…

> Every line is another line that maintainers have to read and understand. Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity. > Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them Can…

> Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.

Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.

> Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).

So figure out a process and resolve that, once and for all. There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.

> Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you?

That's exactly why people were depending on this library.

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

#846

Post by brohee »

gitaarik wrote: post #838

Why was it removed anyway? I agree that the ability to unpublish something is the real problem, but I wonder why the author actually unpublished it. I wonder if the author knew about all the projects that depend(ed) on it. Maybe he/she actually did it as an evil experiment, though a very interesting and eye-opening experiment. Does anyone know?

https://medium.com/@azerbike/i-ve-just-liberated-my-modules-... discussed here in this thread : https://news.ycombinator.com/item?id=11340510

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

#847

Post by cousin_it »

Someone wrote: post #833
cousin_it wrote: post #678

Earlier quoted context omitted.

IMO the behavior of "average" should be unspecified if it's passed anything but a single nonempty array of numbers. Making it even a tiny bit more robust is wasted work. Moreover, it's harmful because it encourages sloppy calling code.

The committee that designed SQL had a different opinion.

Right, that's a different philosophy. You can use JS as a dynamic language with DWIM qualities, like SQL. But I prefer to write JS code as if it were a typed language without nulls, and use tools to enforce that. I think that approach will win.

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

#848

Post by pcwalton »

ksenzee wrote: post #842
pcwalton wrote: post #245

Earlier quoted context omitted.

> If you add a dependency for just a few lines of code, you're making a way bigger commitment than if you'd just copy/pasted the code and maintained it yourself. This is a problem with NPM, not with dependencies. With different package management systems with stable builds and lockfiles, then you pin to a specific version and there is no way upstream can cause problems. A lockfile is a pure win over vendoring.

You're talking about the purely technical aspects of package management that keep your build from breaking. My point is that there's a lot more to it than that. Lockfiles do not keep software from requiring maintenance. Introducing a dependency means handing off a chunk of your software project to someone else to maintain. If they do it wrong, you're on the hook for it. For example, I was a maintainer for an admin UI…

But if you write it yourself, you're also on the hook for it. So I don't see a meaningful difference here.

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

#849

Post by dang »

esailija wrote: post #726

No it's because they don't do the same thing at all. This comparison shows you clearly don't understand the first thing about promises.

This comment as well as https://news.ycombinator.com/item?id=11354704 break the HN guidelines. Please don't post uncivil comments regardless of how wrong or ignorant someone seems.

We detached this subthread from https://news.ycombinator.com/item?id=11351657 and marked it off-topic.

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

#850

Post by geoelectric »

lewisl9029 wrote: post #206
runin2k1 wrote: 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…

Percentage of module owners who you can't trust to not screw up their module: H

Risk of indirectly hosing a project with N module owners providing dependencies: 1-((1-H)^N)

Let's say H is very small, like 0.05% of module owners being the type who'd hose their own packages.

3 module owners: 0.15% chance your own project gets hosed

30 module owners: 1.49% chance your own project gets hosed

300 module owners: 13.93% chance your own project gets hosed

Keep in mind it's not just your dependencies, but your entire dependency chain. And if you think a module owner might hose some modules but not others, maybe H is actually the number of modules in which case 300 starts getting pretty attainable.

Upshot:

Not everyone is trustworthy enough to hang your project on. The more packages you include, the more risk you incur. And the more module owners you include, definitely more risk.

The micromodule ecosystem is wonderful for all the reasons described, but it's terrible for optimizing against dependency risk.

Takeaways:

Host your own packages. That makes you the module owner for the purposes of your dependency chain.

If you're not going to do that, don't use modules dynamically from module owners you don't trust directly with the success of your project.

I love collaborative ecosystems, but some people suck and some perfectly non-sucky people make sucky decisions, at least from your perspective. The ecosystem has to accommodate that. Trust is great...in moderation.

Post reply on HN