It’s possible, and very easy, to generate yaml with a bunch of for-loops and side-effects in an imperative language.

So without knowing anything about cdk, even if it is declarative, I don’t think your conclusion is applicable.

Terraform, the language, works differently. While it has variables, you can not store state in variables and depend on side effects based on the order you read/write such variables. Every assignment and execution order of resources is purely based on dependency order and not based on the order of the lines in your code.

Terraform is not a language. HCL could be considered a language, but really requires the additional context of the Terraform resource model and the individual schema pertaining to the resources under management to decode. It populates an internal resource model, before changes are effected by the Terraform core engine.

One can configure the self same resource model using JSON, which can be trivially generated - as you correctly point out - using whatever language and paradigm you like.

However, since the language doing the generation does not influence the order of operations when applying the effects, the model is declarative. This is identical to the CDK configuring the CloudFormation engine via YAML. Indeed, there is a CDK for Terraform too...

Inbetween using CDK and generating CF Template you can be very “creative”, thats where the imperative part lies.

I think there's a much stronger argument that cloudformation deploying your stacks gets to being imperative than the way you produce your cloudformation file.

The file is still declarative regardless, and the functions you write to create that file don't per se have side effects outside that file