There's plenty of improvement to be had while still keeping it declarative.

Is there a formal specification of what “what” and “how” means in this context? I’m familiar with your description, but it appears subjective to me because the phrases “what the output should be” and “how to generate the output” are poorly defined.

I consider SQL imperative. You say exactly how to do what you want, not what do you want.

If we take as example a table with a single row:

In imperative (SQL):

INSERT INTO TABLE1 (name, wage) VALUES ('John','50k');

Then one day John gets a raise:

UPDATE TABLE TABLE1 SET wage = '60k' where name = 'John'

In declarative (pseudo code in yaml):

- table: TABLE1 - name: John wage: 50k

Then one day John gets a raise:

- table: TABLE1

  - name: John

    wage: 60k

It's sort of a weird hybrid monster really, some times it's the worst of both worlds.

You state what you want, yes - but you are forced to articulate it as a specific set of table navigations / logistics through the relational model, as if you were writing the implementation. Then, however, the database then may choose ignore those and do something else to resolve the data you asked for if it wants, if it can prove the outcome is equivalent.

For example I want all the ice creams bought by John. Even though the schema knows the foreign key relationship between "user" and "purchase" I have to tell it back to the database engine in my query. But even after doing that there's no requirement the database will actually implement the steps I was forced so ungraciously to specify. It may "optimise" them away and do something else.

You’re describing to the RDBMS what you wanted added to the database. The SQL/RDBMS takes care of how that’s done.

In C, you’d have to program how the data should be stored (data structure) and written to disk.

> In C, you’d have to program how the data should be stored (data structure) and written to disk.

Just like declaring the columns you're specifying values for and then the values for them?

If SQL was declarative, you wouldn't have an error on duplicate CREATE, there would be no CREATE OR REPLACE, and changing column types would not be an error. It would just 'table x should be like this, make it so'.

(Actual queries/projections I would say are declarative, just the nomenclature pretends they're not. (Select from join all sounds very imperative, but really you're just describing what you want, and have no say over how it's retrieved.))

You might notice that the only way to create a declarative language is to use an Imperative language.

Declarative languages are basically a DSL, which (hopefully) translate the desired steps into efficient instructions. Nonetheless, your cpu will execute imperative code at the end.

SQL is an example of a very well established and generally well done declarative language, but that doesn't mean that declarative languages are inherently better.

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.

Which compiles it to bytecode, which is Imperatively executed on your cpu.

You didn't think that one through, did ya?

I'm not even sure where your outage comes from. DSLs aren't inherently bad either.

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.