4 ms·

All projects would be well served by carefully keeping their dependency graph small and conservative.

PaulDavisThe1st 7y ago
So you think that rather than see that list grow, they should all reimplement their own (drawing examples from my own project): * font rendering * audio file I/O * resampling * websocket support * OSC support * i18n * XML parsing * .... ? In our case, 89 libraries. 2GB of compiled libraries. Surely you can't be serious. Unless you just don't believe in "big, complex software" ?
- ddevault 7y ago
  89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long tail of stuff you didn't mention includes a lot of more trivial dependencies. I don't know your project, but I imagine that you ought to redefine your scope to avoid introducing a need on complex dependencies. Simpler software is more robust, more maintainable, and often gets the job done better - but it's more difficult to make. In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).
  - akkartik 7y ago
    As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience. vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.
  - PaulDavisThe1st 7y ago
    https://nightly.ardour.org/list.php#build_deps https://nightly.ardour.org/list.php#build_deps C++ (with a tiny bit of assembler). Most of our dependencies arise from our choice to use GTK, but there's a fair number that do not. I wouldn't call any of them trivial dependencies. Edit: on the order of a dozen of the deps are actually requirements for the build system of libs we depend on (e.g. autotools nonsense), but from a practical perspective, they are dependencies that have to be satisfied if you want to build Ardour completely from scratch (by which we mean, alternately, a Linux system with only libc, libstdc++ and X, or a new macOS install).
    - ddevault 7y ago
      Build deps aren't free, but have different constraints and effects. Anyway, if this is your full dependency tree - with transitive dependencies included - this is fairly reasonable. I reckon Boost doesn't need to be there, and you're probably well past the point of diminishing returns with GTK+ and a UI like yours, but otherwise this seems reasonable to me. You should also consider moving on from autotools by now, I recommend Meson as a replacement. These kinds of questions - is autotools still a good choice? Do we really need Boost? Is GTK+ doing us any favors? Answering these is the "careful keeping of your dependency graph small and conservative" that I am referring to.
      - PaulDavisThe1st 7y ago
        Yes, this is a fully transitive deps list. I mentioned autotools as part of the build system of some of our dependencies. We abandoned it ourselves in disgust many years ago (in favor of waf; meson may be in our future). Boost is critical for us because we aim for compatibility (and for macOS that means buildability) on systems only reaching C++98, meaning that boost fills in large parts of the then-missing std:: namespace (such as shared_ptr<>). We will move to C++11 after our 6.0 release, but boost still provides several other very useful bits of functionality. GTK+ remains useful even as we slowly move away from it, and there remains the big four (text entry, file browsing, treeviews and menus) that will be a huge effort to reimplement. Our goal is to eventually depend only upon GDK (i.e. a thin window system wrapper), but I doubt that we will ever reach that goal.
- akkartik 7y ago
  I'm not Drew DeVault, but I think there's value in taking responsibility for your dependencies. You don't need to understand all of it on day 1, but as you use it and run into issues you should be gradually understanding its internals better, gradually resolving features that you use vs features that you don't. That then gives you the option to rip out stuff you're sure you'll never need. Or to rip out stuff you may need in future, but is easy to put back (this is analogous to deleting code without fear because version control). One "value" of of libraries is that it allows us programmers to spread out responsibility for breakage. What if we didn't do that? What if we exchanged software in units of working computing stacks, to take the idea to an extreme. It seems unquestionably useful to the world. So it seems worth exploring how close to that ideal we can feasibly get. (Part of this comment was reworked from https://news.ycombinator.com/item?id=16882140#16882555 https://news.ycombinator.com/item?id=16882140#16882555 back in 2018.) (I research ways to distribute software as complete stacks: http://akkartik.name/akkartik-convivial-20200315.pdf http://akkartik.name/akkartik-convivial-20200315.pdf)

So you think that rather than see that list grow, they should all reimplement their own (drawing examples from my own project): * font rendering * audio file I/O * resampling * websocket support * OSC support * i18n * XML parsing * .... ? In our case, 89 libraries. 2GB of compiled libraries. Surely you can't be serious. Unless you just don't believe in "big, complex software" ?

ddevault 7y ago
89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long tail of stuff you didn't mention includes a lot of more trivial dependencies. I don't know your project, but I imagine that you ought to redefine your scope to avoid introducing a need on complex dependencies. Simpler software is more robust, more maintainable, and often gets the job done better - but it's more difficult to make. In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).
- akkartik 7y ago
  As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience. vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.
- PaulDavisThe1st 7y ago
  https://nightly.ardour.org/list.php#build_deps https://nightly.ardour.org/list.php#build_deps C++ (with a tiny bit of assembler). Most of our dependencies arise from our choice to use GTK, but there's a fair number that do not. I wouldn't call any of them trivial dependencies. Edit: on the order of a dozen of the deps are actually requirements for the build system of libs we depend on (e.g. autotools nonsense), but from a practical perspective, they are dependencies that have to be satisfied if you want to build Ardour completely from scratch (by which we mean, alternately, a Linux system with only libc, libstdc++ and X, or a new macOS install).
  - ddevault 7y ago
    Build deps aren't free, but have different constraints and effects. Anyway, if this is your full dependency tree - with transitive dependencies included - this is fairly reasonable. I reckon Boost doesn't need to be there, and you're probably well past the point of diminishing returns with GTK+ and a UI like yours, but otherwise this seems reasonable to me. You should also consider moving on from autotools by now, I recommend Meson as a replacement. These kinds of questions - is autotools still a good choice? Do we really need Boost? Is GTK+ doing us any favors? Answering these is the "careful keeping of your dependency graph small and conservative" that I am referring to.
    - PaulDavisThe1st 7y ago
      Yes, this is a fully transitive deps list. I mentioned autotools as part of the build system of some of our dependencies. We abandoned it ourselves in disgust many years ago (in favor of waf; meson may be in our future). Boost is critical for us because we aim for compatibility (and for macOS that means buildability) on systems only reaching C++98, meaning that boost fills in large parts of the then-missing std:: namespace (such as shared_ptr<>). We will move to C++11 after our 6.0 release, but boost still provides several other very useful bits of functionality. GTK+ remains useful even as we slowly move away from it, and there remains the big four (text entry, file browsing, treeviews and menus) that will be a huge effort to reimplement. Our goal is to eventually depend only upon GDK (i.e. a thin window system wrapper), but I doubt that we will ever reach that goal.
akkartik 7y ago
I'm not Drew DeVault, but I think there's value in taking responsibility for your dependencies. You don't need to understand all of it on day 1, but as you use it and run into issues you should be gradually understanding its internals better, gradually resolving features that you use vs features that you don't. That then gives you the option to rip out stuff you're sure you'll never need. Or to rip out stuff you may need in future, but is easy to put back (this is analogous to deleting code without fear because version control). One "value" of of libraries is that it allows us programmers to spread out responsibility for breakage. What if we didn't do that? What if we exchanged software in units of working computing stacks, to take the idea to an extreme. It seems unquestionably useful to the world. So it seems worth exploring how close to that ideal we can feasibly get. (Part of this comment was reworked from https://news.ycombinator.com/item?id=16882140#16882555 https://news.ycombinator.com/item?id=16882140#16882555 back in 2018.) (I research ways to distribute software as complete stacks: http://akkartik.name/akkartik-convivial-20200315.pdf http://akkartik.name/akkartik-convivial-20200315.pdf)