What do others think of "SQL as a very functional language?"
The insight that businesses decouple data from procedures is right. But SQL has poor support for functional hallmarks such as recursion, functions as first-class values, etc. SQL is not functional but declarative: it's less Haskell and more Prolog.
> What do others think of "SQL as a very functional language?"
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. But of course, as you note, SQL being "functional" in this sense does not mean it supports more recent features associated with functional programming.
The idea of functional programming is much older than this article. I learned the principles of functional programming in the 90s at San Francisco State University, on a language actually called "FP"[1]. Similarly, SQL has been known as a logic/declarative language since it's start and these two paradigms have been known to be different for a long time. I don't think you can get away from a situation where the author is abusing the concept and terminology.
Edit: the argument seems especially galling given that logic languages seldom get credit as "industrial strength" and functional programming has a huge following of "language geeks" when a logic programming language is what works-with a broad swath of regular languages.
>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.
In my opinion, SQL is a good mixture of DSL/Declarative & Functional paradigms. It enables programmers to specify operations to perform without worrying about the 'How'.
I completely lost him at that point. Like you said, SQL is more like prolog. To boot, it's a language designed to mutate data, using a sequence of commands. Not very functional in my mind. I think the whole article suffers from a poorly defined notion of what functional exactly means, and what OOP exactly means, and I think the next step would be to stop thinking in terms of OOP and functional because most industry languages tend to blend elements of both now, so it is better to break it down into the features that you find useful and analyze them one by one such as, can functions be values, is there immutability support, pattern matching, types of polymorphism, generic data, etc etc
The insight that businesses decouple data from procedures is right. But SQL has poor support for functional hallmarks such as recursion, functions as first-class values, etc. SQL is not functional but declarative: it's less Haskell and more Prolog.