Live data from Hacker News

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

haneycodes.net

601–610 of 887 posts

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

#601
post #591
post #75

Earlier quoted context omitted.

> every line of code I write myself is a commitment That's true. However: Every dependency you add to your project is also a commitment. When you add a dependency, you're committing to deal with the fallout if the library you're pulling in gets stale, or gets taken over by an incompetent dev, or conflicts with something else you're using, or just plain disappears. If you add a dependency for just a few lines of code,…

Maintaining a dependency on a library should be much less effort than maintaining 17 lines of code. If it isn't that's a deficiency in your dependency infrastructure.

If you have 100 dependencies, then that's a 100 projects you need to follow and understand the updates for. The minute your dependencies bring in their own dependencies then you start having troubles keep up or even keeping track of the updates. The 17 lines of code you pull in is in most cases a one time deal, having it in a third party library means that you need to keep track of that library for ever.

Honestly, and this is maybe just me being biased against JavaScript, then this is what happens when you pick a language fully knowing it's limited in all sort of silly ways and attempt to use it as a general purpose language. It's not that you can't, but if you need say typing that can tell you if something is an array, then maybe picking JavaScript to begin with wasn't the brightest idea.

There's a ton of libraries and hacks out there, all attempting to fix the fact that JavaScript isn't really good general purpose language. ES6 is fixing a lot of these thing, but it's a little late in the game.

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

#602
post #596

Earlier quoted context omitted.

I feel exactly the same. There is something about JavaScript that makes people go a little crazy both for and against it. I've never seen so many programmers advocate copy/pasting code before... But regardless of how many insults get thrown around, or how many people seem to think JS is useless or that it's a horrible language, its probably my favorite (and I've done professional work in non-trivial applications from…

> But regardless of how many insults get thrown around, or how many people seem to think JS is useless or that it's a horrible language, its probably my favorite (and I've done professional work in non-trivial applications from C and C++, to Java and go, to python, Ruby, and PHP to BusinessBasic and even some lisp). I see one common thread between all those languages you list: none of them has a decent type system. I…

I've actually played with OCaml a bit, and Haskell a bit less. The problem is that I don't know what "problems to solve" with them, and there is no way I'm going to use something like that at work, so I kind of run out of steam before I really get into it.

I might shoot for Scala next time. We don't use Java anywhere at my current job, but I might play around with it in a personal project for a while.

I really like the functional style, and I can see how strong typing works REALLY well with it, but I've already found that it's pretty hard to bring other devs up to speed on it. And that really limits where I use it.

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

#603
post #432

If I engage in as much hyperbole as the author, where does "write it yourself" stop? If I'm working on a team of two, should we each write our own left-pad? How about a team of three? Four? Five? Fifty? At a certain point, it makes sense for that to be written once for the project. We spent 30 years in software engineering trying to figure out how to get code re-use, and now that's it common and widespread, we want t…

I think about this every time I write a UTF-8 decoder. It's a task which is simple enough that I can bang it out from scratch about as fast as I can find a library that does it, so I can't really stomach adding a full-blown dependency to deal with it - but it's also just complex enough that I have to think about it, write some tests to make sure I didn't forget something, and wonder whether this implementation is any…

I have 'tools' repository on my local gitolite server just for that. Saved a lot of time already.

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

#604

Earlier quoted context omitted.

There are definitely trade-offs involved when making decisions to inline vs import. Strictly speaking, you're definitely right. Each dependency is an additional point of failure, but so is each additional line of code you inline . The benefits of these small modules is that they're very thoroughly tested by the entire community. I'd say for most cases, they will be much more robust than any solution an individual dev…

> There are definitely trade-offs involved when making decisions to inline vs import. If someone can't make the right trade-off regarding "should I import a module called "isArray" or "is-positive-integer", then they should not be programming...

I think a lot of the confusion here is that in most languages "isArray" or "is-positive-integer" are simple functions of simply build into the language.

Dynamic typing and diversity of devices and virtual machines mean the ability to simple tell if something is an Array could be multiple lines of code that could take a considerable amount of time to test.

Delegating this to the community is arguably the only sane choice, however strange that may be to someone come from another environment.

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

#605

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…

Sorry for the nitpick, but "hyperabstraction"?

left-pad isn't even slightly abstract.

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

#606
post #570
post #420

Earlier quoted context omitted.

The equivalent in C would then be replacing #include and "-lm" with #include #include #include #include … and "-lsin -lcos -ltan -lsinh …" Which is nuts no matter what language you are coding in.

So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?

Having a full set of math functions isn't kitchen sink, it's the right level of granularity for a module. If I want math functions I really want them to all be written by the same author and kept in lock-step as a unit.

Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?

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

#607
post #28

Everything in this article is categorically wrong and antithetical to every principle of good programming ever articulated. The only problem here, as others have already noted, is that NPM allows people to delete published packages. Small modules are not evidence of a problem, and they certainly aren't evidence of an inability to implement these things on the part of the people depending on them. Why would I implemen…

> Why would I implement left-pad myself when there is already a well-tested implementation that I can install? You call 4 basic assertions "well-tested"? https://github.com/azer/left-pad/blob/master/test.js

You are assuming well tested is referring to unit tests, rather than the wealth of developers depending on and running it in their projects daily.

Don't forget how many different targets there are for JavaScript, even if you had a test environment with limitless budget, it wouldn't compare to having a popular package on NPM.

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

#608
post #432

If I engage in as much hyperbole as the author, where does "write it yourself" stop? If I'm working on a team of two, should we each write our own left-pad? How about a team of three? Four? Five? Fifty? At a certain point, it makes sense for that to be written once for the project. We spent 30 years in software engineering trying to figure out how to get code re-use, and now that's it common and widespread, we want t…

I pretty much came to the comments to post something similar. I'm sure there was a long comment thread here on HN discussing the perils of NIH this week. This seems like the end point of the alternative.

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

#609
post #566

Earlier quoted context omitted.

Do you seriously think that "word starts with a capital letter" is an easy function to write? I feel like you haven't spent enough time with Unicode.

return string[0] === string[0].toUpperCase(); You're welcome!

string[0] isn't necessarily one code point.

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

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

I'm not at all clear why this blog post is touted as evidence that the tiny modules approach is correct. I think it might be all the people after it congratulating him.

"It's all about containing complexity." - this completely ignores the complexity of maintaining dependencies. The more dependencies I have the more complicated my project is to maintain.

Dependencies are pieces of software managed by separate entities. They have bugs and need updates. It's hard to keep up to date.

When I update a piece of software I read the CHANGELOG, how am I expected to read the CHANGELOG for 1,000 packages?

Depending on a bigger package (handled by the same entities, who write one changelog, in the same form) is more straight forward.

I'm not saying this is wrong - but there's a balance here, and you must not ignore the complexity of increasing your number of dependencies. It does make things harder.

Post reply on HN