1. 23
  1.  

  2. 8

    IMO, the issue here is not that using external deps is wrong and we should be writing 15 lines of bespoke I/O code, but rather than we need to stop writing big crappy libraries relative to the problem they solve. It’s easy to look at that problem and locally decide 15 lines saves you a lot of trouble, and it clearly does. However globally, that 15 lines of code has been written thousands of times, and several of them probably have their own security vulnerabilities in them. At least if the security vulnerabilty were fixed in the 800 line library, it would be fixed everywhere (that upgraded).

    1. 8

      Depends on what the fifteen lines does relative to the problem that’s being solved. Replacing fifteen lines that did their job with 800 lines of unknown code is a net negative in my book, regardless of our ideas about ‘best practices.’

      The only way forward for software is embracing minimalism: what do we need in our apps/libs/languages? Throw everything else out, because it bites us in the end.

      Software is not much fun when you’re so close to the bleeding edge that you have to keep up with what you should be using. We can and should audit third party dependencies for their code to make sure that they don’t suck, rather than relying on star counts and Bootstrapped sites.

      1. 7

        I think it’s too late. Software is accreting faster than it can reasonably be audited or even understood, and further layers are being laid down on top of the rancid layer cake that already exists. I think everyday software will get better, at least in a consequentalist sense, as more and more band-aids are applied; but the failures will be all the more spectacular for that.

        I’d like to be a rejectionist, but I just don’t see a way down to anything that isn’t itself built on a mound of garbage.

        1. 4

          This is a lot of why, as an industry, I think we need to spend the next twenty years redoing all our infrastructure to take advantage of formal verification. Compilers, kernel, libraries, everything. Yes, there are immense practical problems with even starting that today, but the seL4 microkernel is showing the way.

          We can continue to build on garbage, or we can start planning for something better. Realistically, we can expect to be doing both in parallel for a long time. :)

          1. 4

            I would like to think you’re right, but I fear that the economics of the way that software is built are such that there is no incentive to do a good job, other than the good taste of the various practitioners, and at the end of the day, we all need to put food on our family’s table. I do things all day every day that I know are bad, but I need to hit my deadlines more than I need to fix the glaring awful problems with e.g. Unix or C or Emacs or anything.

            1. 4

              “We need to” doesn’t imply “we are able to”. Yes, it’s depressing.

              We did manage to get everyone using UTF-8, which took about twenty years (it was invented in 1992). Of course, that was a smaller change, but it was similar in that almost nobody whose efforts were needed wanted to make them, at first.

              1. 6

                everyone

                Except, y'know, this minor niche operating system called Windows and this obscure programming language nobody cares about called Java. ;)

                Granted, things are much better now than they were even just a few years ago. Network traffic is almost entirely in UTF-8, code pages are for the most part relegated to the black pit of “legacy software we don’t touch”, and most programmers can mostly ignore encoding and have things mostly work. But it would definitely be a mistake to think we’ve solved the problem.

                1. 2

                  Agreed.

        2. 4

          I agree with everything you said. To be clear, I am not defending the 800 line library to do something that takes 15 lines, I think the 800 line library is the problem.

          IME, many libraries do not embrace callback architecture. Almost every library I wrote tries to separate the procedure from the policy. I then offer policies for common patterns. It makes libraries small and specific but also powerful enough to exend in useful ways.

        3. 3

          There’s also a trend for every programmer to have their own library (eg libtedu).

        4. 3

          Related article: Yosef K.’s Redundancy vs dependencies: which is worse? (2008)