Comment by adambard
11 years ago
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 mostly so I may be more used to having a huge standard library to lean on than is typical.
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!
Looking at the changelog, there have been more than 70 versions of Lodash in less than four years. The first was in April 2012. [1]
does not exist. It was added as part of version 3.0.0 January 26, last year and renamed to _.padstart in Version 4.0 on January 12, this year.
So in less than a year "padleft" came and went away because all strings don't start on the left and someone decided that "left" means "start" except that the reason that it doesn't is the reason that it was changed. Even worse, the 4.0 documentation does not document that _.padstart renamed _.padleft. It's hard to grok what cannot be grepped.
Why blame someone for depending on padleft in a world where libraries swap out abstractions in less than a year? Breaking changes are bad for other people. Semantic versioning doesn't change that.
[1]: https://github.com/lodash/lodash/wiki/Changelog
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 alias for reduceRight.
All this in a language that doesn't make it easy to do automated refactoring means that you basically break everything upgrading to Lodash 4.0 so you can't refactor parts to the newer style piece by piece.
2 replies →
Damn, yeah, that's a totally valid reason. I was under the impression that lodash was more stable than to have that kind of stuff happen.
What if lodash itself was unpublished? I'm having a hard time drawing a line here, obviously a 10 line function is too far on the bad side of lazy, but I can't tell what is an acceptable dependency.
I think it would be annoying but recoverable. It's used so widely that somebody would republish it, at worst under a different name.
Edit: But there would sure be a period of chaos.
2 replies →
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
This seems like the right answer to me. It's not that we forgot how to program, it's that Javascript forgot a stdlib. You could easily write your own left-pad function in any language, but a stdlib (or this module) gives you a standard way to reference it, so you don't have to look up what you named it or which order the args go in.
Agreed the JavaScript standard library is poor and instead of addressing it they've mostly just added syntax changes to ECMAScript 6 and 7. It's incredibly disappointing.
For instance I added a utility to my own library (msngr.js) so I could make HTTP calls that work in node and the browser because even the fetch API isn't universal for some insane reason.
I think in some ways a good standard library is a measure of programming language maturity. I remember when C++ had a lot of these problems back before you had the STL etc. In the early 90's it was a dog's breakfast.
We have a large internal C++ app at my work of that vintage (~1992) it uses its own proprietary super library (called tools.h++) which is just different enough from how the C++ standard evolved that its not a simple task to migrate our codebase. So now every time we change hardware platforms (has happened a few times in last 30 years) we have to source a new version of this tools++ library as well.
I find it amusing Javascript hasn't learnt from this.