Live data from Hacker News

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

haneycodes.net

721–730 of 887 posts

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

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

That package is, at best, average... ducks (Edit: typo)

Don't be .... Mean.

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

#722
post #578

Earlier quoted context omitted.

Odd, the ones I use all have tests, thousands of downloads, and active bug trackers. If I reinvented the wheel, or copy pasted, I wouldn't get those things.

Doing a for loop is not equal to re-inventing the wheel. Words and phrases have lost their meaning nowadays. By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. Maybe they didn't forget how to program, as the article implies; maybe they never knew how to program in the first place.

Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel.

> By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules.

If there was, it would have been published and people would be depending on it. Instead, people use the stdlib first, then big lego bricks like underscore, then (when they don't want the bulk of big lego bricks) smaller lego bricks. A single capitaliseMap() might be in there but it's a much more specific case than padding.

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

#723
post #185

Earlier quoted context omitted.

I wish I could say you were joking. At best it comes off as ivory tower idealism, at worst the complete naivete of someone who doesnt code.

I'm not sure if you're saying this of my comment or the OP, but I code professionally every day in this style and it's working out just fine. And the smaller my modules get the better it seems to work.

It's not working out fine. You just haven't been around long enough to understand it.

JS code is the most disposable piece of any infrastructure. In all companies(mine included) that I know of, npm and the JS jenga tower of hell is the most brittle element that breaks every fucking day. It's the constant pain you can count on being around.

The stack and the dependencies are a moving target. Like.. every minute. If you had coded in any other language other then JS you would know that.

Come to me after 5 years and tell me if your "professional" JS code you're writing today is used by anyone and then we'll talk.

I'll be waiting.

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

#724
post #406

Earlier quoted context omitted.

Finding this module on NPM or npmsearch.com is pretty trivial compared to ensuring you implement this in a way that catches every edge case. > It manifests in much slower bug fixing I don't buy this at all, because I've done it myself many times. If you're waiting on a PR from the original repo owner to fix a Production bug, you're doing it wrong. It's trivial to copy the dependency out of node_modules and into your…

What are these arcane edge cases everyone is so afraid of?

I think it's because you never know what you're going to get with JS variables, and from what I've seen there's a strong tendency towards trying to fix or squash input errors to an insane degree within the JS culture.

Just let it crash if the user is trying to leftpad a boolean, for crying out loud.

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

#725

Somehow, someone always forgets that engineering is about trade-offs, and so every few years we can an indignant series of articles about how stupid and ignorant today's programmers are and how we should all go back to the same processes that they called stupid and ignorant 4-5 years ago. Relying on reimplementation, copy-paste, npm shrinkwrap, or various other ways of importing third-party code into your repository…

7. You automatically get malwares and backdoors released by your upstream dependencies.

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

#727

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…

It's interesting to me that people find this convincing. I find it to be complete insanity. People need their libraries, but putting everything in tiny buckets is just not working. Why aren't people working on good utility libraries instead? There's even some guy calling for a "micro-lodash". To me, as a Python engineer, lodash [1] is already a tiny utility library. I guess it's also about the fact that JS is a prett…

There is a practical reason for tiny modules in client-side JS that doesn't exist with Python: page load times. If your base layer is going to have third-party dependencies, they better be tiny and do only and exactly what you need.

That said, lodash core is only 4KB, and lodash gives you the ability to build it with only the categories or exact functions you want, so I don't understand what the purpose of a "micro-lodash" would be.

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

#728

Earlier quoted context omitted.

JS does not have an Integer type, so (x > 0) does not work. Now if you add all those checks necessary to see whether you're actually dealing with an integer here, you get to a point where you cannot be sure anymore whether there aren't any weird type coercion issues there and need to start writing tests. Suddenly your whole positive integer check took 1h to write and you still cannot be sure whether there's something…

A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write function isPositiveInteger(x) { return x > 0 && Number.isInteger(x); } and always pass it a number. (Of course, this shouldn’t even be a function, because JavaScript is confused about the definition of “integer” – maybe you really want…

The module checks that the positive integer is less than Number.MAX_SAFE_INTEGER constant, while yours would lead to unsafe comparisons if we trust its validity as a number.

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

#729
post #722

Earlier quoted context omitted.

Doing a for loop is not equal to re-inventing the wheel. Words and phrases have lost their meaning nowadays. By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. Maybe they didn't forget how to program, as the article implies; maybe they never knew how to program in the first place.

Writing your own solution, when you could use a common widely known solution, exactly matches both writing your own left pad and inventing your own wheel. > By the JS community's standards if I wanted code to capitalize the 3rd or sometimes 4th letters of a string, they would be 2 different npm modules. If there was, it would have been published and people would be depending on it. Instead, people use the stdlib firs…

A 1-line of code module matches your needs exactly just for today. When you have 100 such modules which don't quite work and don't quite need after a month(quite a long time for a JS project to exist untouched), then your dependency hell shows its ugly head.

If you had years of experience in a wide array of technologies and languages, you'd be aware of that which is, and has been, obvious to the rest of us for the past 2-3 decades.

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

#730
post #665
post #585

Earlier quoted context omitted.

We had, and still prefer (looking at npm stats) the async module. Eg: promise.then(function(){}).then(function(){}) is not substantially different than: async.waterfall([function(){}, function(){}]) Promise advocates kept pretending async didn't exist though, and everybody was using callback hell.

Nobody pretended that async didn't exist, we just knew its the best "solution" that ignored the problem. Which was: throwing away the entire language's compositional features, including the concept of input arguments and return values, results with... poor compositionality, of course.

I thought the problem was callback hell. I've sat through a bunch of promise talks and the problem was never 'JS should be more compositional'.
Post reply on HN