1. 10

  2. 7

    I don’t entirely agree with the first part. Sure, the software should be updated for maintenance, but there comes a point where a piece of software does not need any updates simply because it is feature complete. If one targets POSIX, sanitises and lints code, tests thoroughly, and keeps as dependency-free as possible, then it does not need updating as often.

    The idea that regularly updated => works well, comes from tools and programs that target either ephemeral platforms (Think Android, IOS, or Web – where manufacturers (of phones or web-browsers) push out regular updates so they can keep an income), or from programs that target the strata at the upper layers of abstraction. Too much abstraction is like a Faustian deal, it can be powerful, and will save you time in the short term. But that comes with the downside that the strata shifts much more frequently, so your program will either fall into disrepair earlier, or break earlier.

    1. 3

      Completely agree. At work, a lot of the stuff is written in C, 20 to 30 years old, and works like a charm. I’ve worked in more ‘modern’ environments too, where everything was written by juniors and bug-ridden. ‘Modern software’ is often an euphemism for “we don’t quite understand it yet, but we try” (hence the need for updates).

      1. 1

        Ditto with Common Lisp; libraries get written, battle-tested, and then nothing much more needs to be done with them. Still, I’ve seen people turned away because they’re used to software never being “finished”.

        1. 3

          This was exactly the point I wanted to make. When I started using Common Lisp, these “last commit is 6 years old” libraries were really confusing. I eventually get used to it, but there remains a problem: it is sometimes difficult to distinguish at first glance “never finished” and “battle-tested” libraries.

      2. 1

        I also don’t entirely agree with the first part either.

        How do you think we could educate people on this front? And/or do you think there is a good way to reduce abstraction churn for a project over time?

        1. 3

          As much as I have a visceral distaste for the aesthetics of the Rust language, I think it’s aim for “zero cost abstractions” is in fact the right one. Smalltalk-80, and other languages not only ran on computers with much less power than computers today have, but had more expressive power.

          There isn’t any reason why we can’t build software that functions at a lower layer but provides the same convenience as those on the high-layer.

          It’s funny I saw this now, I’ve spent the night pondering about hacking on a fork of netsurf (the ridiculously small browser) that integrates with python, not just because I deeply, deeply dislike Electron, but I’m working on a project that requires the custom-UI. I don’t like things that don’t integrate with accessibility software, and it’s my understanding that netsurf does, which would make it ideal.

          Ultimately I feel the solution to the abstraction problem would be something like Ocaml, but with enough C behind it syntax-wise to make it lightweight to use. Or maybe a neutered Javascript, that compiles and runs on a native computer (i.e. not nodejs).

      3. 5

        Common Lisp community is said to be famous for having libraries that haven’t been touched in more than a year. But it implies stability there.