> Even if correct, is it the most optimal solution possible?
"most optimal"?
NPM and Left-Pad: Have We Forgotten How to Program?
491–500 of 887 posts
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#492Earlier 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?
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.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#493So, apparently some guys managed to build a system where it is very easy to re-use small parts of other people's code and now the author is complaining that "too much code re-use is happening" ? I'm fairly old, so I remember the complaints a decade or two ago that people had where "We can compose hardware from IC's and you don't have to know what's going on inside and it's all standard and just works! Why can we not…
minor nitpick: it's not 28k lines, it is 28k FILES
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#494Earlier 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…
> 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 f…
I think the gist of this whole discussion ( at least the OMG WHY?!?! ) part, can be easily explained by an excerpt from your example comment that sums up in a nutshell the all too pervasive mindset I've seen over the years:
"...LOC is pretty much irrelevant. It doesn't matter if the module is one line or hundreds. It's all about containing complexity. Think of node modules as lego blocks. You don't necessarily care about the details of how it's made. All you need to know is how to use the lego blocks to build your lego castle. By making small focused modules you can easily build large complex systems without having to know every single detail of how everything works..."
By LOC he's referencing 'ye ole Lines of Code paradigm, and trying to make the point that in the end it just doesn't measure up to the prime directive of "containing complexity".
... and that's where I beg to differ.
What I think is being completely overlooked here is the net cost of abstracting away all that complexity... It's performance.
Every extra line of code, extraneous function call, unnecessary abstraction ( I'm looking at you promise ), every lazy inclusion of an entire library for the use of a shortcut to document.getElementById -- these all add unnecessary costs from the network down to the cpu.
And who pays these costs?
The end users of your slow, memory hogging, less-than-ideal set of instructions to the cpu that you call an application... but hey, it's easier for you, so there's that.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#495Earlier quoted context omitted.
Well if I was interviewing the guy, my second or third question would be "tell me about these packages you published on NPM" It's going to be damn hard to make an average function sound impressive.
I think you're seriously overestimating quality of the average programmer candidate. Someone who understands what NPM is, has written and published working code (even stupid code) is miles ahead of the curve already. Most companies in the world, especially non-software companies, don't go for 5% hacker gurus. Attracting someone vaguely competent is already a blessing.
No, I don't think I am. I've conducted many dev interviews. Gurus can often be prima donnas, difficult to work with in a team, btw.
Interviewed enough "C++, 3 years" people who couldn't even describe a class, or give the most basic description of OO, to have no illusions of some of the standards out there. Similar for other languages. Similar for how much having a degree is worth. I used to be surprised such people tried it on, as there was no way they'd walk out of the hour looking anything but stupid, but it happened often enough to stop surprising. Of course I've also experienced code produced by such types, and worked with a couple.
If you're going to publish something then make the world a better place not pollute it with pointless stuff.
Spending more time publishing this package than most basically competent developers would spend writing the four lines is not going to mark you as "miles ahead of the curve" in my eyes. If you're an 18yo fresh out of school without degree, seeking trainee role, I'd look on it favourably.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#496The insanity is that JavaScript doesn't have a standard string library. More a case of forgetting how to design a programming language than how to program.
Contrast with the Scheme Request for Implementation (SRFI) process, see " rel="nofollow">http://srfi.schemers.org/>.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#497Functions are too small to make into a package and dependency. Pure functions don’t have cohesion; they are random snippets of code and nothing more. Who really wants a “cosine” dependency? We’d all really like a “trigonometry” dependency instead which encompasses many “tricky” functions that we don’t want to have to write ourselves. This is a pretty weak argument. What is "cohesion" and why do we care that modules h…
I would retort with: Packages are too big to make into a functional dependency.
In the end, in this functions-as-dependencies world, a trig package would be something like:
(name) =>
switch (name) {
case 'sin':
(x) => sin(x);
break;
case 'cos':
(x) => cos(x);
break;
}Re: NPM and Left-Pad: Have We Forgotten How to Program?
#498Earlier quoted context omitted.
That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.
How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?
53 bits that cannot overflow (it only becomes less accurate) is not enough but 64 bits are, even with the risk of overflow?
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#499I completely agree with the author. The loudest people in the Node community have been evangelizing this practice for as long as I can remember. This shouldn't come as a surprise. The argument, "If I didn't write it I don't have to think about it" is ludicrous. I just have to point at the left-pad incident disprove the premise of this argument. The analogy of building things with a bunch of npm lego blocks is laughab…
Just because it's a one-liner doesn't mean that this code is not complicated. If you forgot something in this one-liner, you could have something that's not working in every case.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#500That's what you get when you let JavaScript into the server side.