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

Post by mangecoeur » Thu, Mar 24, 2016, 11:49 AM UTC

userbinator wrote: post #350

lewisl9029 wrote: post #206

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…

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…

Post by pliny » Thu, Mar 24, 2016, 11:50 AM UTC

xorcist wrote: post #594

imron wrote: post #466

Earlier quoted context omitted.

Not defending javascript because I dislike it immensely, but with javascript being a dynamically typed language, and with the way it handles implicit conversions between types, and with trickiness around NaN, Infinity and null objects, there are sufficient edge cases that writing a correct function to test if some variable contains a positive integer is not as trivial as it is with more sane languages, and is likely…

(That's the whole point of using a dynamic language, what '>' actually does depends on the surrounding code. If you want '>' to type check you should be using a type safe language to begin with.) The issue I have with this is readability. Type '>' and I know exactly what it does, I know what implicit conversions are involved, and how it would react to a null object. Type 'isPositiveInteger' and I need to check. I can…

Post by spion » Thu, Mar 24, 2016, 11:52 AM UTC

nailer wrote: post #585

spion wrote: post #562

Earlier quoted context omitted.

Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)

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.

Post by wtbob » Thu, Mar 24, 2016, 11:52 AM UTC

minitech wrote: post #547

ShellfishMeme wrote: post #516

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…

Post by plugnburn » Thu, Mar 24, 2016, 11:55 AM UTC