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

351–360 of 887 posts

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

#351

Post by fieryeagle »

formula1 wrote: post #273
anexprogrammer wrote: post #208

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

Im of the mind most employers are looking for "have you done stuff" "can you do stuff". Veey rarely are they looking for anyone extraordinary, simply a tool that works

I doubt something like 'wrote npm package that averages stuff' would be relevant without fluffing it up to impress the non-tech hiring manager. Still would ring alarm bells with devs though.

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

#352

Post by sago »

superuser2 wrote: post #343
sago wrote: post #336

Earlier quoted context omitted.

Which languages do you trust to use Knuth's algorithm (or something similarly comprehensive and exhaustive) without checking? Not going to check many, but a quick look, since I've got them handy: Python fails Spivak's criteria, as does .NET.

I don't care. I expect it to work for the simple case, and I expect not to spend time on it unless there is a good reason (like I have very large numbers and must be careful not to overflow).

You responded to a point I made in response to Spivak. If you don't care about his argument, then it might be worth responding elsewhere.

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

#353

Post by apalmer »

smegel wrote: post #330

> What concerns me here is that so many packages took on a dependency for a simple left padding string function, rather than taking 2 minutes to write such a basic function themselves. Wait -- code reuse is bad now??

YES... it is... its a trade off... code reuse has a upside and a downside...

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

#354

Post by coldtea »

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…

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

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

#355

Post by bbcbasic »

EvanPlaice wrote: post #326
bbcbasic wrote: post #298

Earlier quoted context omitted.

Also it is a lot easier to get it wrong in JS. Is it null? Is it undefined? Is it bird? Is it a plane? No it's a string!(but sometimes a number). Good programming languages make it easy to write is negative e.g. isNegative = (<0) where implicitly by the 0 and < it will take a Num and return a bool and this is type checked at compile time.

Use the null object pattern. If you're checking a value to see if it's set by testing for null/undefined, you're doing it wrong. This is good advice for any language, not just JS. Besides, using null as the default for an undefined value is a mistake. Null should indicate a non-value not the absence of a value. Maybe one day the static OOP languages will die so devs have a chance to learn the difference.

My point is more that the compiler* can't detect these mistakes but in other languages you can. E.g. in Haskell you only allow Null on types when you want it (you do this by using the Maybe type). Objects where you probe for values that could be undefined or could be defined but null doesn't exist as a concept but if you badly wanted it you could use a dictionary. In Haskell if you use Maybe and you process a Maybe object you have to deal with the null and not null case otherwise you get a compiler error.

All these checks seem annoying but we've all seen the bar chart of when you discover the bug vs. the cost of that bug. The compiler finding the bug is cheap. Haskell is a cheap language to program in, compared to JS!

* I forgot there is no compiler in JS but let's say the linter for argument sake.

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

#356

Post by coldtea »

lewisl9029 wrote: post #227
wodencafe wrote: post #213

Earlier quoted context omitted.

But this doesn't address the author's point that each module, each dependency is an additional point of failure.

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

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

#357

Post by jmduke »

lintiwen wrote: post #251

I see two kinds of programmers here. Good programmers understand the risks of making your system depend on something you don't have control really well; They know how keeping system complexity low is like an good investment which makes your life later easier (low maintaining costs). Bad programmers stacks up technical debts such as including unnecessary dependencies until the system no longer works.

Technical debt doesn't stop being technical debt just because it's your code.

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

#358

Post by forrestthewoods »

adrusi wrote: post #306
yoodenvranx wrote: post #167

Earlier quoted context omitted.

The problem is not that we forgot how to program, the problem is that we never actually learned how to create a good programming language which avoids these problems. Just look at the whole build system and module hell of C and C++... I totally like the language C++ but I hate the tooling around it with a passion. As long as you only need stuff from stdlib then you are fine, but as soon as you want to create some cus…

It sounds like your problem with C/C++ tooling is that it's hard to support Windows. The reason for that is simply that microsoft bundles its own proprietary C++ toolchain with the platform-specific tools that Windows developers need. Windows developers don't want to install a second posix-like toolchain, and os x/bsd/linux developers don't want to install a Windows-like toolchain because in both cases the new toolch…

Supporting multiple platforms is simple. Assume the user has an existing build pipeline and you need to integrate into it. That means doing one of:

1) provide a single, amalgamated .h/.cpp pair 2) provide per-platform, per-config precompiled static and/or dynamic libs 3) provide all dependencies in the form of 1 or 2

Voila! Your goal should be to provide something that can be trivially added to an existing pipeline.

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

#359

Post by statictype »

memracom wrote: post #287
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…

They do NOT encourage code re-use because the effort required to understand your need, refrain from writing code, and hunt down a module in npm, far outweighs the effort to just write the code and stick it in your in-house utils library.

Well, it does encourage code re-use, but the issue is that the benefits of code re-use here are far outweighed by the downsides of just writing it yourself.

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

#360

Post by sago »

superuser2 wrote: post #347
sago wrote: post #301

Earlier quoted context omitted.

Okay, but how long would you think it sensible to look for, test and assess a package for being 'well-maintained' before you'd consider it a better use of your time to average a list of numbers? If you had to, say, add a list of numbers together, without averaging them, would your first thought be to go searching for a package, given that you know some languages have a 'sum' function? Some languages have an 'add' fun…

>would your first thought be to go searching for a package No, because if this isn't in the standard library (or a very simple one-liner from standard library functions like "fold +") then I don't want to be working in this language. If I have to work in this language, and I'm allowed to bring in packages, I'd go look for the community's attempt at fixing the standard library, or at least a "math" package, particular…

[Edit: Parent comment has been rewritten, see second response, below].

That you think averaging a list of numbers qualifies as a 'feature' you might add to a codebase is rather the surprising thing about your response. I'm aware I'm coming over rather arsey, and that isn't intended, I'm just surprised to find someone actually defend the attitude, generally, that says a trivial calculation should be either a) provided, or you're not going to use the language, or b) put in a package to mean you don't have to spend 'the time' writing it, while at the same time saying you don't care what is in those implementations.

I mean, it doesn't matter to me, obviously. You can choose to have whatever criteria for taking a job you like, and I can have whatever criteria I like for my hires. I'm just surprised. Sorry If I've come over argumentative or grandstanding.

Post reply on HN