Heh, glad to see it, was gonna post this.
Now you have it, do you want to use it. (bluff call time LOL).
Being a bit facetious, don't get too offended at the joke, people. But yeah, Xonsh is the "python(ish) shell" option if that's what you want.
Which works fine.....until it doesn't. Many non-trivial builds require custom logic, and trying to do that in maven was painful the last time I tried it.
If you have any complexity, programming against a good abstraction (Gradle is not good good, but decent) beats finding the magical incantation of configuration to get the tool to do what you want.
I think folks just get used to Maven-induced constraints (this applies to SBT, Bazel, others too). When you free yourself from that you realize: builds just aren't all that hard, it's often the tooling that becomes a real limitation.
Of course, sometimes the limitations are good: preventing you from doing "the wrong thing", or encouraging cacheability, etc. But as with any abstraction layer - getting a model that fits across so many disparate use cases can be very challenging.
That is why maven offers a plugin model for your custom logic that can be written in Java/Kotlin and a well defined lifecycle model where you can configure your plugin declaratively.
You can also download custom CLI tools and invoke them as part of a well-defined build lifecycle.
And then fail to do proper incremental builds, leaving you with no choice but a faulty build or clean installing on every occasion.
At the very least, I would move to Gradle which does have proper knowledge of your build graph. But Mill is also a good choice and fills the same niche, with the added benefit that imperative-looking ordinary scala code will simply become a parallelizable, cacheable build graph.
"Do One Thing" is to me maybe best understood in the context of the Single Layer Of Abstraction Principal - it has helped me numerous times to be very intentional about following SLAP in complex code, and Do One Thing seems to fall very naturally out of it.
Greg Smith wrote a book about postgres high performance that does go into the internals a bit and how to analyze performance problems. If you want to be a DBA, this will probably wind up needing to be in your back pocket at some point.
