undefined | Better HN

0 pointsd4mi3n2y ago0 comments

The trick is to dig deeper into those big library's dependencies as well. It's turtles all the way down.

The other thing I find is that big libraries are either mostly dependency bloat (as implied above) or dealing with a hard domain problem. If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent.

0 comments

hutzlibu2y ago

"If it's the latter, what you're really struggling with is not the library, but the domain it's trying to represent."

But this doesn't change anything of the programmers problem. If I stumble on a bug in a physics libary I am using for a game, I cannot just jump right into there and go fixing things. I mean I can start doing it, but at the cost of not getting anything else done for quite some time.

There are lots of hard domains in programming. Cryptography is hard. Networking is hard. Fast rendering is hard. Efficient DBs are hard. OS are hard. Drivers are hard.

You can maybe fix a trivial error in such libaries, but everything else is usually a (big) project on its own.

d4mi3nOP2y ago

Absolutely correct, but I think it’s still valuable to be able to recognize if you’re struggling against the code or the domain.

Additionally, once you recognize that you can also recognize if you’re dealing with incidental complexity (e.g. poorly thought out/designed code) and inherent complexity (e.g. physics calculations). The former can be fixed, the latter cannot. Knowing the difference saves much pain.

j / k navigate · click thread line to collapse