[adrian_b]

DROP TABLE ?

Most of SQL is not imperative, but it certainly also includes some imperative commands.

Inserting a new row into an existing table is an imperative command, which may be the most frequently used of the SQL features, in certain applications concerned with recording transactions.

Only the subset of SQL that is used for queries can be said to not be an imperative programming language.

[da_chicken]

No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless.

Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.

[adrian_b]

Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.

  printf("Hello world!");

also does not tell anything to the system about how to accomplish this.

Anyone who claims that an SQL command like insert a row, create a table or destroy a table is not imperative, is just plainly wrong.

Even in real life, when humans communicate commands to each other, from where the term "imperative" comes, the commands normally do not tell anything to the recipient about how to accomplish the order, they just name the action, because it is supposed that whoever receives the command knows how to do it.

After programming languages were invented there was a clear partition between commands a.k.a. imperative statements, expressions and definitions a.k.a. declarations ("definition" and "declaration" were originally synonymous terms, "declaration" being the ALGOL 60 term and "definition" being the CPL term; the use of the 2 words with different meanings, like in C, where it is required by a defect of the compiler, which needs additional declarations besides a definition, is only recent.)

Later the meanings of these terms have become muddled by their careless use by many authors, which usually had political reasons, i.e. because they somehow considered the words "imperative" or "command" as shameful, they attempted to present their pet languages as purely functional or purely declarative, so they twisted the words in various ways, despite the fact that any practical program must contain imperative parts, not only functional or declarative parts.

[da_chicken]

> Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.

No. That's more to do with imperative vs functional programming, which is a subset of declarative, but even then you can't simply say "I changed state so it's imperative." That's a drastic oversimplification. That's like saying Haskell can't write to a file, which is plainly false. Declarative (functional) can absolutely change the state of the system. It just doesn't let you do it except by calling fixed commands, which is exactly what `INSERT` is.

When we're talking about imperative vs declarative, state can still be manipulated in both, but it's abstracted away with declarative programming. Like, a `filter()` or a `map()` transform in JavaScript is declarative programming, even in an otherwise imperative language. That's why it returns a new object with an updated state.

[cmrdporcupine]

This just exposes how weak this definition of declarative is, I think. Or how it's carrying two meanings here.

What you're really talking about is one of the things Codd wanted to emphasize: representational independence. Which actually was the primary thrust of his famous paper: the user should not need to know how the data is stored in order to use or manipulate it.

The other thing that people are talking about with "declarative" is probably another level up in abstraction. Talking about the business logic or problem in terms that are closer to logic than a sequence of instructions, and then letting the machine sort out what those steps are.

Consider in a Datalog users don't customarily perform DDL type operations; they declare data rules and the system decides the form of the underlying relations. That's a small step up the declarative ladder from SQL, even if it's somewhat analogous to "create view".

So I think there's a blurry definitional line between the two. But I don't think your very blunt "No." is doing much to help clear that up?

[da_chicken]

I would say it exposes how imperative programming was forced to adopt declarative/functional paradigms in order to write things concisely, to the extent that nobody thinks those elements are declarative/functional anymore.

[FrustratedMonky]

"how to accomplish the thing."

I always thought this was splitting hairs.

C#,C++, Java seems imperative. You are in control? But you aren't really telling it how to move values between registers, the compiler is making a million decisions for you on how the computer will execute that 'imperative' code. Just like SQL isn't really telling the DB how to do it either..

[cmrdporcupine]

It's really a matter of degrees though. You're waving away a big part of the big sell of a relational database as proposed by Codd, which is that the user need not "know" the structure of the data in order to formulate operations on it because there's a consistent set-oriented model that can be used with a bunch of different physical storage forms but also the very sequence of relational operations against it can be re-ordered / restructured without the user knowing. And that the same data can be accessed in N number of ways that don't require changing the underlying storage. In theory. In practice SQL databases are only sort-of there.

Contrast that if I create a class/object/field structure/hierarchy in Java, or put a HashMap somewhere with a certain set of keys, I've written something in stone which requires significant refactoring if the data needs to be accessed from a different direction.

[thesz]

Imperative languages such as C/C++ specify "microtransactions" - an ordering over memory accesses (including (de)allocations) within some statement or group of statements.

Compilers are free to rearrange these accesses if the final result is same as if executed by these ordered microtransactions.

Consider loop fusion, loop splitting and/or loop skewing.