1. 40
  1.  

  2. 10

    I love text-file-driven applications! I irrationally use them wherever I can, even if a GUI would be easier/quicker. In particularly intense cases this drives me to write my own utility that is in fact text-file based (so happening right now with an RSS reader) Perhaps it’s Stockholm syndrome, perhaps it’s my desire to do as much as possible with Emacs, I love them all the same.

    I think the strongest point in favour of text-file driven modality that you didn’t mention is statelessness - GUIs often have a lot of hidden state that is stored somewhere that influences what happens. In text-file driven applications, all of the state is right there in your editor, making it a lot easier to reproduce and change things, and have those things work across machines and users.

    1. 3

      Yes! statelessness is very important. Thank you for pointing that out. I feel this most when making figures etc. Early on I was using Matlab, and I had this very manual GUI based layout flow, because Matlab made it easy to edit figures, but it was super annoying when I had to remake the figures. Then I discovered how to do most things programmatically.

    2. 7

      I still remember writing POVRay scripts and seeing the scenes render as if by magic.

      1. 6

        Indeed! As someone who used to dabble in POVRay a long time ago, I can relate to this. I have archived my POVRay learning journey here. Some of the scenes, especially the ones towards the end took hours to render. To see POVRay run as a CLI tool laboriously ray-tracing the scene and the rendered scene appearing after several hours indeed felt like magic!

        1. 5

          This writeup looks amazing. Perhaps combining povray with a templating language like PHP or jinja2 could be a fun project?

      2. 7

        I remember the first time I re-configured a Linux system by editing a text file, when doing the same task on Windows required clicking through a wizard. That was a big “aha!” moment for me.

        1. 7

          Glad to see someone mentioned GraphViz in the comments, that’d have been my first thought. Another neat one is mermaid for javascript diagrams.

          I was happy to find that there is a new modern package called TikZ that has taken up the baton

          TikZ is terrible but the least terrible drawing tool I’ve ever used. That’s generally true of everything in LaTeX: I despise beamer but despise it less than powerpoint or Google Slides.

          1. 6

            Another application like this is LilyPond for music engraving (typesetting).

            1. 2

              That’s cool! I see there are several VS Code plugins - might help in my quest to learn the piano!

            2. 5

              Markdown (when used with a Markdown compiler and web browser) also counts: it’s a text-file-driven word processor, like Microsoft Word. Markdown doesn’t have as many built-in functions as LaTeX, but if you embed HTML like <div class="note"> and add some CSS (which is also plain text) you can do a lot of the same things.

              1. 5

                OP talks about version control, but another great payoff of these systems is the ability to use their inputs as something else’s output.

                1. 3

                  Yes, very good! They can be programmatically driven, though this can get a bit insane. Sometimes, the original application has been wrapped as a library in, say, Python, to make this meta-programming a little easier. Say like Python and GraphViz.

                  1. 2

                    Or like in… Bourne Shell ;)

                2. 4

                  On the topic of this, someone on the orange site mentioned Ward Cunningham’s ski trip expense calculator, which is certainly text file driven!

                  https://c2.com/doc/expense/

                  1. 4

                    Every now and then I’ve used LTSpice (free to use, but not open source) to do circuit simulations for work projects (industrial control systems). I first learned the GUI during my studies. Not sure at exactly which point I found out that actually the graphical models are translated into text before they are fed to the simulator, but figuring this out opened quite a few possibilities.

                    Recently for a work project we had to figure out whether a particular circuit design would end up in an unsafe state as the result of a different fault modes/combinations of faults. The circuit was complex enough that it didn’t really yield to normal “stare at circuit diagram and think what could happen”-style FMEA. We ended up building fault simulations into the model and then adding parameters to switch different faults on and off. Because the whole model was just a single text file, it was then possible with simple search and replace-style script to change the parameters of the simulation. This allowed to programmatically simulate (you can call the simulator with a SPICE-netlist through the command line and it dumps the simulation results to a .raw-file, which is binary, but there are libraries to read it) through all the interesting fault modes, combinations of them and combinations with different circuit control states and for all the simulations dump the results into a bunch of figures and tables for easy analysis. We easily found a couple of unsafe fault modes which were very unintuitive and would not have been found without the simulation. Coding the whole thing initially took quite a few hours, but combined with a couple of circuit revisions ended up saving a lot of tedious manual work.

                    Of course similar things could be done with other simulators, but usually there’s some clunky API I would have to work through, with the text-based models creating own tools and scripts on top is rather nice.

                    In another case we were trying to simulate another circuit which used a couple of ICs. We found a SPICE-model for one of the ICs online, the model was dated to 1993. After only a minor modification it was possible to run it on the 2020 simulator, which is by itself quite a feat. It didn’t quite contain all the functions that the modern version of the IC had, but since it was text-based and not encrypted (like some manufacturers like to do), we were able to reverse engineer the model and found out you could simulate the modern version of the IC at least to some approximation by combining the building blocks provided by the 1993 library.

                    Had the model from 1993 been in a binary format for some GUI program, I doubt we could’ve ran it or figured out how to open the thing at all to be able to figure out what the thing was actually doing.

                    1. 4

                      To summarize, it sounds like LTSpice’s use of plain text files provided these benefits:

                      • Scriptability
                      • Forward compatibility
                      1. 1

                        Yes. I have a tendency to write too long-winded, thanks for the TL;DR. :)

                    2. 4

                      I wonder if many people here appreciate script driven applications like I do. I made a very short list (just 4) of applications I use via scripting that most “modern” users would think to use a point and click graphical user interface for. It would be cool if people could add their own favorite script driven application that, on the face of it, would be better driven via a graphical interface.

                      1. 1

                        I do want to mention DokuWiki, a PHP web app that uses plain text files instead of a database and works wonderfully, although this is probably not exactly what the author meant.