> Consider GitHub Actions. How much better off would we be if, instead of writing the workflow-job-step tree by hand, we could just have a single Python script, executed on push, whose output is the GitHub Actions YAML-as-assembly?
github-workflows-kt[0] is a tool for generating GitHub Actions workflow YAML files in a type-safe script, helping you to build robust workflows for your GitHub projects without mistakes, with pleasure, in Kotlin.
Two thoughts this sparked, somewhat in tension with each other:
The HTML→React evolution is a good parallel. Writing long-term maintainable markup without loops, reuse, and parameterization became untenable at scale. React (and similar) emerged precisely because "data" (HTML) needed to become "code." Not everyone loves frameworks, but clearly many developers found the abstraction ceiling of pure markup too low.
That said, declarativity has real advantages — mostly around security and sandboxing. CloudFormation is instructive: CDK eventually outputs CloudFormation YAML. AWS could let you run arbitrary code inside CloudFormation, but they don't — because if you can send code there, you can also make it mine bitcoin. The declarative layer is the trust boundary.
So maybe the sweet spot is code-that-emits-data. You get loops, abstraction, and type safety at authoring time, but the execution environment only sees the constrained, analyzable output. CDK got this right. The problem is when systems skip the "emit data" step and try to grow a DSL organically inside YAML.
> Consider GitHub Actions. How much better off would we be if, instead of writing the workflow-job-step tree by hand, we could just have a single Python script, executed on push, whose output is the GitHub Actions YAML-as-assembly?
github-workflows-kt[0] is a tool for generating GitHub Actions workflow YAML files in a type-safe script, helping you to build robust workflows for your GitHub projects without mistakes, with pleasure, in Kotlin.
[0] https://typesafegithub.github.io/github-workflows-kt/
> I wish I could, instead, write a make.py file with something like this:
I have had in mind a project which I hope could make this more ergonomic. I think the example could look more like so (and be made to work):
Two thoughts this sparked, somewhat in tension with each other:
The HTML→React evolution is a good parallel. Writing long-term maintainable markup without loops, reuse, and parameterization became untenable at scale. React (and similar) emerged precisely because "data" (HTML) needed to become "code." Not everyone loves frameworks, but clearly many developers found the abstraction ceiling of pure markup too low.
That said, declarativity has real advantages — mostly around security and sandboxing. CloudFormation is instructive: CDK eventually outputs CloudFormation YAML. AWS could let you run arbitrary code inside CloudFormation, but they don't — because if you can send code there, you can also make it mine bitcoin. The declarative layer is the trust boundary.
So maybe the sweet spot is code-that-emits-data. You get loops, abstraction, and type safety at authoring time, but the execution environment only sees the constrained, analyzable output. CDK got this right. The problem is when systems skip the "emit data" step and try to grow a DSL organically inside YAML.