I think you're reading into something that isn't there. GP never said anything about declarative being better than imperative, merely that they are different approaches and SQL is declarative.

But even if they had, your argument that the CPU ends up running imperative code makes it better seems silly. The CPU ends up "running" machine code and a compiler has to turn the vast majority of imperative code into a different form. Does that make machine code better than assembly? better than C?

I don't think so. They are simply different levels of abstraction, each with their own pros and cons. Neither are "better" than the other. Each are "better" at some tasks and worse at others.

GP said there was a "benefit" with SQL being declarative, because when you want to abstractly request some arbitrarily structured data, it's beneficial in most cases to not have to know exactly how to find and retrieve that data. It's certainly not "better" if you need to ensure some specific bit format on the hard drive. But it's "better" if you want to succinctly express a query that is broadly reusable and understandable even to people who have no idea how the database works on the inside.

You're reading something into my comment I didn't want to say too

I just felt the need to point out that declarative languages are essentially always a DSL, wherever this DSL is actually performant and should be used depends on it's implementation.

Generally speaking, SQL is very well implemented so using any of the well established databases is probably a good choice. Nonetheless, few declarative languages come even close to SQLs efficient implementation so they're very rarely the answer.

There’s nothing stopping you from writing a compiler or interpreter in a non-imperative language like prolog.

Also performing the equivalent of a table join in a non-declarative query language is going to be a burdensome task. It’s certainly beneficial to let a query planner figure out the details for you, instead of iterating over all the rows of your data.

Design and analysis of hardware for high-performance Prolog

https://www.sciencedirect.com/science/article/pii/S074310669...

It means you can let the database engine determine the best way to get you what you are after. If you write imperative code, you are telling the DB exactly what to do and you don't really give it much ability to optimize your queries. Before SQL most DB engine queries were imperative and it was terrible... which is why we don't do it anymore.

People keep twisting themselves into knots trying to fit things into these labels, but the net effect is unrelated to the description.

Using a "declarative language":

  my_bucket = aws_s3_bucket(aws_region, bucket_name)

Using an "imperative language":

  if aws_s3_bucket.exists(aws_region, bucket_name):
    my_bucket = aws_s3_bucket.update(aws_region, bucket_name)
  else:
    my_bucket = aws_s3_bucket.create(aws_region, bucket_name)

I prefer the latter. In every DSL I've ever used, people end up needing to handle weird edge cases, and it's extremely hard to do that with a "declarative-only" DSL, so they end up adding imperative-ness to the DSL. Give me a regular "imperative" programming language and lots of convenience functions that do black magic behind the scenes, and I'll do regular programming when the black magic falls short.

This is basically why AWS CDK / Terraform CDK / Pulumi exist.

...and you have nice imperative race condition right there in your simple example.

bravo.

From a simplistic point of view, yes, but from a practical standpoint, no. IaC assumes a global lock on any resources being managed. As soon as that expectation is violated, everything starts breaking, regardless of how good the code is.

Furthermore, the only way to implement an imperative language is to use a declarative language.

Verilog and VDSL, you see, are declarative. They have to be.

It's not a better or worse thing. It's a domain thing.

Only if you limit yourself to current CPU architectures. Even GPUs right now are significantly more declarative than CPUs, and it definitely seems like some point in the future we could end up moving towards asynchronous circuits built with memristors.