Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Micro-libraries should never be used

bvisness.me

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Micro-libraries should never be used

#151

Post by mewpmewp2 »

ristos wrote: 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…

These days with LLMs, doing leftPad yourself is incredibly easy, I would just do that.

Re: Micro-libraries should never be used

#152

Post by VonGallifrey »

mewpmewp2 wrote: post #151
ristos wrote: 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…

These days with LLMs, doing leftPad yourself is incredibly easy, I would just do that.

With LLMs? I don't think something like leftPad was every difficult to create.

Re: Micro-libraries should never be used

#153

Post by ristos »

reaperducer wrote: post #24
ristos wrote: 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…

The UNIX philosophy is also build on the idea of small programs, just like micro-libraries, of doing one thing and one thing well, and composing those things to make larger things. This year I started learning FORTH, and it's very much this philosophy. To build a building, you don't start with a three-story slab of marble. You start with a hundreds of perfect little bricks, and fit them together. If you come from a t…

Yeah, exactly! FORTH looks really awesome, I haven't gotten around to learning it much though. I heard it's addictive and fun.

Yeah, it's all concatenative programming: FORTH, unix pipes, function composition as monoids, effect composition as kliesli composition and monads, etc.

It makes it super useful for code readability (once you're familiar with the paradigm), and debugging, since you can split up and decompose any parts of your program to inspect and test those in isolation.

Re: Micro-libraries should never be used

#154

Post by mewpmewp2 »

VonGallifrey wrote: post #152
mewpmewp2 wrote: post #151

Earlier quoted context omitted.

These days with LLMs, doing leftPad yourself is incredibly easy, I would just do that.

With LLMs? I don't think something like leftPad was every difficult to create.

Well if you think about it then yes, but thinking and making sure is a waste of energy and time. Also typing the boilerplate.

This energy could be spent elsewhere.

Like similarly it is not that hard to pick clothes for the day, but it is much easier if you always have the same clothes easily available and can move on with your day.

Re: Micro-libraries should never be used

#155

Post by throwitaway1123 »

bborud wrote: post #146
throwitaway1123 wrote: post #139

Earlier quoted context omitted.

> 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

Yeah, the thing is that `yes` isn't a stand alone project, it is usually part of a bigger project such as coreutils ( https://github.com/coreutils/coreutils/ ). For the comparison to be valid you would have to split up coreutils into roughly 100 individual repositories and replace many of the implementations with ones that are trivial, buggy, and/or unmaintained that pose a supply chain attack risk because it gets ha…

> For the comparison to be valid you would have to split up coreutils into roughly 100 individual repositories and replace many of the implementations with ones that are trivial, buggy, and/or unmaintained that pose a supply chain attack risk because it gets hard to keep track of what's maintained, by whom and how.

You could paraphrase that as: core utilities that ship with my operating system should obviously be more reliable than random code fetched from the internet.

> For the comparison to be valid

I was responding to the limited scope of your statement "Yet, they are still a lot bigger than most micro-libraries. And more complex." Utilities like `yes` and `true` are neither big nor complex. The man pages are longer than the source code necessary to replace them.

Re: Micro-libraries should never be used

#156

Post by DonHopkins »

buildbot wrote: post #112
conradludgate wrote: post #83

Earlier quoted context omitted.

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?

How it works and how it should be used are different.

Say “no” to import side‐effects in Python:

https://news.ycombinator.com/item?id=7536246

https://chrismorgan.info/blog/say-no-to-import-side-effects-...

>I must be able to import your module— any module— at any time without anything breaking.

Or even the beneficial side effect of some other module running 10% faster. ;)

What side-effects, if any, are okay when importing a python module?

https://softwareengineering.stackexchange.com/questions/4540...

>Q: Is this a better design pattern or does it just kick the issue down the road?

>A: Kicking the issue down the road is the basic idea of the "functional core, imperative shell" design pattern.

Functional Core, Imperative Shell (2012):

https://news.ycombinator.com/item?id=34860164

https://www.destroyallsoftware.com/screencasts/catalog/funct...

Re: Micro-libraries should never be used

#157

Post by jvanderbot »

ristos wrote: 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…

Micro libraries are ok - TFA even says you can use self-contained blocks as direct source.

Mirco dependencies are a god damn nuisance, especially with all the transitive micro-dependencies that come along, often with different versions, alternative implementations, etc.

Re: Micro-libraries should never be used

#158

Post by n0tank3sh »

It really depends on the case. Some folks use the left-pad library for aligning, which can be done in 10 minutes. In C++, we have header libraries for thread pools, etc. I don't think implementing a fully functional thread pool with waiting and other features is an easy task. In conclusion, it really depends on the situation.

Re: Micro-libraries should never be used

#159

Post by Brian_K_White »

n0tank3sh wrote: post #158

It really depends on the case. Some folks use the left-pad library for aligning, which can be done in 10 minutes. In C++, we have header libraries for thread pools, etc. I don't think implementing a fully functional thread pool with waiting and other features is an easy task. In conclusion, it really depends on the situation.

No it doesn't. The answer to needing a string manipulation function would be to use a string manipulation library that include that function, not one that is nothing but that finction.

If you don't need anything else, and having the linker not include unused code isn't good enough, then just vendor the single function.

There could still be some special case but that will need a lot of explaining to justify and will be such an exception that it is silly to talk about. There are legitimate one time freak exceptions to every principle. It means nothing.

Re: Micro-libraries should never be used

#160

Post by Brian_K_White »

oftenwrong wrote: post #87

The primary cause of the left-pad incident was that left-pad was removed from the npm registry. Many libraries depended on left-pad. The same could have occurred with any popular library, whether micro or not. To reformulate the statement made in the intro of this post: "maybe it’s not a great idea to outsource _any critical_ functionality to random people on the internet." It has long been a standard, best practice…

The problem with micro is 100 micros is 100x more surface area and chances than 1.
Post reply on HN