Micro-libraries should never be used • Hacker News Board

Re: Micro-libraries should never be used

#111

Post by zx8080 » Mon, Aug 19, 2024, 12:34 AM UTC

foul wrote: post #96

ivan_gammel wrote: post #77

Earlier quoted context omitted.

The whole web stack must die and be replaced. JS, CSS, HTML, HTTP are huge cost center for global economy.

The HTTP-centrism is the worst. QUIC is hilarious because they ended up fitting everything and the kitchen sink for any need in the proto, just because 15 years ago firewalls blocked this or that and the reimplementation with websockets of the thing that was blocked runs only in a browser.

> The HTTP-centrism is the worst.

> QUIC is hilarious

It's apples to oranges. QUIC is actually used _with_ HTTP/3.

Consider not mix transport level (QUIC) and application level (HTTP) protocols in the same comparison to oppose them.

Re: Micro-libraries should never be used

#112

Post by buildbot » Mon, Aug 19, 2024, 1:01 AM UTC

conradludgate wrote: post #83

DonHopkins wrote: post #56

Earlier quoted context omitted.

Sometimes importing zombie "undead code" libraries can be beneficial! I just refactored a bunch of python computer vision code that used detectron2 and yolo (both of which indirectly use OpenCV and PyTorch and lots of other stuff), and in the process of cleaning up unused code, I threw out the old imports of the yolo modules that we weren't using any more. The yololess refactored code, which really didn't have any ch…

This is mortifying. This should not be acceptable implicit behaviour for imports to implicitly run code by simply existing

That’s just the way Python works though, an import reads a script line by line defining the functions and executing calls. I think that’s true of any scripting language?

Re: Micro-libraries should never be used

#113

Post by flysand7 » Mon, Aug 19, 2024, 1:18 AM UTC

I was about to jump into the comment section and say something along the lines of "but no one really thinks they're actually good, right?", only to see the top comment arguing they're good.

Re: Micro-libraries should never be used

#114

Post by flysand7 » Mon, Aug 19, 2024, 1:22 AM UTC

ristos wrote: post #57

rrdharan wrote: post #40

Earlier quoted context omitted.

> When's the last time ls, cat, date, tar, etc needed to be updated on your linux system? probably almost never. Bad example: http://www.slackware.com/security/viewer.php?l=slackware-sec... They find stuff like this fairly often in GNU coreutils even to this day.. it’s the main reason there’s a Rust coreutils effort.

It's probably still a good example. Looking up the CVEs for various search terms: coreutils: 17 results linux kernel: 6752 results x11: 184 results qt: 152 results gtk: 68 results docker: 340 results rust: 455 results python: 940 results node: 110 results javascript: 5657 results firefox: 3268 results chrome: 3763 results safari: 1465 results webkit: 1346 results The large monolithic codebases have a lot more CVEs. I…

The large ~~monolithic~~ codebases have a lot more CVEs

Who would've guessed. Also the older ones also got more CVE's than newer ones, even if they aren't that big.

Re: Micro-libraries should never be used

#115

Post by foul » Mon, Aug 19, 2024, 1:24 AM UTC

zx8080 wrote: post #111

foul wrote: post #96

Earlier quoted context omitted.

The HTTP-centrism is the worst. QUIC is hilarious because they ended up fitting everything and the kitchen sink for any need in the proto, just because 15 years ago firewalls blocked this or that and the reimplementation with websockets of the thing that was blocked runs only in a browser.

> The HTTP-centrism is the worst. > QUIC is hilarious It's apples to oranges. QUIC is actually used _with_ HTTP/3. Consider not mix transport level (QUIC) and application level (HTTP) protocols in the same comparison to oppose them.

First draft of HTTP/3 was called "HTTP/2 Semantics Using The QUIC Transport Protocol". I'm sorry, i should've laid that more shoddily and call that "GoogleHTTP".

Re: Micro-libraries should never be used

#116

Post by flysand7 » Mon, Aug 19, 2024, 1:31 AM UTC

foul wrote: post #37

userbinator wrote: post #11

and because it updates fairly frequently I fail to comprehend how a single-function-library called "isNumber" even needs updating, much less "fairly frequently". The debate around third-party code vs. self-developed is eternal. IMHO if you think you can do better than existing solutions for your use-case, then self-developed is the obvious choice. If you don't, then use third-party. This of course says a lot about th…

>I fail to comprehend how a single-function-library called "isNumber" even needs updating, much less "fairly frequently". If someone uses isNumber as a fundamental building block and surrogate for Elm or Typescript (a transpiler intermediate that would treat number more soundly I hope), this poor soul whom I deeply pity will encounter a lot of strange edge-cases (like that one stated in the article: NaN is a number o…

> [...] and sometime succeed

Nothing is ever certain when you program in javascript.

Re: Micro-libraries should never be used

#117

Post by zbentley » Mon, Aug 19, 2024, 1:54 AM UTC

conradludgate wrote: post #83

DonHopkins wrote: post #56

Earlier quoted context omitted.

Sometimes importing zombie "undead code" libraries can be beneficial! I just refactored a bunch of python computer vision code that used detectron2 and yolo (both of which indirectly use OpenCV and PyTorch and lots of other stuff), and in the process of cleaning up unused code, I threw out the old imports of the yolo modules that we weren't using any more. The yololess refactored code, which really didn't have any ch…

This is mortifying. This should not be acceptable implicit behaviour for imports to implicitly run code by simply existing

C libraries compiled with -ffast-math would like a word…

Re: Micro-libraries should never be used

#118

Post by bvisness » Mon, Aug 19, 2024, 2:15 AM UTC

gerdesj wrote: post #109

"The library may be a bad fit for your problem." How is this the fault of the library? You chose the wrong one! "This often cancels out the primary benefit of libraries. No, you don’t have to write the code, but you do have to adapt your problem to fit the library" You evaluated the library, found is unsuitable and yet, it is somehow their fault. Why on earth would you project your own failures on to someone else's c…

If we had perfect knowledge, we could choose perfect libraries. But we don't. Maybe someday.

Re: Micro-libraries should never be used

#119

Post by bvisness » Mon, Aug 19, 2024, 2:17 AM UTC

DonHopkins wrote: post #84

>Micro-libraries should never be used Passive voice. WHO should never use micro-libraries?

You, specifically.

Re: Micro-libraries should never be used

#120

Post by bvisness » Mon, Aug 19, 2024, 2:22 AM UTC

crabmusket wrote: post #81

While I mainly agree with the author's substantive point, though I find some of the ways it's presented in this post not entirely convincing or fair, I am interested that someone else has identified this: > I have talked a lot about the costs of libraries, and I do hope people are more cautious about them. But there’s one factor I left out from my previous discussion. I think there’s one more reason why people use li…

I think the culture of JS has been reinforced over time, and the result is a novel form of paranoia. npm makes package-sharing easy, developers share trivial packages, people use trivial packages, people rationalize trivial packages, people teach beginners never to write code, beginners think they can never write code, beginners grow up and here we are.

Certainly the language is quirky, but it really doesn't change that much. Frameworks have come and gone but JavaScript itself is still the same. is-number would have looked much the same 15 years ago, if anyone was crazy enough to actually distribute it.