> That means they need to communicate with those programs primarily through the command line interface for invoking a program, which is a very thin bottleneck f

> That means they need to communicate with those programs primarily through the command line interface for invoking a program, which is a very thin bottleneck for interactive feedback. On the off chance you, or other readers, were not aware, Tcl drives the most famous example of that use case that I know of: https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index While trying to dig up the repo for it, I came across https://github.com/Netflix/go-expect#osexec-example https://github.com/Netflix/go-expect#osexec-example which really highlights your point about "wowzers, what a lot of boilerplate to communicate with a subprocess". I had to deal with a few projects where folks thought that using Python as a "better bash" was a good thing to do, and it, too, was horrific, made worse by the fact that poor subprocess.Popen doesn't have a raise_for_status() equivalent to have it STOP RUNNING if something goes wrong, cheerfully leading to a cascade of errors that is far less likely to happen in bash or likely in Expect, either