"I don't have a clue how one would be able to build a gui with it, or how one can easily interact with a database."
Because SQL is functional programming. Functional programming doesn't just mean Haskell, it also means Microsoft Excel (which, I've been told, is the most used programming platform in existence).
I disagree. SQL, by definition, is natively nonfunctional. The concept of a database requires state. However, you can write functional-esque (monadic) layers on top of SQL.
Excel is basically a wrapper around spaghetti code. It's great for small presentations, but using it for real programming is incredibly risky. There are an enormous number of stories floating out there about business apps written in Excel that turned out to have subtle but sometimes disastrous bugs due to random human errors as well as poor maintenance when the "program" changed hands.
If you don't use UPDATE or DELETE, then you're treating SQL as a static-single-assignment language.
This is pretty much what I do at work; we have massive quantities of geographic and linguistic data that we have to translate to [REDACTED], and we do this by uploading it all into PostgreSQL and then running through a long sequence of "CREATE TABLE foo AS SELECT hairy_expression FROM bar;" statements.
I think I see your point, but is "natively nonfunctional" how you would describe lisp? There's not really any difference. One is binary relations and one is set relations.
"I don't have a clue how one would be able to build a gui with it, or how one can easily interact with a database."
Because SQL is functional programming. Functional programming doesn't just mean Haskell, it also means Microsoft Excel (which, I've been told, is the most used programming platform in existence).