Have we all forgotten how to program?

Yep, I agree with that. I had seen the post by Thomas Fuchs making the case for a better standard library. He makes some very good points. I appreciate that it can be a bit frustrating to have to depend on such small modules as left_pad in JavaScript, when coming from a language like Ruby (with a much better standard library), where you have all of that built in.

I also read Brendan Eich’s reaction to the call for a better standard library. It seems that the reason that this isn’t currently an option is that the language isn’t maintained by a single person or pair of people who design well (like the founders of Unix did, or the creators of Perl, Python, and Ruby do). Instead, “You have a bunch of people from different companies. They’d do a terrible job if they were in charge of building a big standard library.” — which I guess is a fair point.

There may be a certain element of naiveté about this next comment, but here goes anyway… If something like left-pad is so small (12 lines was it), and seemingly unlikely to need to change, why would you make it a dependency, rather than just rolling it into the larger piece? Is this just down to the way certain pieces of OSS are inter-licensed?

It feels rather like a carefully crafted spiderweb, you know, the kind that gathers dew and glows in the morning light, only to have it torn to shreds under the hooves of a passing elk…

2 Likes

No, just the node js people.

It’s further reaching than that. The JS ecosystem as a whole(npm) has glorified small modules and these philosophies are making their way to the front-end too.

Correction… Just the JavaScript people but there are less security concerns running JavaScript client side.

Not sure I follow. Do you mean why wouldn’t you make something this simple part of the standard library?

Nice metaphor : )

2 Likes

I was thinking more of a particular product making use of it as a dependency - let’s for argument sake say React is using something like left_pad (could be anything in reality) as a part of its build, wouldn’t you just pull that into the product core and take away the dependency? Given the size of it, and the limited scope of its functionality, it’s not likely to change much I’d have thought, so would seem a low risk route to take. For the impact left_pad had though, maybe it is significant enough consider for the standard library - in truth I’ve no idea what it does, apart from something lots of people relied on.

Pads a string with an specified amount of characters (which defaults to space)

leftpad('foo', 5)
// => "  foo"

“foo” is 3 chrs in length. 5-3 = 2, so it adds two spaces to the start of the string.

leftpad('foo', 5, '-')
// => "--foo"

etc …

Ah gotchya. Yeah, there’s no real reason (I can see) not to do that and I think it’d make sense.

The reason that didn’t happen (as Mark mentions) is due to the fact that the small module philosophy has been glorified and is the current standard way of doing things.

I’m just poking around the GitHub repository at the moment to understand it a little more…

I feel another spoof O’Reilly cover coming on… :wink:

1 Like

There’s not much to it is there?

module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}

If you don’t mind the code being less readable, you can use the String.repeat() method to do it with even less:

function leftpad(str, len, ch) {
	return (ch || " ").repeat(len - (str && str.length)) + String(str);
}

// works with leftpad(), leftpad("text"), leftpad("text", 5), and leftpad("text", 5. "_")

Thi

2 Likes

I’ve not set up a test for this, so am not immediately sure what I’d get, but what does it do if you supply a pad value of less than the string length. Presumably nothing, with no error?

For example

leftpad('foo', 2);

Dunno about Paul’s code, but the original code will do nothing.

1 Like

Ahh, good thought.

That results in no extra padding being added, so the one-liner would have to be made even more complex with a Math.max method.

function leftpad(str, len, ch) {
    return (ch || " ").repeat(Math.max(len - (str && str.length), 0)) + String(str);
}

Complex is not good. Even though we can do it with the above, or with a more spread version of it:

function leftpad(str, len, ch) {
    return (ch || " ").repeat(
        Math.max(len - (str && str.length), 0)
    ) + String(str);
}

Complex is not our friend.

The original is better because even though both achieve the same end result, it’s easier to understand how the original works.

2 Likes

Another one-liner using the ternary operator (if that counts)…

function leftpad(str, len, ch) {
  return len - str.length > 0 ? leftpad((ch || ' ') + str, len, ch) : str;
}

[cough]

I feel like everyone’s focusing on the wrong thing. The kerfuffle that happened had absolutely nothing to do with the size of the dependency. If jQuery or lodash disappeared from NPM, we’d suffer exactly the same problem. What we really need is a guarantee that a dependency won’t disappear.

1 Like

This we now have: http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy

3 Likes

I agree that the size of the dependency isn’t the biggest problem but when micro-packages are glorified the number of dependencies goes through the roof.
Each dependency is an external piece of code that you have to know about.

3 Likes

It’s not just that you have to know about it. It gets worse.

Each and every dependency is another potential point of failure for you and your code.

4 Likes

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.