>I think the author is using "functional" in a different sense from its usual use nowadays. Basically I think he just means that with SQL, you focus on the operations you're performing (i.e., functions), and the functions are only loosely coupled to the actual data, since you can write many different functions (SQL statements) on the same database, and the same SQL statement can be applied to many different databases with different underlying storage architectures
Huh? To me, "declarative" means focusing on just stating what you want the result to look like, not what operations need to be performed to obtain the result. I agree that SQL could be considered declarative as well as functional, since an SQL statement has aspects of both. But I don't see how "focus on the operations" is declarative.
>To me, "declarative" means focusing on just stating what you want the result to look like, not what operations need to be performed to obtain the result
And that's exactly what SQL does.
You specify what the result should be like "I want the result to have those two sets common elements, but only items where this column is larger than 10, and I want it grouped by these 2 columns and ordered by this over column", and now how to get to it (e.g. open these files, read those indexes, load a hash table with matches, iterate over them to find those where column > 10 etc).
GROUP BY x and WHERE X > 10, etc. are not "the operations performed to obtain the result", are high level descriptions of the result we want.
In fact in CS courses, SQL was one of the canonical examples of declarative programming (despite some nits to the premise, e.g. the ability to specify use of indexes etc).
So an SQL UPDATE statement is purely declarative? "Update" sure looks like an operation to me. Similar remarks would apply to DELETE or INSERT.
For queries, I can see your point of view, yes; but even for queries, SELECT, GROUP BY, etc. can be viewed as operations just as well as descriptions of the result set. (WHERE, I agree, doesn't really look like an operation.)
> GROUP BY x and WHERE X > 10, etc. are not "the operations performed to obtain the result", are high level descriptions of the result we want.
Again, I think this is a matter of point of view. GROUP BY isn't a low-level operation, sure; but that doesn't mean it's not an operation, or can't be viewed as one. High-level operations are still operations.
> in CS courses, SQL was one of the canonical examples of declarative programming
I'm not trying to dispute this. I'm saying that given how the author of the article is using the term "functional", it seems to me that SQL could be considered "functional". But I've already noted that the way the author of the article is using the term "functional" is probably not the way that term is commonly used.
>So an SQL UPDATE statement is purely declarative? "Update" sure looks like an operation to me
The Update statement tells "set this column to this value". It's totally a declaration of intent.
It doesn't specify anything about how the update is going to happen behind the scenes (open this file, use this tree structure, traverse, find the nth entry, write this value to the disk, and so on).
(Databases also support PL/SQL which is more imperative in nature, but here we're talking about SQL the query language).
>but that doesn't mean it's not an operation, or can't be viewed as one. High-level operations are still operations.
Operation in the context of declarative vs non declarative is not about high vs low, it is about whether the language has the user explicitly define control flow.
In the "group by" the user just tells to the DB that they want the results grouped, they don't specify any control flow, or tell how that grouping will happen.
I understand and agree with your comments about SQL the language, but would you consider an application consisting of stored procedures to be a functional program? That is, would you consider the result of a modularized SQL _system_ to be a functional system?
I find the FP vs OOP to be more of a discussion about "approach" more than anything else, where the language is more of an implementation detail. When understood like this, I don't think it's unreasonable to call SQL functional.
That's called "declarative" -- not "functional".