I don’t view this ratio as a better/worse thing. Config as code it a good practice already, and once you have that, it’s moving complexity, not creating it.https://twitter.com/springrod/status/1002379190174302208 …
In my ideal world there is only application code. Tooling can staticly analyze (or run) that code and output a set of isolated functions and a declarative infra plan.
-
-
In my ideal world, application code approaches zero, and there's only configuration.
-
k - for extracted infra plan I'd be concerned that "annotations" of some form would be required to provide service-specific params. For config-only, do you imagine that's the representation people would edit (eg: XProc/XSLT style)?
-
Isn't java era XML config hell what we are all running away from? that was before my time so I really don't know for sure.
-
Yes - there was a "XML all the thingz" movement that seemed to punt intrinsic application awareness to a runtime, external "config problem".
-
I would like some resource to learn about dev from ~90's into early 00's. So much of what we do seems to be reactive to practices of that era. I wish I could connect the dots better.
-
History is definitely path-dependent. We're often stuck with suboptimal solutions. At best, we learn to accept it and work with it. At worst, we convince ourselves it's actually the best of all options.
End of conversation
New conversation -
-
-
JS would be nice for adoption and partiy with front end. But its possible a different language will be required. Something that better understands all this natively.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.