1. 43

  2. 18

    I concur: software can be finished, at least asymptotically. For that to be a realistic goal however, we must meet a couple conditions:

    1. The project must be small enough to begin with.
    2. The boundaries of its scope must be clearly bounded.
    3. Dependencies must be few enough, reliable enough, and stable enough.

    (1) and (2) are obvious enough, but I’ve found in practice that (3) is a major cause of “it’s impossible to finish software”. If you constantly have to keep up to the latest vulnerability of one of your dependencies, or if they keep shipping breaking changes, the only way you can finish your project is to wait for your dependencies to be finished.

    Problem is, if you only use stable, “finished” dependencies (mainstream language, a couple old libraries, widespread system interfaces), you won’t live at the cutting edge unless you sharpen it yourself. So you end up balancing the benefits of bespoke solutions (tailored to your problem, smaller, better), and the opportunity cost of implementing them.

    That being said, I have only one life. If I don’t finish my current project, I’ll never get to the next one. I need to finish.

    1. 1

      One big and complete project I’m happy to be using is the MATE desktop environment. It does require maintenance for the dependency updates, and they do add new features, but I’m happy that they don’t feel a need to make big changes for questionable reasons.

    2. 9

      I agree with basically all of this, except it wasn’t explicit that you need to announce that, and I think you need to.

      Something like SQLite does: https://www.sqlite.org/lts.html

      I know for my own projects, If I haven’t committed to the repo in a while(say a year): I try to update the README with the current status, whatever it is. (I still use this, I maintain it for me, happy to take bug reports and patches) or I don’t use this anymore, I now use X see here, or whatever the case may be.

      So it’s clear my intentions of the project. that doesn’t mean someone else can’t come along and fork and do whatever, and hey, more power to them. But my intention is at least clear.

      1. 4

        Somewhat off-topic but I love the update at the bottom of that page: “Our goal of supporting SQLite long-term have apparently come to the notice of the preservationist at the US Library Of Congress who have identified SQLite as a recommended storage format for the preservation of digital content.”

      2. 6

        This is a part of why I really love Common Lisp. Many of its libraries (like bordeaux-threads, the de facto threading library, and usocket, the BSD sockets thing) were last updated something like 10-20 years ago, and they still just work.

        This kind of ecosystem stability is refreshing when compared to a language like Rust, where all my code became unidiomatic / dependent on now-stale libraries within half a year… (!)

        1. 3

          But all your Rust code still works, doesn’t it? So it must be you love Common Lisp for some other reasons: not that bordeaux-threads still works, but that bordeaux-threads is still idiomatic.