4 ms·

Each dependency increases the cognitive load for maintenance (something goes wrong/is slow/doesn't compile in that platform or requires steps incompatible with

by Crinus 7y ago

Each dependency increases the cognitive load for maintenance (something goes wrong/is slow/doesn't compile in that platform or requires steps incompatible with the rest of the project/other issue, is it me or the 20839423 libraries i depend on? How does that library that has the issue work? How do i fix it? These are things C programmers tend to care about) as well as reliance on 3rd parties to stay in line with your needs (e.g. you may want to stick with C89 but a library you depend on - or a library a library you depend on depends on - decided to raise minimum requirements to C99 "because everyone has that now" or one of your dependencies stops development for whatever reason - in either case you are left with the choice of dropping the dependency - and anything that depends on it - or taking over maintenance for something you decided to use in the first place to avoid that sort of work).

avar 7y ago
Very little of what you mention would apply to the GP since they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. Guile's list of mandatory dependencies is short, and consists of libraries like libgmp (also used by GCC), libiconv etc., I doubt a packager would have much issue with the stability of those. These are libraries that work on dozens of platforms across a wide range of compiler versions: http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 More generally the trade-off with libraries cuts both ways, and I've seen other programmers underestimate the maintenance burden of rolling their own v.s. the investment in just including a well-tested third-party library. E.g. it's very common for C programs to have their own buggy and often insecure version of something like a string library, DNS resolver etc. That's not free for you as a user of those programs either. E.g. the other day I was dealing dealing with an issue in how bitlbee resolves SRV records with its own home-grown code instead of using something like GResolver, which wouldn't have had that issue.
- Crinus 7y ago
  My comment was about the <<I've never understood why some shy away from "number of dependencies" per-se for C projects>> part, not Guile itself although it also applies to what you wrote, specifically this: > they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. ...as it doesn't matter if they are using these other dependencies directly or indirectly, they are still dependencies of their application - if anything these are dependencies they didn't have any say over (they had say over depending on their direct dependency - like Guile - but not on their dependency's own dependencies which were decided by the programmers of that dependency) so they have less knowledge on how those are used and why they are used (knowledge they may need to gain in the case where something goes bad as i wrote above). Basically the more dependencies you have (not necessarily the number of libraries you depend on but also how much of each library you are using), the more people you invite to have a say in how your project will work and as such the more likely to encounter friction and misaligned goals. This is why a lot of C programmers prefer to use small single-purpose libraries (to the point where "single header libraries" have taken off significantly) and avoid huge "multitool" frameworks. > its own home-grown code instead of using something like GResolver, which wouldn't have had that issue. Perhaps, but it may have had other issues you (or even the programmer who wrote that code) didn't know about.
  - avar 7y ago
    At this point we'd be better off with the GP chiming in, what I was responding to was "after running into problems with the number of Guile dependencies". So not the stability of the dependencies, or any specific issue with them, just the number of them. In practice I've encountered a lot of cases where C programmers in particular tend to get what's best described as dependency vertigo resulting in badly re-inventing the wheel. I'd be much more confident in using Guile with its 10 dependencies (or thereabouts) than some random similarly-sized C program. Something the size of Lua or Guile isn't someone's weekend project. No matter what other people have a say in the direction of your program. I'd argue that you're generally better off structuring it in such a way as to make use of already-invented wheels, and users are better off not shying away from dependencies. We're not talking about something like the absurd 100-line dependencies node.js has made famous, but whether a compiler like Lua needs to implement its own bignum handling (or as it at all), v.s. Guile doing the same via libgmp, and thus sharing bignum behavior with something as well-tested as GCC. If you're a Guile core developer would you rather e.g. deal with guile's home-grown text encoding library or iconv? I know which one I'd pick both as a developer & user.

by Crinus 7y ago

avar 7y ago

Very little of what you mention would apply to the GP since they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. Guile's list of mandatory dependencies is short, and consists of libraries like libgmp (also used by GCC), libiconv etc., I doubt a packager would have much issue with the stability of those. These are libraries that work on dozens of platforms across a wide range of compiler versions: http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 http://git.savannah.gnu.org/cgit/guile.git/tree/README#n20 More generally the trade-off with libraries cuts both ways, and I've seen other programmers underestimate the maintenance burden of rolling their own v.s. the investment in just including a well-tested third-party library. E.g. it's very common for C programs to have their own buggy and often insecure version of something like a string library, DNS resolver etc. That's not free for you as a user of those programs either. E.g. the other day I was dealing dealing with an issue in how bitlbee resolves SRV records with its own home-grown code instead of using something like GResolver, which wouldn't have had that issue.

Crinus 7y ago
My comment was about the <<I've never understood why some shy away from "number of dependencies" per-se for C projects>> part, not Guile itself although it also applies to what you wrote, specifically this: > they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. ...as it doesn't matter if they are using these other dependencies directly or indirectly, they are still dependencies of their application - if anything these are dependencies they didn't have any say over (they had say over depending on their direct dependency - like Guile - but not on their dependency's own dependencies which were decided by the programmers of that dependency) so they have less knowledge on how those are used and why they are used (knowledge they may need to gain in the case where something goes bad as i wrote above). Basically the more dependencies you have (not necessarily the number of libraries you depend on but also how much of each library you are using), the more people you invite to have a say in how your project will work and as such the more likely to encounter friction and misaligned goals. This is why a lot of C programmers prefer to use small single-purpose libraries (to the point where "single header libraries" have taken off significantly) and avoid huge "multitool" frameworks. > its own home-grown code instead of using something like GResolver, which wouldn't have had that issue. Perhaps, but it may have had other issues you (or even the programmer who wrote that code) didn't know about.
- avar 7y ago
  At this point we'd be better off with the GP chiming in, what I was responding to was "after running into problems with the number of Guile dependencies". So not the stability of the dependencies, or any specific issue with them, just the number of them. In practice I've encountered a lot of cases where C programmers in particular tend to get what's best described as dependency vertigo resulting in badly re-inventing the wheel. I'd be much more confident in using Guile with its 10 dependencies (or thereabouts) than some random similarly-sized C program. Something the size of Lua or Guile isn't someone's weekend project. No matter what other people have a say in the direction of your program. I'd argue that you're generally better off structuring it in such a way as to make use of already-invented wheels, and users are better off not shying away from dependencies. We're not talking about something like the absurd 100-line dependencies node.js has made famous, but whether a compiler like Lua needs to implement its own bignum handling (or as it at all), v.s. Guile doing the same via libgmp, and thus sharing bignum behavior with something as well-tested as GCC. If you're a Guile core developer would you rather e.g. deal with guile's home-grown text encoding library or iconv? I know which one I'd pick both as a developer & user.