Threads for Thornycrackers

  1. 1

    https://sedimental.org/the_packaging_gradient.html

    Packaging python can be a wild ride. For anyone feeling the pain, this guide can help you better understand. I love python and agree that the distribution is painful.

    1. 3

      https://www.codyhiar.com/blog/repeated-tasks-with-systemd-service-timers-on-nixos/

      Nixos makes managing systemd services and timers a breeze. I use them for everything. Moving jobs between different machines is just an copy paste job since everything is captured in the nix config.

      1. 1

        I remember watching “How Nix and NixOS Get So Close to Perfect” and you had a comment about not using flakes or something similar. Glad to see you’ve joined the dark side. You’re posts/shared configs are always a treasure trove of great information. Thanks for all your efforts!

        1. 5

          My issue is that I believe a software engineer should be able to apply known, repeatable, principles and practices to a software endeavor in order to produce a predictable outcome within determined constraints.

          Where does that exist in our industry, other than in non-complex systems?

          1. 10

            IME, “non-complex systems” are largely the ones built by people who treat it like engineering.

            99% of the time, complex systems come about when you let someone fuck around with new tools instead of solving a problem.

            Known, repeatable methods exist for virtually every aspect of programming, at virtually every layer.

            1. 4

              99% of the time, complex systems come about when you let someone fuck around with new tools instead of solving a problem.

              Indeed! Needlessly complex systems come about when you allow that to happen in pretty much any industry. The complexity of a problem tends to translate into complexity of the software that solves it, much like it tends to translate into complexity of the machinery that solves it. E.g. tax software is very complex because tax legislation is very complex, even though it’s “just” arithmetic, much like photolithography equipment is very complex because the sequence of chemical and physical processes it steers is very complex.

              Granted, not all problems being solved stem straight from the “real-world” application of a program. Things like allowing only people with the right clearance to view some documents (“security”) are also legitimate problems that a system may need to solve. The bloat line isn’t always easy to draw.

              But complexity additional to that of the legitimate problems being solved is entirely self-inflicted, and often arises because nobody in charge or anything has any understanding of what’s important and what isn’t, so they let everyone – or, worse, they insist that everyone – fuck around with new tools.

            2. 2

              There’s a glimpse of this in the industry already. It’s a niche but it’s there. Formal methods.

              For example, there are relatively big systems (tens of KLOC) being built using Dafny or Spark.

              They use techniques that are repeatable, simple and pretty well understood (imperative languages + contracts).

              Once there’s an incentive to use them more, I guess bigger systems will be built by composing simpler verified parts. The biggest problem is cost. It’s 3-6x more costly to build software like this, and it’s much slower.

              1. 2

                One open problem is that most proofs don’t compose, as I understand it, so you can’t just use small verified parts and compose them into a larger verified whole, you have to re-verify the whole as an entire system, at least for some classes of formal methods. @hwayne I think has more details there.

                1. 1

                  Absolutely. Dafny for example only carries postconditions forward to keep tractability while composing things, but that looses some information so it’s a compromise. In practice, I think it works quite well.

                2. 1

                  I think that is an interesting point, but is that glimpse on the fringes? A much more pressing need is surely to find a predictable way to model a complex domain problem in code? When I started programming about 40 years ago the question of the day was how to represent business logic and constraints outside of a data model. Stored procedures, or… what? In some ways nothing has really changed, albeit instead of stored procedures the engineering of the day is transactional scripts organized using functional decomposition which rapidly approach a big ball of mud as complexity increases. Hmm, sounds just like 30 years ago, but without the “agile” and “services” terminology that provide a diversion today.

                  Formal methods are I think answering a question of how, where the problem is more one of “what”?

                  “The hardest single part of building a software system is deciding precisely what to build.”, Frederick Brooks – “No Silver Bullet”

                3. 2

                  I’m going to make a leap of faith and assume you’re saying that because you feel that other “engineering” fields have those properties…they really don’t, in my experience working closely alongside mechanical, electrical, and chemical engineers.

                  1. 1

                    No I made no statement about other engineering disciplines.

                  2. 1

                    Release Engineering?