I suspect this might be seen as trolling, but why isn't there a standard lib of stuff like this? surely it can't be beyond the wit of programming kind to have a standard lib, or even layers of standard lib for Node? What is the argument for not having a standard lib, apart from download speed?
I'm not taking an absolute position either way -- the devil is in the details -- but here's my steelman for the opposing view: When you put something in the standard library, it's harder to take it out, meaning that you're committing development resources to support the implementation. Furthermore things change: protocols and formats rise and fall in popularity and programming style evolves as the language changes (e…
Micro-libraries should never be used
131–140 of 179 posts
Re: Micro-libraries should never be used
#132Re: Micro-libraries should never be used
#133Applications should never have trivial, tiny libraries as moving-target external dependencies.
If you must use a small library, bring it into the program.
Re: Micro-libraries should never be used
#134Micro-libraries are really good actually, they're highly modular, self-contained code, often making it really easy to understand what's going on. Another advantage is that because they're so minimal and self-contained, they're often "completed", because they achieved what they set out to do. So there's no need to continually patch it for security updates, or at least you need to do it less often, and it's less likely…
If you understand what is going on, paste it into your tree.
Re: Micro-libraries should never be used
#135Earlier quoted context omitted.
Micro-libraries anywhere else are everything you said: building blocks that come after a little study of the language and its stdlib and will speed up development of non-trivial programs. In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and de-facto standards in the programming community like the oldest…
The whole web stack must die and be replaced. JS, CSS, HTML, HTTP are huge cost center for global economy.
How people use them is another matter. But don't blame that on the technology.
Re: Micro-libraries should never be used
#136Earlier quoted context omitted.
This has nothing in common with the UNIX approach. Awk, grep, sort, less and the like are perhaps small, but not that small and not that trivial.
Unix has yes, tr, cut, true, false, uniq, nl, id, fold, sort, sleep, head, tail, touch, wc, date, cal, echo, cat... These are tiny programs. I mean, sort has put on some weight over the years, sure. But if it were packaged up for npm people would call it a micro-library and tell you to just copy it into your own code.
Re: Micro-libraries should never be used
#137Earlier quoted context omitted.
They were developed by different authors...
Who often worked together, sometimes, gasp in the same building! Definitely not random people on the internet not met or even emailed.
I don't think you can necessarily trust Bob's code without looking at what he wrote, just because you see him in person.
And coreutils has 200 contributors, many random people and strangers, from all over the world now.
Re: Micro-libraries should never be used
#138Earlier quoted context omitted.
Why isn't there some kind of 'compiler/linker/stripper' that would collect the functions actually used and compile them into an application specific library? Yes I know that dynamic dispatch makes that difficult but the programmer does surely know which functions he wants to call. I sometimes hanker for a return to Fortran IV where every routine was separately compiled and the linker only put into the object code tho…
Zig handles this with lazy compilation: code is parsed, but not even type checked, until the compiler reaches it. This can lead to the occasional rude surprise when finally reaching code I've been working on for awhile, but haven't yet connected to the rest of the project. But it means there's no need for tree shaking, because nothing gets in until it gets used. One of my favorite things about the language.
Re: Micro-libraries should never be used
#139Earlier quoted context omitted.
Unix has yes, tr, cut, true, false, uniq, nl, id, fold, sort, sleep, head, tail, touch, wc, date, cal, echo, cat... These are tiny programs. I mean, sort has put on some weight over the years, sure. But if it were packaged up for npm people would call it a micro-library and tell you to just copy it into your own code.
Yet, they are still a lot bigger than most micro-libraries. And more complex. And most of them tend to be parts of the same package (coreutils). So no, they have nothing in common with microlibraries. Not in concept, not in how they are used, shipped or maintained.
Some of them are incredibly trivial. I made this exact same comment months ago, but the yes command is basically a one line bash function [1]:
function yes { while true; do echo "${1:-y}"; done }
[1] https://news.ycombinator.com/item?id=38799808Re: Micro-libraries should never be used
#140Earlier quoted context omitted.
Micro-libraries anywhere else are everything you said: building blocks that come after a little study of the language and its stdlib and will speed up development of non-trivial programs. In JS and NPM they are a plague, because they promise to be a substitute for competence in basic programming theory, competence in JS, gaps and bad APIs inside JS, and de-facto standards in the programming community like the oldest…
The whole web stack must die and be replaced. JS, CSS, HTML, HTTP are huge cost center for global economy.