I completely agree with this statement and made a similar realization as well. Basically, modern devops and application development boils down to writing Lisp in YAML.
Config languages for Ansible, K8S, etc.are just basically a bad implementation of a Lisp-ish language.
It’s not a lisp. It’s similar to s-expressions, but it is not lisp. It’s a tree based language and that’s the entire similarity. There is nothing else here that is reminiscent of lisp.
Well, Common Lisp isn’t opposed to it, it does have labels and gotos. But it’s not used in your average code (at least from what I’ve seen they’re typically constrained to code needing high performance or macros).
But this is missing some of the key things of lisps. It’s not homoiconic (it’s a tree-based syntax, yes, but with no tree structure unless you count nested arrays). There are no closures or lambdas. You can’t pass steps/sub-workflows around as parameters to variables (at least not what is shown) so you can’t do something like:
I mean, that’d be a basic element for passing function-like things around and getting the functional capabilities of lisp and let you have higher-order functions.
This is a weird, basic, imperative language that’s aiming for deliberately limited capabilities. They seem to have chosen YAML only because it’s already used as a configuration language, but not because it actually provides any real value or novelty. We are very much approaching the 00s infatuation with XMLifying everything here.
Remember that you need something in addition to s-expressions to represent a dictionary. (There are multiple ways to do it but at the end of the day all you have are nestable lists.)
Config languages for Ansible, K8S, etc.are just basically a bad implementation of a Lisp-ish language.