4 ms·

Writing everything from scratch by hand is an insane take. It is not just reinventing the wheel but there are whole frameworks one should use because writing th

by ozim 1y ago

Writing everything from scratch by hand is an insane take. It is not just reinventing the wheel but there are whole frameworks one should use because writing that thing on your own will take you a lifetime. Yes you should not just pull as dependency thing that kid in his parents basement wrote for fun or to get OSS maintainer on his CV. But there are tons of legitimate libraries and frameworks from people who are better than you at that specific domain.

actionfromafar 1y ago
I feel you are arguing a bit of a strawman. The take is much more nuanced than write everything from scratch.
- ozim 1y ago
  ... simplest solution is often not to use a library at all and write the thing yourself, or even better, realize that you don't need the feature you would have used that library for ... the resulting code is of a manageable size.. I don't see the nuance there, that is my take of the comment, those are pretty much strongest statements and points about using libraries are minimal. That is why I added mine strongly pointing that real world systems are not going to be "managable size" unless they are really small or a single person is working on the.
  - actionfromafar 1y ago
    For me "realize that you don't need the feature" is strong and also hits home. I sometimes prototype in C because it makes me think really hard about "what does this thing really have to do? What can I omit for now?" While in for instance C# I tend to think "this would be simple to implement with whatever-fancy-thing-is-just-a-package-away". Neither way is impossible to judge as good or bad on its own. A real world system is almost always part of a larger system or system of systems. Making one thing simple can make another complex. The world is messy.
barrkel 1y ago
That's not how it works. Here's a scenario. You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. Worse, you pull in different libraries and they all pull in different versions of their own dependencies, with lots of duplication of similar but slightly different code. Node_modules usually ends up like this. The point is not writing the resize code yourself. It's the cultural effect of friction. If pulling in the resize library means you need to chase down the dependencies yourself, first, you're more aware of the cost, and second, the library author will probably give you knobs to eliminate dependencies. Perhaps you only pull in a JPEG decoder because that's all you need, and you exclude the metadata functionality. It's an example, but can you see how adding friction to pulling in every extra transitive dependency would have the effect of librabry authors giving engineers options to prune the dependency tree? The easier a library is to use, the more popular it will be, and a library that has you chasing dependencies won't be easy to use.
- lmm 1y ago
  > You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.
  - nolist_policy 1y ago
    Do you have an example?
  - barrkel 1y ago
procaryote 1y ago
There's a difference between "I need to connect to the database and I need to parse json, so I need two commonly used libs for those two things" and whatever npm is doing, and to some extent cargo or popular java frameworks are doing. Building everything from scratch is insane, but so's uncritically growing a dependency jungle

by ozim 1y ago

actionfromafar 1y ago

I feel you are arguing a bit of a strawman. The take is much more nuanced than write everything from scratch.

ozim 1y ago
... simplest solution is often not to use a library at all and write the thing yourself, or even better, realize that you don't need the feature you would have used that library for ... the resulting code is of a manageable size.. I don't see the nuance there, that is my take of the comment, those are pretty much strongest statements and points about using libraries are minimal. That is why I added mine strongly pointing that real world systems are not going to be "managable size" unless they are really small or a single person is working on the.
- actionfromafar 1y ago
  For me "realize that you don't need the feature" is strong and also hits home. I sometimes prototype in C because it makes me think really hard about "what does this thing really have to do? What can I omit for now?" While in for instance C# I tend to think "this would be simple to implement with whatever-fancy-thing-is-just-a-package-away". Neither way is impossible to judge as good or bad on its own. A real world system is almost always part of a larger system or system of systems. Making one thing simple can make another complex. The world is messy.

barrkel 1y ago

That's not how it works. Here's a scenario. You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. Worse, you pull in different libraries and they all pull in different versions of their own dependencies, with lots of duplication of similar but slightly different code. Node_modules usually ends up like this. The point is not writing the resize code yourself. It's the cultural effect of friction. If pulling in the resize library means you need to chase down the dependencies yourself, first, you're more aware of the cost, and second, the library author will probably give you knobs to eliminate dependencies. Perhaps you only pull in a JPEG decoder because that's all you need, and you exclude the metadata functionality. It's an example, but can you see how adding friction to pulling in every extra transitive dependency would have the effect of librabry authors giving engineers options to prune the dependency tree? The easier a library is to use, the more popular it will be, and a library that has you chasing dependencies won't be easy to use.

lmm 1y ago
> You pull in some library - maybe it resizes images or something. It in turn pulls in image decoders and encoders that you may or may not need. They in turn pull in metadata readers, and those pull in XML libraries to parse metadata, and before you know it a fairly simple resize is costing you 10s of MB. This is more likely to happen in C++, where any library that isn't header-only is forced to be an all encompassing framework, precisely because of all that packaging friction. In an ecosystem with decent package management your image resizing library will have a core library and then extensions for each image format, and you can pull in only the ones you actually need, because it didn't cost them anything to split up their library into 30 tiny pieces.
- nolist_policy 1y ago
  Do you have an example?
- barrkel 1y ago

procaryote 1y ago

There's a difference between "I need to connect to the database and I need to parse json, so I need two commonly used libs for those two things" and whatever npm is doing, and to some extent cargo or popular java frameworks are doing. Building everything from scratch is insane, but so's uncritically growing a dependency jungle