"Small modules are easy to reason about"
No... "appropriately sized modules are easy to reason about"
In this case... "Appropriate" has gone out of the window!
NPM and Left-Pad: Have We Forgotten How to Program?
691–700 of 887 posts
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#692Earlier quoted context omitted.
Small modules are easy to reason about Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are effici…
Perhaps another reason for this is that Javascript is inherently unsafe. By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors. Other languages handle this with compilers, may be strongly typed, and/or have features that don't allow nulls. Javascript doesn't exactly have that luxury. So maybe it makes sense in J…
I think it's a very valid (and concerning) point. JavaScript is made in way that one fears to implement isPositive or isArray.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#693Earlier quoted context omitted.
Two points: - Breaking out is-positive-integer hasn't reduced the number of paths to test. You have not gained anything, you've added overhead. - 100% test coverage is rarely a good thing. It is required for safety critical areas like avionics. I can guarantee that your JS code is not making into any safety critical environment!
>hasn't reduced the number of paths to test But it has: it's now tested, and you don't need to write tests for it next time you want to use it. >100% test coverage is rarely a good thing Not sure what your argument is here. Sure, it may not be helpful but are you saying that one should strive for less than 100% coverage, because "it's rarely good"?
100% coverage is rarely worth the time, unless it's an engine controller or something else that needs the assurances.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#694Hell, the java programmers I work with seem to never use each others simple functions and instead recreate the will every single time.
As for the issue with such a short piece of code being reused by many, why score on number of lines? If it works and is a useful function is more important to me. I am not familiar with bundling within the usage the article covers but we tend to bundle like functions together and the compiler drops unused ones
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#695Earlier quoted context omitted.
What's not to like? The fact that every one of those dependencies is an attack vector when one of those package's maintainers gets compromised / project hijacked / bought off by some black hat operator. It's easier to keep an eye on a small number of trusted parties than 200 random strangers. You thought this SNAFU was bad...
That has nothing to do with how granular packages are. The npm is broken as it allows such things. Look at this spectacular example of providing high security for users: https://www.npmjs.com/package/kik Someone has to do this manually?! If the package is not popular, no one cares? What happens if I send them an email and provide the same package with the same API (not trademarked and MIT licensed) but break it a bit…
when those packages are not under your control, it has everything to do with how granular they are and by extension how many you depend on and thus have to trust/verify.
when was the last time you rechecked the entire source of a package you depend on after updating it?
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#696Earlier quoted context omitted.
Perhaps another reason for this is that Javascript is inherently unsafe. By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors. Other languages handle this with compilers, may be strongly typed, and/or have features that don't allow nulls. Javascript doesn't exactly have that luxury. So maybe it makes sense in J…
> By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors. In practice, many, if not most, of these one-line modules don't even work correctly, and it is difficult to get people to care to collaborate on fixing them instead of just replacing them with a new one-line module that works slightly better as the concept…
Case in point: the left-pad package has quadratic complexity.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#697The problem with shared hyper-modularisation is that it assumes the name of a function is unambiguous with only one valid implementation. If that were true, it should be encouraged but given it isn't, the practice will crushed by ambiguity and unintended consequences.
My app might well have an is-positive-integer function but it will include a range of context dependent choices about e.g. floating point, infinities, zero, null, "9", "9 ", "09", boxed numbers, string representations exceeding js max int, etc. etc.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#698Earlier quoted context omitted.
>hasn't reduced the number of paths to test But it has: it's now tested, and you don't need to write tests for it next time you want to use it. >100% test coverage is rarely a good thing Not sure what your argument is here. Sure, it may not be helpful but are you saying that one should strive for less than 100% coverage, because "it's rarely good"?
100% coverage is rarely worth the time, unless it's an engine controller or something else that needs the assurances.
If tjmehta likes to cover his open source code 100%, under whatever metric, by God let's encourage him in that and not start a discussion about the economic sense of it!
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#699I can't take this author seriously at all, one of his most egregious cases is the is-positive-integer library which until today had around 30 downloads in the last month.... No one was really using this and furthermore of course you can find bad/iffy code on NPM for the same reason you can find bad/iffy code on github. ANYONE can publish code. I could write a similar module for any other library, publish it to their repo, then scream LOOK! python is stupid and python devs are stupid.
I firmly believe that building on what has already been done allows for much safer code written at a quicker pace. Why should we constantly repeat ourselves? Also by using npm modules we can abstract logic and prevent someone on the team from going in and modifying it for their own use. It is a documented/constant function that we can use knowing exactly what it does. Is it a better world where everyone just copies code out other's repos and then has to include the licence/docs/tests along with it? It's much easier to just pull in the repo which contains everything and make it trivial to see where a function came from.
People are blowing this whole thing way out of proportion just because it makes a good headline "11 lines of code broke node"... You can all try to shame people who build on what's come before and chant "Not invented here" but I'll opt to build on what is proven to work instead of rewriting everything. At the end of the day that's what ships products.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#700Earlier quoted context omitted.
Am I right that len(" null") here is 5, so it's working incorreclly?
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.