My advice is that people will use your library if it’s less work to find it, understand it, integrate it, and consume it, when compared to writing their own utility functions. For a utilities library, this is highly unlikely to be the case.
The remarkable thing about left-pad to me is that these conditions somehow became true, which is a huge credit to npm.
Well, seeing as I released this package literally today, I might not be the best person to give advice – maybe no one will use _ either!
That said, here are a few things that I’d look for in a utilities package and that I’m aiming to deliver with _:
How much do I trust the quality of the code? For _, I’m emphasizing the shortness of the code and hoping that reading it will get people to trust the quality (this depends both on them being willing to read it and on them thinking it’s well-written). But this could also be based on the reputation of the author/professional backing, test coverage, etc.
Does the library seem likely to be well maintained? Part of the point of a utility library is to simplify common tasks. But if the library becomes abandoned, it would have the opposite effect. For _, I’m trying to address this by putting thought into the library’s future and being transparent about my thoughts. (See, e.g., the 5,000+ word OP)
Will the library maintain backwards compatibility or break when I need it most? As with the previous bullet, a utility library that breaks my code is having the opposite of the effect I want. This part is still a WIP for _, but I’m trying to come up with the strongest promise of backward compatibility that I can reasonably keep.
Does the library have functions in a “happy medium” of complexity? If they’re too simple, I’d just implement them myself instead of using the library; if they’re too complex, I’d be willing to take on a dedicated dependency for that feature rather than leave it to a utility library. This is fairly subjective; I’ve tried to strike the correct balance with _, but I’ll have to see how many users agree.
“I used an underscore character to name my library. Many people will think it’s named after this other similar library that also uses an underscore for its name, but it’s actually not.” <- This makes no sense at all. I’ve never heard an underscore called a lowbar, and citing the HTML spec comes across as “see I’m technically correct” pedantry.
That’s an entirely fair criticism of my post – so much so that I upvoted.
(The bit about the HTML spec was intended as … well, not quite a joke, but making light of myself for needing to pick an obscure term for the character – I also hadn’t heard a ‘_’ called a “lowbar” before. Clearly that not-quite-a-joke didn’t land).
What I was trying to say is that _ fits so well with Raku’s existing use of $_, @_, and %_ that I decided to go with the name anyway – even though I view the name collision with underscore.js and lodash.js as unfortunate and 100% accept that most people will think that _ named in homage to lowdash.
Yeah, I’m speaking without any specific knowledge of Raku. I just think that if the library does catch on, people will pronounce it as “underscore” whether you want them to or not. =)
Can you say more about why _ strikes you as a bad name? Does the spelled-out version I also used (“lowbar”) strike you the same way?
I dislike this name because it’s difficult to search for and lowbar is a relatively obscure term. If the intent is that every Raku program includes the library, then you could call it Prelude. That’s what other languages such as Haskell call a library of functions that are implicitly included in every program.
But you’ve just pushed the workload somewhere else… now you have to separately monitor for and pull in manually any bug fixes and security patches that get made in the dependency. Vendoring (whether in the traditional sense, or merely by snapshotting some specific state of a remote source) is a valid approach, but no panacea.
I have a utilities library for another language and I’ve found that the grab-bag, misc nature of it has made people reluctant to use it. Any advice?
My advice is that people will use your library if it’s less work to find it, understand it, integrate it, and consume it, when compared to writing their own utility functions. For a utilities library, this is highly unlikely to be the case.
The remarkable thing about left-pad to me is that these conditions somehow became true, which is a huge credit to npm.
Well, seeing as I released this package literally today, I might not be the best person to give advice – maybe no one will use
_either!That said, here are a few things that I’d look for in a utilities package and that I’m aiming to deliver with
_:_, I’m emphasizing the shortness of the code and hoping that reading it will get people to trust the quality (this depends both on them being willing to read it and on them thinking it’s well-written). But this could also be based on the reputation of the author/professional backing, test coverage, etc._, I’m trying to address this by putting thought into the library’s future and being transparent about my thoughts. (See, e.g., the 5,000+ word OP)_, but I’m trying to come up with the strongest promise of backward compatibility that I can reasonably keep._, but I’ll have to see how many users agree.first impression: this is a terrible name, and not just because it’s already in use by gettext
Can you say more about why
_strikes you as a bad name? Does the spelled-out version I also used (“lowbar”) strike you the same way?Names are important things, and I’m curious about your views.
“I used an underscore character to name my library. Many people will think it’s named after this other similar library that also uses an underscore for its name, but it’s actually not.” <- This makes no sense at all. I’ve never heard an underscore called a lowbar, and citing the HTML spec comes across as “see I’m technically correct” pedantry.
That’s an entirely fair criticism of my post – so much so that I upvoted.
(The bit about the HTML spec was intended as … well, not quite a joke, but making light of myself for needing to pick an obscure term for the character – I also hadn’t heard a ‘_’ called a “lowbar” before. Clearly that not-quite-a-joke didn’t land).
What I was trying to say is that
_fits so well with Raku’s existing use of$_,@_, and%_that I decided to go with the name anyway – even though I view the name collision with underscore.js and lodash.js as unfortunate and 100% accept that most people will think that_named in homage to lowdash.Yeah, I’m speaking without any specific knowledge of Raku. I just think that if the library does catch on, people will pronounce it as “underscore” whether you want them to or not. =)
The thing that the underscore character reminds me of is when you’re writing a function that accepts more arguments than it needs, and you’re using an underscore to communicate that it’s unused: https://softwareengineering.stackexchange.com/questions/139582/which-style-to-use-for-unused-return-parameters-in-a-python-function-call (the link mentions Python and I’ve never used Python, but it’s common in nearly every language I do use)
I dislike this name because it’s difficult to search for and lowbar is a relatively obscure term. If the intent is that every Raku program includes the library, then you could call it Prelude. That’s what other languages such as Haskell call a library of functions that are implicitly included in every program.
On the other hand, lodash uses _ and is pretty well known in the JS land.
there’s also underscore.js https://underscorejs.org/
I sometimes use such libraries if I have no other choice, but it would be much better to split it into smaller, more focused libraries probably?
But then we’re back to the left-pad dilemma!
Not if you don’t rely on a mutable third party store for your production builds :)
But you’ve just pushed the workload somewhere else… now you have to separately monitor for and pull in manually any bug fixes and security patches that get made in the dependency. Vendoring (whether in the traditional sense, or merely by snapshotting some specific state of a remote source) is a valid approach, but no panacea.
Part 2 is a followup to Following the Unix philosophy without getting left-pad, which was discussed previously on lobste.rs (23 comments)