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

461–470 of 887 posts

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

#461

Post by lucaspiller »

PascalsMugger wrote: post #297
Macha wrote: post #163

Earlier quoted context omitted.

Yes, I found a number of the stylistic changes made in Lodash 4.0 made it more complicated to upgrade than needed. Dropping the this param with no period of deprecation? Pretty breaking change to make with no warning. Renaming first/rest to head/tail? Was it really worth it? Particularly when they go the opposite direction of replacing traditional functional names with more explanatory names by removing the foldr ali…

The reason for the name change and the Parma change is that String.prototype.padStart is being added in the next ECMAScript release, and lodash was changed to be compatible with the newly built-in version (so it's a polyfill).

An easy solution would be to have both padStart and padLeft, with a note in tbe changelog saying padLeft is deprecated and will be removed in a future version.

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

#462

Post by imron »

drauh wrote: post #420
bluejekyll wrote: post #407

Earlier 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…

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.

The difference with C is that with a good linker, functions you don't call are removed from the resulting binary (or are maybe not even in the binary if you are dynamically linking to the c runtime).

With javascript however, if you import a hypothetical "math.js" instead of just "sin.js", "cos.js" or "tan.js", then you'll need to download and evaluate a whole bunch of javascript that you might not need.

I'm not defending javascript, because I dislike it and avoid it where possible, but I can understand some of the reasons why short, specific modules came about.

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

#463

Post by grumblestumble »

Couple of things:

* If you're in favor of the micro-module approach, you shouldn't be relying directly on NPM, and should have something like Sinopia in place. After all, external code isn't the only thing you're vendoring, right?

* Micro modules are fine - but your application code should depend on a privately published utils module whose entry point is a prebuilt distribution of all your external micro-modules exposed through a facade. Your utils module deps are all installed as dev dependencies to avoid the Fractal Nightmare.

* Yay, now you have your own 'standard library' which still manages to leverage the NPM philosophy of distributed code. And if some twit decides to throw a tantrum, it will only impact future builds of your custom std lib - and you'll know about it at build time.

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

#464

Post by forgotpwtomain »

lewisl9029 wrote: post #206
runin2k1 wrote: 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…

> This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic:

https://github.com/sindresorhus/ama/issues/10#issuecomment-1....

If anything looking at sindresorhus's activity feed: (https://github.com/sindresorhus) perfectly supports the author's point. Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though..

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

#465

Post by magicalist »

runin2k1 wrote: post #95
magicalist wrote: post #33

Earlier quoted context omitted.

it's a module with exactly one dependent module -- by the same author. Daily WTF material but who cares beyond that?

Formerly 9 dependent modules... but who cares maybe it was a homework assignment or a joke. I don't use NPM so maybe it doesn't really matter aside from the level of abstraction being implemented being relatively ridiculous. However, if my build system had to go out and grab build files for every X number of basic functions I need to use, grab Y number of dependencies for those functions, run X * Y number of tests fo…

> I don't use NPM so maybe it doesn't really matter aside from the level of abstraction being implemented being relatively ridiculous.

Except, again, it's no more ridiculous than pick a random bit of code from anywhere and isn't any more emblematic than that random bit because, again, it's not used anywhere.

> [Quick Edit] Basically I'm saying "Get off my lawn ya kids!"

tl;dr: going for buzzfeed headlines but for comments, got it. Good job, I guess?

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

#466

Post by imron »

coldtea wrote: post #354
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…

> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

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 to trip up even experienced developers if they miss one or more of those edge cases.

Having pre-written modules that account for all edge cases that have been battle-tested by hundreds, thousands, or even millions of users does have merit.

The main problem here is with the Javascript language, which makes code evolve to things like 'is-positive-integer'.

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

#467

Post by marssaxman »

rycfan wrote: 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 different from the last one I wrote.

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

#468

Post by lukeschlather »

baudehlo wrote: post #35
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)

JavaScript much to my dismay has no sprintf. It's one of the most annoying omissions ever for server side work.

The biggest thing I've run into is that there's no built-in `mkdir -p`. There is, of course, a module that is literally just mkdirp.

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

#469

Post by lucaspiller »

emidln wrote: post #19
mastazi wrote: post #3

Usually, dependency hell doesn't bite you, until it does. Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-) I recently had to rebuild a large RoR app from circa 2011 and it took me longer to solve dependencies issues than to familiarise myself with the code base. Excessive dependencies are a huge anti-pattern and, in our respective developers communities, we should try to circul…

> Try to rebuild that thousand-dependencies app in three years from now and you'll see ;-) This is your fault for expecting free resources to remain free forever. If you care about build reproduction, dedicate resources to maintain a mirror for your dependencies. These are trivial to setup for any module system worth mentioning (and trivial to write if your module system is so new or esoteric that one wasn't already…

I've been in the same situation as OP many times (although in most cases I've been brought in fix someone else's code).

In the Ruby ecosystem, library authors didn't really start caring about semantic versioning and backwards compatability until a few years ago. Even finding a changelog circa 2011 was a godsend.

I think this was mainly caused by the language itself not caring about those either. 10 years ago upgrading between patch releases of Ruby (MRI) was likely to break something.

At least this is one thing JavaScript seems to do better.

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

#470

Post by scrollaway »

meric wrote: post #236

NPM modules can be used on browsers. On browsers, space is a premium. Why would you want to install a 500kb dependency that has only one function you need, when you can install a 10kb dependency that has it? Would you want each of your five 20kb dependencies to re-implement the same 5kb function, increasing the code you must send to the client by 20%, or would it be more optimal for each of those dependency to use th…

FYI, you can reply to my comments if you click on their timestamp, in case the reply box isn't showing up

> So if you're going to troll a solid argument by nitpicking, do it properly and get the details right.

First of all, I don't appreciate you calling me a troll. Someone who mentions "5kb functions" clearly has no idea of what 5kb represents, period.

And second, this is not a solid argument at all. There is logic behind it, which is why we usually have high quality stdlibs in popular languages. Javascript lacks that. So instead, javascript gets this absolute mess of an ecosystem, where things like this can happen.

Several people have brought up various issues with the way it's done now. Dependency hell, for one. Lack of discoverability, which in turn leads to duplicate libraries, which in turn leads to a system where you have 1000 dependencies, but despite your "modular" idealism you still have hundreds of duplicate dependencies. Not to mention all the duplicates of different versions of the same dependency.

This "saving lines of code" math is completely broken exactly because this stuff is not in the stdlib. The various issues with the JS ecosystem mean that the actual results are nowhere close to ideal, and have a net negative impact.

I also love when people mention how much "one time cost" is saved and back it up with similar math, completely forgetting the amount of continuous time wasted downloading and installing these dependencies every time.

Post reply on HN