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

101–110 of 887 posts

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

#101

Post by NeutronBoy »

mastazi wrote: post #44
emidln wrote: 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…

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 prob…

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

You've precisely identified the trade-off. You basically have three options. You can

1. Maintain a local repo of your dependencies (high effort)

2. No dependencies, include everything as 'first-class' code (lower upfront effort, but v. messy)

3. Rely on third-party repos (easiest, riskiest)

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

#102

Post by emidln »

mastazi wrote: post #44
emidln wrote: 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…

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 prob…

This problem is solved by mirror dependencies and pinning the versions. Even against a git repo, pinning to a particular sha is something that is possible.

Automatically upgrading versions (i.e. not pinning versions) in a production build is an anti-pattern.

These sound like problems incurred due to a previous lack of software engineering rigor. As an industry, when we encounter challenges like this we should be learning how to solve them without reinventing the wheel. Pinning versions and maintaining mirrors of dependencies (whether that's an http caching proxy for npm/pypi/maven/etc or keeping a snapshot of all dependencies in a directory or a filesystem somewhere) is something that any company requiring stability needs to take seriously.

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

#103

Post by mastazi »

mmanfrin wrote: post #64
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…

Shouldnt the Gemfile.lock have prevented that? It takes your gemfile and makes a specific-version locked file of those gems.

The gemfile.lock must have been "gitignored" at some point, because it had much older packages than the ones in Gemfile. Background: all we had was a git repo and did not have access to any "living" installation.

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

#104

Post by larkinrichards »

I wanted to write this post after the left-pad debacle but I've been beaten to it.

I think we got to this state because everyone was optimizing js code for load time-- include only what you need, use closure compiler when it matters, etc. For front end development, this makes perfect sense.

Somewhere along the line, front end developers forgot about closure compiler, decided lodash was too big, and decided to do manual tree shaking by breaking code into modules. The close-contact between nodejs and front end javascript resulted in this silly idea transiting out of front-end land and into back-end land.

Long time developers easily recognize the stupidity of this, but since they don't typically work in nodejs projects they weren't around to prevent it from happening.

New developers: listen to your elders. Don't get all defensive about how this promised land of function-as-a-module is hyper-efficient and the be-all end-all of programming efficiency. It's not. Often times, you already know you're handing a string, you don't need to vary the character that you're using for padding and you know how many characters to pad. Write a for loop; it's easy.

Note that this is exactly the sort of question I ask in coding interviews: I expect a candidate to demonstrate their ability to solve a simple problems in a simple manner; I'm not going to ask for a binary search. Separately, I'll ask a candidate to break down a bigger problem into smaller problems. In my experience, a good programmer is someone who finds simple solutions to complex problems.

Note: rails is similarly pushing back against developers that have too many dependencies:

https://www.mikeperham.com/2016/02/09/kill-your-dependencies...

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

#105

Post by agumonkey »

nv-vn wrote: post #68
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.

And 54 people found it a worthwhile package to install _this week alone_.

Let's say these are just prescient trolls. For our sanity.

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

#106

Post by tomc1985 »

21 wrote: post #26
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…

I think this is some sort of cargo cult UNIX minimalism - do one thing and one thing only.

No, its a byproduct of programming-interview-via-GitHub-repo

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

#107

Post by ksenzee »

joantune wrote: post #87
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,…

OR: you depend on a specific version of the library, that you know that works, and you have none of those problems.

You can't escape problems by bundling specific library versions. You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.

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

#108

Post by jacobolus »

jdmichal wrote: post #81
jacobolus wrote: post #63

Earlier quoted context omitted.

You should then go dive into the passAll function: https://github.com/tjmehta/101/blob/master/pass-all.js It’s written in such a way that every time you call... passAll(f1, f2, ..., fn)(args..) ... there are something like 5 + 2n attribute accesses, 5 + 3n function calls, 3 + n new functions created, as well as some packing and unpacking of arguments, not including the actual application of the functions to the argum…

I'm more disappointed that it doesn't short-circuit the operation at all. It applies all the functions, THEN it determines whether all of them passed. Even worse, it uses `every` (which does short-circuit) to determine that all the functions are, indeed, functions, but apparently the ability to use that function to determine whether every predicate passes was missed.

It could have been a simple for loop with a break whenever one evaluates false. Blazing fast in every javascript engine, and easy to see all the code in one place.

Instead, it’s a slow tower of bloat, which you need to read 5 files to reason about.

Javascript implementation:

    function passAll() {
      var fns = [].slice.call(arguments);
      return function() {
        for (var i = 0, len = fns.length; i
Or Coffeescript (including the function check):

    passAll = (fns...) ->
        for fn in fns then if typeof fn isnt 'function'
            throw new TypeError 'all funcs should be functions'
        (args...) ->
            (return false if not fn args...) for fn in fns
            true

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

#109

Post by jlg23 »

sebringj wrote: post #34

This is a non-issue and taking focus away from the real issue. The issue is the security hole that NPM opens up when a namespace can be grabbed up by anyone if the original developer pulls out.

The OP is deliberately talking about a completely different issue that just happened to be spawned from the recent drama.

He is talking about learning to code vs asking google for implementations of even the most trivial things and about what a useful library is.

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

#110

Post by panic »

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 have it? Joe Armstrong, one of the creators of Erlang, has argued the opposite (http://erlang.org/pipermail/erlang-questions/2011-May/058768): that lots of small, individual-function modules are better than a "misc" module that grows endlessly and may overlap with other people's "misc" modules.

Calling a function instead of writing the code yourself doesn't mean you've forgotten how to program! The real problem here is the cost and risks associated with dependencies in general (both of which are actually lower for single-function modules), and the broken package removal policies of npm.

Post reply on HN