Live data from Hacker News

Micro-libraries should never be used

bvisness.me

131–140 of 179 posts

Re: Micro-libraries should never be used

#131
post #9

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…

But people don’t have to spend social capital to get it used at the next place they work.

Re: Micro-libraries should never be used

#134
post #15

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

Right! So if it is indeed so easy to understand what is going on, why would you need to make it an external dependency that can update itself behind your back?

If you understand what is going on, paste it into your tree.

Re: Micro-libraries should never be used

#135
post #50

Earlier 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.

HTTP, HTML and to some extent CSS are solid technologies that are very well designed and has been standing thr test of time.

How people use them is another matter. But don't blame that on the technology.

Re: Micro-libraries should never be used

#136
post #65

Earlier 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.

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.

Re: Micro-libraries should never be used

#137
post #66

Earlier 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.

Then only use the software that Bob wrote in the same building you work at, I don't know what to tell you.

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

#138

Earlier 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.

its such a useful technique. tiny binaries ftw!!

Re: Micro-libraries should never be used

#139
post #136

Earlier 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.

> Yet, they are still a lot bigger than most micro-libraries. And more complex.

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=38799808

Re: Micro-libraries should never be used

#140
post #50

Earlier 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.

I don't see why you feel the need to drag HTTP, HTML and CSS through the mud
Post reply on HN