1. 33
  1.  

  2. 10

    Software doesn’t have to be finished. Monotheism has created a fraudulent non-goal of having a singular perfect global state. We should embrace a many rooted tree, like Nix . Done should mean usable for what we are using it for.

    1. 2

      i don’t think it’s so much a desire for a singular perfect global state as the desire to build software as a fractal structure of non-leaky abstractions. e.g. from the op’s example of how he would ideally develop nanomsg:

      1. compatibility library, e.g. apl, libuv
      2. coroutine library, e.g. libtask, libmill
      3. the core: messaging protocols

      It may even make sense to implement individual messaging protocols as separate components.

      he wants each piece to be a perfectly polished, self-contained lego block that he can snap into place when it’s completed.

    2. 15

      I appreciate the sentiment here, but it seems to forget two points:

      1. A lot of the software we write was never intended to really have users. It scratches our itch, and we move on. If a user picks this software up, it feels incomplete, but at that point we’ve moved on.
      2. What does it mean to even be complete? Software doesn’t really ever become finished, so finishing software feels like a very difficult goal to reach.
      1. 15

        libxml2 is complete. Look at the release history, there hasn’t been a major feature added to the library in years despite it being one of the most popular packages. 98.96% of hosts with popcon installed have libxml2, yet most of the work put into it is security fixes and OS/400 compatibility.

        1. 13

          I really love software that is complete.

        2. 5

          Yes fully agree. Half of the stuff I have on github is there mostly cause why not. I have zero plans to support it, or even finish half of it. Most of the time you get further into the weeds and realize, well I really don’t need this that bad for the effort it will take to do this right. Or you decide to backburner it and give it a think because you don’t feel you understand the problem well enough yet.

          Also I worry about this idea that software is never finished. I feel like we’re in a weird perpetual loop or maybe a rut just spinning our wheels and not going anywhere with all this churn going on. I want done tools. Or tools that do the thing they need to well enough they are effectively done. All this constant wheel reinvention is maddening.

          1. 3

            I hear you, on that, and I see both sides. I think software is at the intersection of tool and art. One should strive to reach the goals that are reachable, and covering the same ground every decade is beyond frustrating.

            My personal pet peeve is self-describing data formats, which, with the amount of ire they have always drawn, surely would not keep being reinvented if they didn’t fill a real need… The lack of obvious progress is quite demotivating.

            Just to balance that with a less depressing example, if one looks at language design, there have been enormously many new ideas, and everything’s being explored at once right now, and it’s kind of wonderful the sheer variety that exists. If languages are ever a “finished” problem, computing will be in a much better state than it is today.

            On the gripping hand, I don’t actually think that stability in software is always a sign of it being good. I get frustrated with tools like bash, which does get its job done, and if it’s had any movement in the past decade I haven’t noticed, … but I absolutely hate using it. I wouldn’t view that as a problem the authors of bash are obligated to address; clearly, they’ve made the artistic statements they have to make, and it’s unreasonable to expect them to have more indefinitely. But that leaves room in that area for somebody else to say something new.

            1. 4

              I will admit, self describing data formats to me really probably should end up being a lisp or maybe a scheme, just evaluate/execute the data and get what you want out of it. But I’m a weird person that way. >.< I’ll admit I haven’t thought this through that much.

              And agree on languages, I’m not saying stop developing new languages to be sure, nor do I think herding all those cats will be possible to ever do. Take the recent Haskell AMP change. Language theory in the past decade has changed how we view things, and for the better in my opinion. Onward and upwards in that regard, even if it is painful. I hope for more pain in getting to dependent types in Haskell. But I don’t consider languages to be in the tool category.

              As for bash, I’ll agree that it sucks (joking here), but i’m a zsh heathen so of course i’d say that. But more to the point, I would consider most shells to be “done” at this point. bash for example does keep piling more stuff on, as does zsh, but fundamentally, they tend to still serve their original and by this point ancient root purposes of a command shell and interpreter. Keeping backwards compatibility here is a required feature.

              For it not being modern, sure I don’t disagree but replacing it might mean a lot of false starts and we might end up back where we started. If whomever decides to create a “better *sh” doesn’t look at the plan9 shell, tcsh, csh, ksh, bash, zsh, fish, i’m sure I missed some unicorn shell or other, I think we’ll just end up where we’re at, with 40% solutions that in the end leave a bitter taste.

              I know I feel that way about some new things recently. That or maybe I’m just old now and need kids to get off my lawn. :D

              But the more I look and read papers from the 60’s, 70’s, and so on, the more I realize we reinvent the same crap over and over again. More often than not poorly, malign say APL all you want but it is a great language and there is a LOT to learn from it that directly relates to our problems today.

              1. 2

                Heh - I’ve thought it through quite a lot. I don’t feel up for giving the elevator pitch of my pet project right now, but the thing about using a procedural rather than a declarative description of data is that you lose the ability to operate on it with tools that know some things about its structure, without knowing everything - for example, “this is an array and here is a comparator for its items; sort it”. Anyway, I think solutions are possible.

                Languages are indeed definitely much more art than tool, but at the same time they need to work, or they’re useless. The thread at first wasn’t distinguishing between types of software - “finish your stuff” doesn’t say what type of stuff - and I’m glad it has now become more nuanced. :)

                I agree with you also that replacing things doesn’t automatically make them better. This is why I feel the art analogy is so strong. There have been periods in art history where everything got very cliquish and, despite there being a lot of people making things, they were all making more or less the same thing, over and over. Somebody has to actually have a new, better idea, at some point. And that almost always has to be informed by what has gone before, or it’ll just restate what’s already been said.

                So, yes, I was specifically not making a call to arms to rewrite bash. Not unless somebody feels they understand the problem space and the solutions we’ve seen so far, at least! I feel like in many ways the Lisp-based shell on Genera was better than anything one can easily run today, but I also don’t think it would be useful today. It’s a hard problem.

                And yeah, I am sure I’ve read different things than you but I make it my business to read papers on historical innovations in computing. I completely agree that a great deal of “new” work isn’t.

              2. 1

                i think a lot of it ties in to the other point the article was making, which is to define the scope of your project so cleanly and narrowly that it is self-evident when it is finished. that project can then be used as a clean, reliable building block in other software. i have to admit that it is a very attractive ideal to aim for, even if i seldom get there in my own stuff. (in large part, because the tooling ecosystem encourages developing projects as monoliths; developing, versioning and testing parts independently can get fairly messy.)

          2. 6

            I personally feel that my software will be finished when I’m dead, by definition, and not before. Of course, I’d love it if some of it becomes somebody else’s unfinished software at that point. :) Even with a small project, I don’t believe that one can ever draw a line and say it is everything it could be. With the projects that interest me most, I don’t believe the initial goals are finite in scope, and that’s the point. :)