Live data from Hacker News

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

haneycodes.net

641–650 of 887 posts

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

#641
post #596

Earlier quoted context omitted.

> But regardless of how many insults get thrown around, or how many people seem to think JS is useless or that it's a horrible language, its probably my favorite (and I've done professional work in non-trivial applications from C and C++, to Java and go, to python, Ruby, and PHP to BusinessBasic and even some lisp). I see one common thread between all those languages you list: none of them has a decent type system. I…

I've actually played with OCaml a bit, and Haskell a bit less. The problem is that I don't know what "problems to solve" with them, and there is no way I'm going to use something like that at work, so I kind of run out of steam before I really get into it. I might shoot for Scala next time. We don't use Java anywhere at my current job, but I might play around with it in a personal project for a while. I really like t…

I tried to write a bit about my use cases at http://m50d.github.io/2014/05/16/signs-your-java-program.htm... and http://m50d.github.io/2015/04/21/effects.html (apologies for formatting issues). Basically I find the really useful problem that advanced type systems solve is keeping track of cross-cutting concerns (e.g. database transactions, audit logging - the kind of thing you'd be tempted to use AOP for) in a consistent way.

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

#642
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…

What I want to know is how many systems does the author of is-positive-integer have implicit root access to? Sounds to me like publishing oneliners on NPM is a trivial way to build a botnet.

Seems like the answer is "none" by default, from https://docs.npmjs.com/misc/scripts#user

> If npm was invoked with root privileges, then it will change the uid to the user account or uid specified by the user config, which defaults to nobody. Set the unsafe-perm flag to run scripts with root privileges.

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

#644
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 end up spending most of my working life working on other peoples code, rather than new features I end up debugging and fixing bad code. (I actually rather like it)

The majority of code I have ever seen is awful (20 years across large + small companies) but that is why I am hired to fix awful code so I am skewed. The amount of times I have seen people implement something simple, in a convoluted error prone was is unbelievable.

I know this seems ridiculous but when you see time and time again how people fail to do the simplest things it seems like a good idea.

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

#645

Earlier quoted context omitted.

and it uses another 1LOC package. https://github.com/sindresorhus/number-epsilon/blob/master/i... and no, the edge cases argument does not apply to either of them. Wow.

Would you like to memorise that number yourself to use in your app?

What memorise? How about this for a dependency:

https://www.google.com.au/search?q=es6+epsilon

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

#646
post #570
post #420

Earlier quoted context omitted.

The equivalent in C would then be replacing #include and "-lm" with #include #include #include #include … and "-lsin -lcos -ltan -lsinh …" Which is nuts no matter what language you are coding in.

So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?

There's a cognitive load to every additional thing you need to know to use a module. At a certain point, added flexibility becomes more trouble than it's worth.

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

#647
post #318

Earlier quoted context omitted.

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

Is Node.js itself appropriate for packaging? I think maybe not. It changes really quickly, and has done for some time. Anyone coding in Node installs the particular versions she needs without regard to the distro. Most Node modules are just libraries installed in and for particular projects. There are tools written in node, but for the most part they focus on coding-related tasks that also tie them to particular projects, e.g. beefy or gulp. There's no need to install such tools above the project level, and certainly no reason to install them on the system level.

A distro that still packages python 2 (i.e. all of them) has a particular "velocity", and therefore it has no business packaging Node or anything written in it. Maybe a distro could package TJ's "n" tool (helpfully, that's written in bash rather than node), which would actually be handy for distro users who also use Node, but that's it.

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

#648
post #600

Earlier quoted context omitted.

> It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of cust…

> Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of custom code. In my experience with using npm since it's release, module authors will spit out modules very quickly then, after some period of time, abandon them without passing them onto other people. At which point I have to assume all future maintenance…

> 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 with npm shrinking not working then you absolutely need to resolve them - but resolving them is an O(1) problem no matter how many dependencies you have. Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one. You already depend on your packaging/dependency tools, so you might as well use them all the time.

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

#649
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…

I think that there's a certain wishfulness bordering on naïveté to this pursuit. We tell ourselves that we are managing complexity by having small, well-tested units that are reused by an entire community. But software complexity continues to exist. We think we are mitigating the complexity of our own software. But the complexity really just shifts to the integration of components.

Anyone that has been around long enough has war stories about getting two relatively simple pieces of software working with each other. In my experience, integration problems are often the most difficult to deal with.

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

#650
post #272

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

> Let's admit that the main problem here is with broken npm It is absurd to have packages suddenly retracted and important parts of the ecosystem stop functioning. This never happened with other languages I have used. Maybe we need a way to make sure the packages are always going to exist. Checksumming and adding the checksum to the version number would be useful too.

That's why there are proposals for immutable and distributed packages managers. Look at gx for instance. This is probably the future for package managers maintained by community.
Post reply on HN