Live data from Hacker News

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

haneycodes.net

371–380 of 887 posts

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

#371
I think this is the fundamental thing people don't understand about NPM and JavaScript, and the web in general:

Nothing is included. And that's a feature. The web is not trying to be the kitchen sink. That's iOS. They provide high level APIs for everything. And as a result, the platform is architecturally only as vibrant as Apple can make it.

Now maybe you're happy with Apple, maybe you love the iOS APIs. But if you don't, you're stuck. There's not a rich bed of alternative view layers that you can draw from to build your own vision of how software should work.

Node and the web browser strive to be lowest common denominators. They provide just the very basics: a document format, a very simple programming language, and an http server. The rest is up to you.

That's pretty scary, and so the JavaScript world has dabbled in frameworks. In the end all-inclusive frameworks are antithetical to the spirit I'm talking about, so things trend towards small modules that do one thing pretty well. People go overboard sometimes. I would argue left-pad should just be a copy-pasted snippet rather than module. But that's not a sickness in the community, it's just developers feeling out how far to go.

If you like every application to look the same, and you don't mind being chained to enormous and restrictive standard libraries and frameworks, then you will hate JavaScript. If you like writing software from scratch, forming opinions about all of the different parts of the system, and allowing each application to be built out of different parts, out of the right parts, then you should give JavaScript a closer look.

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

#373

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…

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

A more apt metaphor would be separating a book into many small paragraphs that each serves a single purpose makes the book easier to understand. Regardless, the book metaphor misses a lot of the nuance.

Of course taking the approach to an extreme would be detrimental. However, a vast majority of these small modules that are actually widely used consist of functions that may seem trivial at first sight, but actually contain a lot of corner cases and special considerations that a naive inline implementation could miss.

Sure, there are also plenty of trivial one-line modules on npm that don't fit into a such a description, but those are simply side effects of the unprecedented popularity of the platform and its completely open nature, and shouldn't be used to infer any kind of general trend towards "hypermodularisation" because very few reasonable developers would ever import them into their projects.

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

#374
post #58
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…

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.

Yes, but it's MIT licensed. We also need average_GPL to go with it.

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

#375

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…

Just sugar-coated kool aid I'm hearing. Community benefits? First of all, I'm coding to get paid and this recent madness proved that JS ecosystem is semi-garbage. Back to the original question - do people really can't program that they need packages like left-pad or is-integer which had their own dependencies? Before writing those cool toolchains (which would likely work in a specific machine with a specific setting…

if leftpad were in the node stdlib, would you still be making the same point about knowing computer science and using leftpad?

in python: https://docs.python.org/3.3/library/stdtypes.html#str.ljust

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

#376
post #223

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 that help? Besides they overflow to doubles if they get bigger than 2^31-1 anyway.

The problem with a naive average like this is that if you're averaging a bunch of big numbers there is a very high chance of overflow when you're summing, so even if all the numbers fit in 32 or 53 bits your calculation will be off.

If you're not averaging thousands of large numbers, why are you even using a package instead of nums.reduce((a,b)=>a+b) / nums.length anyway?

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

#377
post #279

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…

Can we ever achieve this? We can't exactly search the code to find out what it does, otherwise you'd basically be reading all the code to discover it's true behavior, which negates the usefulness of modules in the first place... Any search will have to rely on developer-made documentation, and/or meta data. This is great in theory, but documentation is rarely well maintained, and/or someone changes the code but negle…

We could have something similar with full dependent types a la Idris: you could write a proof and search for a function that satisfies it. If such a thing were popular and huge amounts of Idris code were written, you could write only proofs for your program and the Idris system could go download and piece together your program!

That would be very cool, but I'm not sure how much easier it would actually turn out to be. Also to do anything useful you'd probably have to restrict the language to be non-Turing-complete.

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

#378

Counter-argument: A good micro-module removes complexity. It has one simple purpose, is tested, and you can read the code yourself in less than 30 seconds to know what's happening. Take left-pad, for example. Super simple function, 1 minute to write, right? Yes. But check out this PR that fixes an edge case: https://github.com/azer/left-pad/pull/1 The fact of the matter is: every line of code I write myself is a comm…

I'd say you're playing fast and loose with the term "edge case" there. I call that a bugfix, for a feature that does not work.

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

#380

Earlier quoted context omitted.

I'm going to keep writing stuff in JS, and I'm going to keep loving it. Why do you like it? Serious question.

I'm very hesitant to answer this, as i know it will bring on angry comments and people telling me i'm wrong, but i'll give it a shot (this is all literally off the top of my head right now, so if you are going to poke holes in it, cut me some slack) This got a lot bigger than i thought, so strap in! * The lack of "private" anything. This sounds like a bad idea, but I firmly believe it was a major reason for JS's succ…

Thank you for taking the time to write this out. This is probably the best description I have seen of why it is enjoyable to write JavaScript. I myself have been programming professionally for 15 years, writing C, C++, Scheme, Java, Rust, PHP, Python, Ruby, shell script, etc. I actually enjoy C and Rust, have a tremendous respect for Scheme, Clojure, Haskell, Scala, ML, etc., yet I always reach for Node and JavaScript because of the great JIT, instant startup time, great debugging tools, and ease of use of npm.

To add to the part about extensibility, many times I have jumped into a "node debug" session, in my own code or in 3rd party modules installed to node_modules. Many times I have added breakpoints or tweaked 3rd party code right in node_modules, or monkey-patched methods temporarily. This kind of thing is often nearly impossible, very time consuming, or just plain difficult to do in other languages.

Post reply on HN