1. 30
  1.  

  2. 8

    Use the same language for the little tools and scripts in your system too. There are few good reasons to drop down into bash or Python scripts, and some considerable disadvantages.

    I don’t understand this. If what you need to do is string together a simple sequence of commands, isn’t bash the correct tool for the job? Why waste time on compile/debug/test when you can have something that works in seconds?

    1. 4

      Yup, it’s much easier to execute commands in bash than in most other languages. On the other hand, this is mostly accidental complexity; There isn’t any reason why it has to be hard. Deep down I believe there’s no reason that we can’t develop both plumbing scripts and low-level system critical programs in the same language.

      Admittedly, in C, it’s pretty simple with the system(…) function, but in C a lot of other things are very hard.

      1. 3

        “Standard” Unix (in practice Linux and the BSDs) doesn’t have a object view of the OS. Windows has - sorta, if you limit yourself to .Net. This means that PowerShell works on objects, not plain text strings.

        To bring that mindset into Linux would be a decades-long project, at least, and require the same level of focus and goal-orientation of systemd (if not more). It would probably be as resisted as systemd, too.

        Maybe one could get halfway by ensuring that a decently capable scripting language (Lua?) was always available on a Unix.

        1. 2

          What would be neat is a way of using shell completion to generate wrapper libraries for use in non-scripting programming languages.

          1. 1

            So it’d be like a subprocess control library generator? That’s a neat idea, although bear in mind that some of the complexity around shell scripting isn’t just enumerating the various available commands and their inputs but also leveraging their relationships through operating system interfaces.

          2. 1

            Admittedly, in C, it’s pretty simple with the system(…) function, but in C a lot of other things are very hard.

            That’s precisely it. The devil’s in the details :) Sure, executing a command is easy, but even bash scripts very rarely JUST execute commands. You pipeline, check return codes, make decisions and the like.

            1. 1

              I find that all languages I frequently use make an equivalent of system() simple enough. Python and OCaml also make interacting with external processes (i.e. writing to their stdin and reading their stdout/stderr) simple enough.

              I’m pretty sure one can make a nice interface for that for any language, it’s just that some come without it in their standard libraries.

              1. 1

                I recently wrote something in Python which called other tools and had to capture stdout. It was just inconvenient enough to not use Python for these kind of scripts. I think I had to manually split the tool name and it’s arguments or something like that. Not terrible, but it’s just easier in bash. (Sadly, most other things are terrible in bash).

                1. 1

                  I’m pretty sure one can make a nice interface for that for any language, it’s just that some come without it in their standard libraries.

                  No doubt this is true, but thinking about doing this in C as a for instance, executing commands and checking return codes is trivial, but what if you need to watch the output and look for a certain string? Or build a pipe and ensure that any component fails the entire pipeline? All of this is possible in C but arguably not easy.

              2. 3

                Not to mention that “plain text” executables are much easier to maintain (along space (other devs) and time) than binary blobs.

                1. 3

                  Agreed. Would one be mistaken in thinking it a good idea to keep POSIX standards in mind if going down this route?

                  1. 2

                    Writing a shell script is way more convenient than writing it all in e.g.: Java. If you use Shellcheck and adhere to the POSIX standards there shouldn’t be a lot of problems. Shell scripts can be of quality too.

                2. 3

                  I like this a lot on the designing systems part. But I have to say on the code part, a lot of things there that I used to believe and changed my mind. For instance:

                  In code, even the smallest details matter. This includes whitespace and layout!
                  

                  There’s a limited amount of effort a group will spend in achieving a common format, and it’s better to use those for what matters: big design, isolation of concerns, single responsibility of classes. Talking about the tiny details too much make people feel productive while writing bad code. The small details are pointless. A code where all variables are pluralized in the same way, all white spaces are organized, might make someone feel happy and bring some joy (?) But do not make better software. It might even be bad, because gives a false sense of organization.

                  1. 2

                    Reminds me of “Book of beliefs”

                    1. 1

                      -Wpedantic: Belief is a very strong word for this. I think these might be better called axioms over beliefs.

                      1. 4

                        I don’t like to use the word “axiom” outside of formal systems. “Belief” is a great word to call a statement one assumes to be true, without implying they are justified or not.

                        Axioms are always assumed to be true without justification.