Live data from Hacker News

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

haneycodes.net

751–760 of 887 posts

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

#751
post #667

Earlier quoted context omitted.

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…

> A module doesn’t solve that kind of type confusion, though. Static typing does. That's the root of all the problems, though, isn't it? JavaScript is just a terrible language. Actually, that's not really fair. It's a great little language for writing late-90s Dynamic HTML, maybe just a little too powerful. And that additional power enables people to build cathedrals of cruft in order to Get Things Done. I don't like…

It's easy to say things like this. It's a lot harder to actually suck it up and live with what happened. Try to make progress, remember that's what all of the offenders in this story are trying to do. Whether or not it is perceived like that by the community.

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

#752

Earlier quoted context omitted.

How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?

53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?

Who said anything about 64 bits?

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

#753
I just removed the tilde and caret of all my dependencies (in my package.json) and maybe that's the way to go. Seal a local version of your packages and don't update unless is completely needed. But I'm still worried about the fragility of the package environment.

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

#754
post #426

Earlier quoted context omitted.

> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

If you want to build is-bigger-than-5 yourself, I recommend pulling in fivejs[1] as a dependency. [1] https://github.com/jackdcrawford/five

Why is English the only language in which "Five" is capitalized?

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

#755
post #521

Earlier quoted context omitted.

Thought it was a typo on my part... but HN seems to be trimming running spaces.

HN isn't: your browser is. Runs of whitespace are collapsed in HTML to single spaces unless specifically styled otherwise. You can verify that they're there by viewing the page source.

I like to use non-breaking spaces for that kind of thing, although they still might collapse that? At least it doesn't wrap non-breaking spaces.

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

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

My problem with this, as an occasional JavaScript developer, is "discoverability" (as many others have mentioned). If I decide I need a left-pad function, and search on NPM, how do I choose which one is best? The one with the most downloads? Not always the best indicator of quality; perhaps it's just the oldest.

Not to mention the cognitive overhead of stopping programming, going to NPM, searching/finding/installing the module, then reading the documentation to understand its API. Isn't it simpler to `while (str.length < endLength) str = padChar + str;`? How can there be a bug in that "alternative naive inlined solution"? Either it works or it doesn't!

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

#757
post #730
post #665

Earlier quoted context omitted.

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

Yes, uncompositionality of callbacks leads to callback hell. Or to reinventing every single thing but for callbacks. Like array.map (which works with promises) or array.forEach (also works with promises) or every single synchronous function (they all work when passed to promises).

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

#758

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…

x >>> 0 changes a negative integer to an unsigned (positive) 32-bit integer. You can have integers greater than 32 bits. They're represented internally as floats. Bitwise operators make 32-bit assumptions, with the top bit as a sign bit, unless you do x >>> 0, in which case you can revert a sign bit overflow back to a positive integer. If you have a positive integer that's greater than 32 bits, x >>> 0 === x fails. The expression (84294967295 >>> 0 === 84294967295) is false.

Don't even get me started on negative zero.

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

#760

Earlier quoted context omitted.

53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?

Who said anything about 64 bits?

The complaint was that JavaScript doesn't have 64-bit integers but only 53.
Post reply on HN