Live data from Hacker News

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

haneycodes.net

81–90 of 887 posts

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

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

You should then go dive into the passAll function: https://github.com/tjmehta/101/blob/master/pass-all.js It’s written in such a way that every time you call... passAll(f1, f2, ..., fn)(args..) ... there are something like 5 + 2n attribute accesses, 5 + 3n function calls, 3 + n new functions created, as well as some packing and unpacking of arguments, not including the actual application of the functions to the argum…

I'm more disappointed that it doesn't short-circuit the operation at all. It applies all the functions, THEN it determines whether all of them passed. Even worse, it uses `every` (which does short-circuit) to determine that all the functions are, indeed, functions, but apparently the ability to use that function to determine whether every predicate passes was missed.

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

#82

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…

[deleted]

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

#83
There are lots of useful titbits often left out of a languages corelib.

Back in the day we would have built up various pieces of library code, which we would have utilised rather than continually guessing best practices. For example, the isArray method cited may be trivial but is also non obvious. We'd probably have something like that in our library of useful snippets.

Sometimes we may have shared the code on forums and the like and people would copy and paste the code, sometimes into their own libraries. We would locate them by browsing known locations or inefficiently querying search engines

Now we utilise a central resource and simple tools to have a global library of code. Instead of searching far and wide we query a handful of tools that effectively does the copying and pasting for us.

How that can be considered a bad thing is beyond me. It's not a question of knowing how to code, it's a question of using your time effectively.

Granted, there is the problem of so-called modules being removed and dependencies breaking. This can be alleviated by vendoring your modules, a simple task with most dependency management tools.

Personally I think that published modules should persistent indefinitely based on the license the code utilises, although I'm not clear on the actual legalities of the recent npm issue (although if it's due to a trademark complaint, I don't see how it would ever be enforceable for completely unrelated code in any slightly sane country).

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

#84

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…

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)

I think there's two points related to that:

1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart).

2) JS's "standard" library is so small, because it's the intersection of all of the browser implementations of JS dating as far back as you care to support. As pointed out in sibling, a proposal for padLeft is included in ECMA2016. But we'll still need Left-Pad for years after it's adopted.

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

#85

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 agree with the points you've made, but I would also posit that adding a dependency using this mutable package manager is making a commitment to maintain the integrity of that dependency, which is arguably more work than maintaining the handful of lines of code.

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

#86
post #9

Nearly everyone has had it drilled into them the "Don't reinvent the wheel." nonsense for better or worse. I use lodash in almost every javascript project I start, big or small because it makes my life easier. I'd rather use the lodash isArray than roll my own. https://lodash.com/docs#isArray

Do you support IE 8? If not, why not use the one provided by the language, Array.isArray()?

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

#87
post #75

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…

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

OR: you depend on a specific version of the library, that you know that works, and you have none of those problems.

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

#88
We have. I spent some time optimizing [0] a String.repeat function over at Stackoverflow and I was surprised that many developers today don't know what they are doing, including core team members [1]. Specifically,

    function repeatString(str, len) {
      return Array.apply(null, {
        length: len + 1
      }).join(str).slice(0, len)
    }
[0]: http://stackoverflow.com/questions/202605/repeat-string-java...

[1]: http://stackoverflow.com/questions/202605/repeat-string-java...

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

#89
post #72
post #58

Earlier quoted context omitted.

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.

Well a bunch of standard libraries have sum defined, right? JavaScript has suffered from a lack of a standard library for a while. Having a small package like this means that (in theory) everyone is using the same bug free version of summing instead of writing their own. Honestly having JS start building a standard library at this point would be wonderful.

There's already `Array.prototype.reduce()` in most browsers, which will do summing, string concatenation, and any other kind of aggregation:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

If you need something more convenient I highly recommend just adding lodash and getting a whole bag of rock-solid awesome tools.

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

#90
post #5

I think it speaks to just how lacking the baseline Javascript standard library is. The libraries that come with node help, but all of this stuff seems like it should be built-in, or at least available in some sort of prelude-like standard addon library. The lack of either leads to all these (apparently ephemeral) dependencies for really simple functions like these. That said, I work with Java, Clojure and Python most…

So many people use lodash as a drop-in standard addon library that I'm surprised people aren't just using the padding functions that are right in there... Some of the packages that broke yesterday even have lodash included as dependencies already!

Probably they do use that if they need left padding but also have a dependency on another package that thinks 'lodash is too big when all I need is left padding' so we get to this situation
Post reply on HN