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

321–330 of 887 posts

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

#321

Post by other_herbert »

nbzklr wrote: post #223
lsiebert wrote: post #130

Earlier quoted context omitted.

You know what's worse? Javascript numbers are all floating point numbers, which means integers are 53 bits long. So, you might think this library would try to address issues this can cause, but nope, this is the average statement you'd write if you didn't know was a mantissa was and had never heard of big.js, bignumber.js, decimal.js, crunch.js or even strint (which represents integers as strings because wtf not).

That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.

As long as everything used is really an integer and that everyone you work with is careful to keep things as ints (oring with 0 and such)

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

#322

Post by colanderman »

nbzklr wrote: post #223
lsiebert wrote: post #130

Earlier quoted context omitted.

You know what's worse? Javascript numbers are all floating point numbers, which means integers are 53 bits long. So, you might think this library would try to address issues this can cause, but nope, this is the average statement you'd write if you didn't know was a mantissa was and had never heard of big.js, bignumber.js, decimal.js, crunch.js or even strint (which represents integers as strings because wtf not).

That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.

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

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

#323

Post by msbarnett »

onli wrote: post #129
raverbashing wrote: post #17

Earlier quoted context omitted.

Yeah, I thought the dependency thing was a joke (I mean, to have a package for is positive integer is already a joke, but come on) Really

I think it actually is not. That's from some years ago and my memory of it is fuzzy, but at that time it was surprisingly hard to check whether a variable is a positive integer – maybe it was a negative one though and that was harder? You'd think it is just checking whether it is an integer and bigger than 0, or just checking whether it is bigger than 0. And it is. But to get that code to work reliably, regardless of…

Be that as it may, is-positive doesn't handle any edge cases https://github.com/kevva/is-positive/blob/master/index.js

That's half the problem with these stupid micromodules; they're not abstracting complexity, they're obfuscating simplicity.

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

#324

Post by superuser2 »

sago wrote: post #308
Spivak wrote: post #303

Earlier quoted context omitted.

Alright, take a simple function like average. How might someone naively calculate the average? for n in list sum += n return sum / len(list) Which will fail but will probably be caught in the code review. Then a cleverer developer might think to write l = len(list) for n in list sum += n / l return sum Which will also fail but in more subtle ways, hopefully the senior dev will catch it in the code review. Then they c…

1. The algorithm in question does not do any of the latter 'better' approaches. 2. The pursuit of all edge-cases is a form of hubris. Your first version is fine in many cases (it is the algorithm used by the package referenced [edit:] and by both the Python and .NET standard libraries) and can be written inline. 3. At the point you are concerned with specific edge-cases, and need the 'correct' algorithm, you need to…

>It's even worse for a builtin function... You'd need to test it, code review it, and so on

If you can't trust built-in functions to do what they say on the standard library documentation, you're either paranoid or made a wrong choice of language. (Or you have some very compelling reason to be working in a language that's still rough, like the early days of Swift, which is an entirely different game).

>If you're really suggesting that you can't be trusted to calculate an average correctly

It's not about what you can be trusted to do, but what's worth spending your time on.

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

#325

Post by aub3bhat »

LoneWolf wrote: post #259
aub3bhat wrote: post #62

Earlier quoted context omitted.

The recursive folder structure in npm-modules was the first indication. At least Java had a single tree with com.bigco.division.application.framework.library.submodule.NIHObject.java

That recursive node_modules or whatever it is called was what made me hate this whole npm thing, specially because it is not centralized somewhere in my computer. And that means the same files a few times repeated on my drive just eating space. Being a Java developer I don't understand why the approach was not more like maven.

its a long standing issue, and gets worse when there is node_modules inside node_modules inside node_modules ... so on that someone suggested renaming node_modules to n_m . https://github.com/nodejs/node-v0.x-archive/issues/6960#issu...

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

#326

Post by EvanPlaice »

bbcbasic wrote: post #298
zanny wrote: post #144

Earlier quoted context omitted.

This is more a reflection of how bad the JS language is than anything. Real programming languages have means of standardizing the most common UX and simple patterns into a standard library. Javascript is a consortium hell that never gets updated sufficiently, and has no good standard library, so NPM basically replaces the standard library with a thousand micropackages.

Also it is a lot easier to get it wrong in JS. Is it null? Is it undefined? Is it bird? Is it a plane? No it's a string!(but sometimes a number). Good programming languages make it easy to write is negative e.g. isNegative = (<0) where implicitly by the 0 and < it will take a Num and return a bool and this is type checked at compile time.

Use the null object pattern.

If you're checking a value to see if it's set by testing for null/undefined, you're doing it wrong.

This is good advice for any language, not just JS.

Besides, using null as the default for an undefined value is a mistake. Null should indicate a non-value not the absence of a value. Maybe one day the static OOP languages will die so devs have a chance to learn the difference.

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

#327

Post by overgard »

nathancahill wrote: post #84
raverbashing wrote: post #24

Earlier quoted context omitted.

No, no, no Left padding is (almost in all languages) built-in, even C can do it with printf (edited) The problem is not having a library that offers that, but having this micro-module thing as a whole NPM module . No other language does that. If it was inside a string helpers, that's great. But don't make me one single module for just left-padding (or is-integer-number)

I think there's two points related to that: 1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart). 2) JS's "standard" library is so small, because it's the intersection of all of the browser implementations of JS dating as far back…

> 1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart).

JS isn't even remotely unique in this regard, almost every static language has had dead code removal for decades.

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

#328

Post by lugg »

foobarian wrote: post #242
idlewan wrote: post #230

Earlier quoted context omitted.

You'd have a good point, if all of those tiny but probably useful modules were given the use you're describing. Discoverability though is so poor that most of those modules are most likely just used by the author and the author's co-workers. If a typical npm user writes hundreds of packages, how the hell am I supposed to make use of them, when I can't even find them? Npm's search is horrendous, and is far from useful…

Another benefit of small well understood components is that they are easier to write tests for. Do these npm modules have good test coverage? Did the leftpad module have a unit test that would have caught the issue?

which issue? I thought we were talking about the random removal of left-pad and a couple hundred others.
Post reply on HN