> Although SQL is essentially a declarative language (4GL), it also includes procedural elements.
If SQL was a declarative language, there would not be expression in it, for example SELECT (1+2) , only SELECT 3
These categories based on the approach of the programming, not the underlying technology.
Imperative languages (high level): a step-by-step description of a process, like giving orders to someone/something in a sequence, organized further with loops and conditions.
Analogue: cooking recipe. Languages: C, Pascal, Basic, etc (they can be structured or object oriented, still imperative)
Functional language (not mathematical definition, forget stateless, non-mutable etc for a moment): It is an approach that solves the problem of cardinality of the imperative approach. There is nothing which is "one", only "one of them". It's a little bit confusing how i try to define this, but this is the most important aspect of this. We only filter and transform elements of a set, and even if this is nothing (for not mathematical aspect), but syntax sugar, it gives a programmer a safe way to do things, without caring about the details of enumerating things or null checks, etc. Or another angle: functional programming eliminates loops, and put the sequence in the data, and keep conditions. It is really handy to be honest. Purely functional languages are mostly experiments, because making something functional is kinda self-motivated, but other languages will pick up more functional elements in time, which is great.
Analogue: assembly line in a factory. Thing are coming, they are changed (like car body painted) or removed (like quality control). Languages: LINQ, SQL, F#
Declarative language: your approach here is instead of describing how to do something, you only describe what you want as a result. CSS is a perfect example, however it is picking up non-declarative elements nowadays, original it was only capable to describe how a font a paragraph look like. HTML is also declarative. Instead of actually drawing a rectangle, you just say, this width, height on this position, etc.
Analogue: you order a coffee in coffee shop. You don't care any of the details, just the parameters of the coffee you want to drink. Languages: HTML, CSS
Of course there are blurred lines like you can say all high level language are declarative, because you never go down to the hardware level to manually do everything, but I think what is important the approach, how you start to solve the problem, and if we see this from this point, SQL cannot be a declarative language. It was designed to be as close to English as possible to make non-IT people do programming, but it successfully failed it's purpose, because it is a pretty good language for programmers, but it was never designed to be declarative.
SQL is I think generally considered not entirely declarative, but that is not an example that shows that. Is there any declarative language that satisfies that, that has no addition (or operator? Or addition of constants? I'm not really clear what about it you think makes it not declarative?).
By this rule, Prolog and HCL/Terraform are not declarative either.
i give you other angles.
imperative has structures like: sequence (by code), loops and conditions
functional
** has no loop, the loop itself the cardinality, which is always multiple
** has no sequence, it's encoded by data (edit here, actually it has)
** has (of course) condition
So, by basically we redefine the fundamental elements of the imperative model
Purely declarative languages has no sequence/loop or conditions (in programming understanding)
Answering to you, HTML (especially earlier) is pretty close to purely declarative, i does not have loops or conditions, however, this is not 100% true, but close. I don't know those languages you mentioned, so i can not have an opinion about them
SQL fits this perfectly. For example JOINs don't describe actions, they describe relationships. Have you ever looked at what the query planners come up with to satisfy those relationships?
SQL does not fit my definition, because you reach your goals through multiple transformation and filtering, and this is how you reach your goal. you define the way, the process, not the end result. under there are some comments where i speak about this.
SQL is almost the _textbook definition_ of a declarative language.
It does not define the way. It defines the end result.
> This is the "texbook definition"
The textbook definition of gravity is F=Gx((M1xM2)/r2)
According to Newton's textbook. Ask today's physicists about this.
SQL describes WHAT data you want returned. A functional language describes HOW you retrieve that data.
SQL is a declarative DSL for set theory and data transformation. Also precisely why both OO and FP languages fail so miserably with database mapping libraries; the so-called impedance mismatch.
Declares this set joined with that set in this way, and then grab a subset where a condition is true, grouping them according to certain criteria, and putting them in order. All this despite partially being in memory, partly stored on disk, and indexing/performance being orthogonal to the syntax of the query language.
Show me a functional language for some data on disk, some in memory, with varying levels of indexing, and where accessing the information doesn't have any impact on the transformation API.
That textbook example was just about how our understanding improves over time, and how a textbook, or all of them is not absolute truth, and debatable, which is what I am doing exactly.
>SQL describes WHAT data you want returned. A functional language describes HOW you retrieve that data.
You need to phrase more precisely here, HOW and WHAT could be interpreted by your own way.
>SQL is a declarative DSL for set theory and data transformation.
Yes, exactly. Now think about lamdba expression added to a generic imperative languages. Isn't that doing the same thing? A set, transform and filter elements of the set like how you do it in SQL with record, but in this case with objects of classes? Are lamdba expressions functional or declarative? Is LINQ functional or declarative? If you say SQL is declarative, than those should be too, or am I wrong? Or LINQ is declarative, but lambda expressions are functional?
>Also precisely why both OO and FP languages fail
I disagree. OOP failed because most programmers did not understand it. I would argue if they are failed, but now I just go with your premise, and assume they are failing. I see the real reason behind this is multifaceted, and mostly coming from the stupidity of design patterns, software architects making too much money in big companies, so they have to deliver something, so creating overconvoluted abstractions, think about the java enterprise hell. Not understanding why restricting yourself as a programmer actually benefits you in the long term, and helps other people understand your sh*t, because it forces you to be more organized. But instead of this, we have classes with a million interface slapped on it. Just ask the average programmer what is a difference between an interface and an abstract class (or have they used it ever), maybe they gonna ask what is an abstract class.
Functional languages are not failing. Pure ones created for certain purposes, like experiment (proof of concept), scientific use, etc and their ideas make their way into all the popular imperative languages, like javascript or c#, where are really useful tools while not caring about the pristine philosophy behind them, just a really useful tool.
>database mapping libraries
I also would not bury them. I exactly know what are you speaking about when you mention "impedance mismatch". I actually wrote my own mapper, i dont dare showing the code to anyone, it's just a mess, and the performance is horrible, but instead "mapping out the database and showing them as object" I built it for forcing the OOP ideas into the database level, so you can have e.g. inheritance. And not how MS solved this in entity framework like by basically denormalizing the structure and smahing together the data, no, my code exactly knows which tables to go to put together one object, which can have multiple level of inheritance. I also introduced the OOP ideas of aggregates and composites, which is exactly my attempt to solve the impedance mismatch problem you mentioned before. Correct me if we don't speak about the same thing.
You speak about technical details of SQL server internal processes, I approach this question strictly from theoretical standpoint, analyzing the language itself, and categorizing them, without thinking of computers. The problem solving approach is my divide, not anything about implementation. I wrote about this a lot in other comments.