5 ms·

Declarative vs Imperative Language. A huge benefit of SQL is that it's a declarative language (you describe what the output should be); whereas with imperative

Declarative vs Imperative Language. A huge benefit of SQL is that it's a declarative language (you describe what the output should be); whereas with imperative languages like C/Python/Ruby you have to describe how to generate the output with specific instructions and procedures.

jooz 4y ago
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
- tiffanyh 4y ago
  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.
  - OJFord 4y ago
    > 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.))
- zmmmmm 4y ago
  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.
runeks 4y ago
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.
411111111111111 4y ago
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.
- daxvena 4y ago
  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.
- 0xbadcafebee 4y ago
  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.
  - mirekrusin 4y ago
    ...and you have nice imperative race condition right there in your simple example.
    - 0xbadcafebee 4y ago
      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.
jayd16 4y ago
There's plenty of improvement to be had while still keeping it declarative.

jooz 4y ago

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

tiffanyh 4y ago
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.
- OJFord 4y ago
  > 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.))
zmmmmm 4y ago
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.

runeks 4y ago

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.

411111111111111 4y ago

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.

daxvena 4y ago
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.
0xbadcafebee 4y ago
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.
- mirekrusin 4y ago
  ...and you have nice imperative race condition right there in your simple example.
  - 0xbadcafebee 4y ago
    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.

jayd16 4y ago

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