SQL is not a declarative language. It is a functional language, and structured language on the top as extensions. HTML is a declarative language.
SQL is far and away understood as a declarative language for what data you want out of a relational database. I challenge you to find any literature that does not describe it as a declarative language.
Now, can we munge definitions and pull in an odd true scotsman argument about it not being a "true declarative" language? I mean, yeah. But, this is like arguing that LISP is not a functional language by some specific modern view of that term. Certainly true, but far from useful. And almost certainly not what anyone you would talk to expects from those terms.
"That is, it is not generating anything." if you speak about code generation like code behind in VS, it has nothing do with the paradigm. If you speak about underlying technology, it does not matter. In case of declarative languages, the framework determines what the language is capable of. And that's the point of them, they are generalizing the solution for common problems. The browser do a lot of things in the background when it draws a rectangle the same way how SQL server is doing a lot things when you execute a query, but these things have nothing to do with programming paradigm, which can be understood without computers.
Imperative: cooking recipe
Functional: assembly line in a factory
Declarative: your assistant
(compare the real world examples to the things i mentioned)
> SQL is far and away understood as a declarative language for what data you want out of a relational database. I challenge you to find any literature that does not describe it as a declarative language.
Ok, and I challenge you to compare HTML and SQL. Are they the same by nature. Are the steps, the approach of problem solving is the same? Because if SQL is declarative, than it is really similar to HTML
> Now, can we munge definitions and pull in an odd true scotsman argument about it not being a "true declarative" language? I mean, yeah. But, this is like arguing that LISP is not a functional language by some specific modern view of that term. Certainly true, but far from useful. And almost certainly not what anyone you would talk to expects from those terms.
We are speaking about semantics and taxonomy here. These kind of a questions are always debatable, so i can't really say anything about this, because you are speaking of ways of discussion. What i'm saying that my taxonomy makes the most sense to me, and if someone truly can challenge it, it's gonna make my mind change, but "literature mentions it somehow else" is not an argument makes me change my mind.
And again, I get where you are wanting to go. But you are literally arguing against all literature on sql. And your definition of declarative is restricted to only markup languages, evidently. Prolog would also not be declarative, by this view. Which is akin to arguing lisp is not functional. Technically true. The least useful way of being true.
If you want to know why sql is declarative, consider, how is a join performed? Table scan, hash join, merge? Yes, there are many ways to poke at the query plan, but that is like claiming c is assembly because there are extensions.
Even for the ddl statements, how is an insert actually performed into the backing store? When you create an index, what is created? How is the data copied to it? How is the data stored at all? Btree? Something else?
But I compare SQL and HTML for you. In both cases you are creating a text/a script in order to achieve something. The way how you achieve this can be really different in HTML and SQL. You can create a chess algo in SQL, but you cannot in HTML (purely), because in case of declarative language the framework around it strongly limits what the language could do. How would you explain this, if SQL and HTML are the same by nature? Focus on the text you write, because that is your product. Where is a condition is HTML, and why there is not?
Bitmap (like all data: xml, csv, whatever) is not a language in a classical understanding, but if you wanna make it, yes, they are purely declarative.
"It is not a declaration of what you want, but is a definition of what you have" Nope, i can define this without having a computer:
imperative: cooking recipe
functional: assembly line in a factory
declarative: your assistant. or let's make SQL declarative: you ask chatgpt to write a query, and define this query in english
"declarative is restricted to only markup languages" no, the form of the language is irrelevant. CSS is not markup, but still declarative.
Elements of languages cannot be declarative or not, you can only describe the entire language as such, because we are speaking about programming paradigms.
C is assembly at the end of the day, as everything else for the computer itself, but this is irrelevant here. From purely imperative, which is basically machine code to purely declarative (maybe chatgpt?) it's a scale, you put everything somewhere. Functional programming is syntax sugar over iterative, but it's really important one, as it changes how your mind try to solve problems. So basically what I'm saying everything is an abstraction over another one, down below the machine code, but this is just how thing works, not how you use your brain to solve things. I'm saying all this, because not the technical details, the implementations behind is the point when we speak about a purely theoretical classification which programming paradigm is.
Worse than just ignoring the entire field. You are caught up in a strict taxonomy that just doesn't work. Cooking recipes are, amusingly, mixed. They are a declaration of all ingredients and supplies you will need, with an often hybrid list of instructions on how to mix them. Would I declare them as fully declarative? No, but nor would I declare that they are imperative only. That is a part.
And again, your definition of functional versus imperative versus declarative will get you in some amusing historical binds. With how strict you are trying to be, literally no programming language is declarative. Even haskel has do notation.
Please give some effort to understand why so many people are telling you you are wrong. You are not wrong, in that if you expand the concept of SQL to everything that is possible with the language today, there are concepts that are not declarative in it. You are sadly misguided in thinking that makes your point. Would be like my sneaking in the "script" tag to laugh at how HTML is not declarative. It is a markup language, not a programming one. And people have done a lot to add to it so that it can do more than it originally could. Often out of necessity to get stuff done.
But if you want: In the recipe the ingredients can be "int y;", like declaration, or something else like malloc() Stating that i will need something is not declarative programming. Declarative is defining the end result. So none of the ingredients or the declaration are declarative programming (if you want to turn recipe to declarative, you go to a restaurant), but as i told, you can't do this with elements of languages, it just does not make sense.
In practice language paradigms can overlap related to concrete products. You can use (and actually should) c# for functional programming, but that does not make the language functional, the fundamental design is imperative. In the future, everything will be declarative (chatgpt is the first glimpse), so in some way we're just wasting our time here. Also, speaking about AI, model training does not fit any of the current paradigms, it's gonna be a new one, and maybe the only one, who knows...
SQL: describing the subsets of related data you want and not caring if that data is on disk, in memory, indexed, located on another server, or calculated on the fly. The engine (wait staff and cooks) figure out the "how" and return what you've ordered/queried.
Ergo SQL is a declarative language.
Functional: being multiple line cooks, the food is transformed step by step by different cook, they do the same thing on multiple half-ready dishes.
Declarative: giving your order to the waiter and having the food returned to you fully prepared <-your definition BUT you need to have a restaurant to do this, for other cases, not necessarily (you can line cook at home if you really want...)
SQL: getting elements of the a set and by DOING different kind of transformations (line cooks) and removing some plates (a guy standing there and if he sees a plate, which is a different dish, he tossed it to the trash). The end result is the set of data you want.
Ergo SQL is a functional language.
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.
SQL : CSV :: GraphQL : JSON :: React : HTMLSELECT CASE WHEN employee.type = 'contract' THEN salary CASE WHEN employee.type = 'full-time' THEN salary + benefit_costs END CASE FROM employee
Tell me how is this declarative?
-SQL is functional -CSV is not a language, it's a data format -GraphQL, im not familiar -JSON is literally executable javascript code, arguable -React is a javascript framework, binding is a declarative nature (if it has it, i dont know it too well), but it is not a language, it's a framework -HTML is absolutely, 100% declarative, yes
when you create html, you dont care how the rectangle is drawn, you focus on defining the result itself.
if sql was declarative, than the code of the SQL above would be: GIVE ME ALL THE COST OF THE EMPLOYEES --, I DONT CARE ABOUT THE DETAILS
the details, which in this example the difference between fulltime/contract employees would be handled by the framework (SQL server) which would already has a concept of two kind of employee like in HTML can have rounded tips of rectangle or angular tips, because the framework already understand these ideas
an SQL query itself (if no structured language used) is just a big function applied on a set. It has never have a concept of the things you do, like building an accounting solution to a company. HTML has the concept of paragraphs, button, etc etc, all the things you wanna do. but with SQL you step by step define what you want by conditions and transformations.
or another way to separate them -imperative is a combination of -sequence/condition/loop
-function -no loop (cardinality is always multiple) -sequences is encoded as data -conditions <- yes it has conditions
This is exactly what SQL is. There are exceptions, but they're exceptions.
> an SQL query itself (if no structured language used) is just a big function applied on a set.
I don't think you have a correct model of SQL. SQL is a language that expresses definitions, not functions. It is absolutely declarative.
Some extensions of SQL can provide functional capabilities, yes, but they are exceptional.
no, i meant the query is literally this: GIVE ME ALL THE COST OF THE EMPLOYEES
or if we want to formalize more: ALL COST OF ALL EMPLOYEES
the point here that in a declarative mindset EMPLOYEE is a word that SQL server understands, like HTML understand paragraph <p> or table with rows and cells <table><tr><td>
>I don't think you have a correct model of SQL. SQL is a language that expresses definitions, not functions. It is absolutely declarative.
that just not true. without defining the how through transformations and conditions, the only thing you get out of the sql server is a table how it is stored. until you reach a certain complexity you are true, it can be seen as declarative, but my point here, is the approach of problem solving is the separation here. you dont even have to speak about computers:
cooking recipe VS assembly lines in factories VS a robot with ai, which can do whatever is programmed to, but in certain cases work out the details by itself when not given specifically (not the best example, but started to get exhausted)
Also how would you say that by nature HTML and SQL is the same?
I dont think html is anything like sql (only in the sense that all markup languages are also declarative) but a comprable situation would be if you were trying to render some ascii art in html and had to use pre tags in order to tell the layout engine how to show it.
You are describe here the abstraction you create on a primitive (related to the system you design) system, and introduce ideas like "employee" "unions" etc If you do good job, when you programming you combine generic purpose systems and introducing new ideas in a way that another human can understand (words), but in certain way you "made the computer system understand" those things too. That's your job. So basically you teach SQL server that a union employee is a thing with the dbo.IsEmployeeUnion function.
In case of html you are not introducing new things. You actually can, because the browser is really flexible (like i make a non-functional quasi elements a lot, to make the html code itself more understandable), but HTML is not designed for you to introduce new elements/ideas (originally, nowadays kinda with CSS). Anyways this is how you see the difference in another way.
I try to tell all of you how the technical details, the implementation does not matter, only just the language itself, when we speak about paradigms, but it seems i'm failing.
By the way, i think training AI models does not fit to any of the paradigms we have here, it's gonna be (or it is?) a new way to solve problems, and that also has nothing to do with files, or any kind of implementation. The important is what you see on the screen, and what you do.
<script> is Javascript, not html (I mean what's inside), they just smashed together.
>specifies an specific output
That specific output definition is really different.
Consider this:
-task: give me even numbers
-imperative approach:
for i=1 to 100
result += i * 2
-functional approach
return [1,2,3,...].select(x=x * 2)
-declarative approach (not possible, but for the sake of example)
EVEN NUMBERS = NUMBERS LIKE 2,4,6 AND CARRY ON <-this requires a framework, which understand every word i wrote there.
What i wanna ask you to re-explain these examples with your understanding of classification, but using the same task.
>Reality is that declarative languages would be little more than file formats without access to computation.
That what HTML is. A declarative language and a file which requires a framework.
> Your earlier example of SELECT (1+3); is something that can be done in HTML (many different ways), too.
No, not with strictly sticking to the standard and not use any trickery. HTML was not designed to do any kind of calculation. That's why javascript came later.
I thought you would go here, and I understand where you are coming from: Declarative language != file format and declarative is not a paradigm like functional, procedural, object-oriented.
Every useful declarative language allows for some level of computation. Take a template language - YAML + some template tags. Aside allowing variable substitution, every time, the language grows a way to make those substitutions more useful, so you get things like:
{{ variable_containing_a_date + interval(days=1) }}
Back to functional, oo, procedural: some declarative languages import a paradigm.
Back to the script tag:
Even though it was added after the original spec, <script> is part of the standard for HTML and is one of the reasons it pushed many other formats to the side and the web won. I would submit that HTML+JavaScript is the platform, not just HMTL. One can write declarative code in an imperative language, and the reverse is true.
I do really appreciate you thinking on this, but I think we're best to use the existing definition and example of declarative languages, and not just banish declarative to static file formats.
That's right, in practice everything is more like a mishmash of everything. Your function library could be seen as a declarative language over the top of a generic language.
I agree, and will die on this hill :-)
A "case" statement in SQL (or an "iif") is still declarative, how else would you express specific cases when necessary?
iif and case by itself is not declarative or imperative. only an entire language can be described as such
Imperative programming: really detailed cooking recipe
Functional programming: assembly line of a car factory
Declarative programming: a robot what can do what is programmed for, and sometimes can work with really unspecific instructions (like this one line in a file "Hello world" is not a valid HTML, but the browser still renders it)
"functional programming, but that doesn't change the fact that SQL is a declarative language for describing recordsets"
ok, im describing recordsets for you: this set has 4223 records. I'm thinking of something else, but i can't really describe a recordset with anything else. Describing is not what you do when you create a software. You have a problem and you literally write a solution like an author write a book. And as you said, with SQL, you use a functional approach, how you do it when you use lambda or LINQ. Therefore SQL is functional.
SQL is turing complete with the structured extensions, so in that way can be general purpose, but something is general purpose or not does not decide the paradigm. Usually languages are more restrictive moving to the declarative side of things, but that is by design. The point is that you write less text.
On the other hand, the details of query execution are left to the planner and optimizer.
What's the case that it's functional, but not declarative?
Supposedly, “every high level language is declarative”.
It’s an opinion I suppose, but I doubt it’s one you’re going to find much support for. What I think this feels like to most people is that things aren’t what people think they are because you’ve decided to reimagine the commonly used definitions of the words used to describe those things.
Not sure if it’s a straw man exactly, but I feel like I’m in a straw man’s garden.
But this is not my angle, i say the borders drawn up by the way how you, as a programmer, approach solving a problem. My take is declarative when you define the *end result* you want to get. You certainly don't do this with SQL, because that case the your product (what you write in the query) would be the end result set, the data itself. Of course in case of HTML you don't literally draw in the rectangle in the code, but you describe the end result. This is the difference.
Other arguments you wrote is out of scope for me regarding this conversation.
You don't literally draw a rectangle with HTML, but you also don't tell the database's query planner how to do its job.
You're also not comparing things on equal terms. HTML isn't any kind of programming or scripting language.
If I understand you correctly, SQL would only be declarative if the user literally wrote the entire result set of the query. This would then obviate the need for SQL. The result set of a query is called "data". It's not a declarative language.
You're free to redefine terms, but as I mentioned, you're going to have a hard time finding people to agree with you.
There are no bits, bytes and cpus in this conversation. This is classification and taxonomy of artificial languages created for other purpose than communication between 2 persons.
In SQL you gives instruction in a functional way of thinking. Functional programming is a restricted variation of imperative one for a purpose the same way how object oriented programming is basically structured programming with restrictions imposed on the programmer (for a purpose again, and a very good reason for that). So fundamentally SQL is imperative, but the details of that completely hidden and therefore irrelevant.
In HTML you describe the result itself. So "SQL would only be declarative if the user literally wrote the entire result set of the query" is not completely, but somewhat true. The way how you define a result can vary, but SQL definitely does not do that. But the way how i can imagine SQL as declarative, if i "programming by example" or ask chatgpt to translate my natural language and create the query. But these are forced examples, because IMO SQL is absolutely not declarative, and cant really be.
If HTML is a programming language or not, it's debatable, but i think it's enough that is a language (programming or not) which is designed to describe a flow-kind of a text layout (like a word file) in the first versions, then other visible elements, so i think it's not completely, but kinda irrelevant question from the viewpoint of paradigm.
With all due respect, I don’t understand what your aim is with this discussion, and at this point I think I’m more confused than when we started. What is your aim here?
> If HTML is a programming language or not, it's debatable
I suppose to some degree, everything is debatable. But this point isn’t somewhere where we’re going to find common ground. Another commenter said it well — with HTML, you get what you write. It’s not a programming language.
In any case, I appreciate you taking the time to expand on your reasoning. I’m just still struggling to make heads or tails of it.
I don't really have an aim, I just made a simple statement, and after that everything is back and forth. Classification of languages has no practical implication (or not too much), what it changes is how they are taught, like "INTRO TO PROGRAMMING 101 BEGINNER CLASS FOR DUMMIES"
>I suppose to some degree, everything is debatable.
I just wanted to say that i dont think it's important to decide if HTML is an actual programming language or not, I see it as a language that defines something for a computer. We can just put all alikes into the "Markup-not-programming-language" basket, and that invalidates all of my arguments. I feel in this case there is no big difference in functional/imperative vs declarative languages assuming most of the people's different-than-mine classification, so why even bother then?
But the part that is declarative is sure difficult to test.
i did not speak about testing, however what a declarative language can do is defined by the framework under it. so you test that I guess?
You don't draw line by line. You describe what you want and have the engine work it out. Just because that description can be complex such as a <path> definition doesn't detract from this point.
Kinda like SQL. Describe the set of data you want from other sets of data and have the engine work it out. It's set theory. In math, sets can have conditions, can be combined, can be filtered, and all without a single function or loop in sight. Ergo declarative, not functional or imperative.
SQL is a DSL for set theory with some extensions tacked on. You can use functions with SQL, but its core is perfectly adequate without them.
I totally agree. It is declarative the same way how HTML is.
I don't see how SQL and SVG is similar from the viewpoint of approaching the problem. In SVG you concretely define what you want, and that is happening. In SQL you don't define the data you get, like ok, this cell will be 5, another will 8. I understand what you want to say, I just see those completely different ways.
>can be combined, can be filtered, and all without a single function or loop in sight
This is the key here, because this is exactly true to functional programming.
Compare SQL->LINQ->lambda expression
If they work the how you say, then
SQL - declarative
LINQ - declarative and functional the same time
Lambda exp - functional
This idea is completely nonsensical for me
Point to any programming language that is supposed to be a pure example of anything and folks will either find at least ten clear counterexamples in that language within five minutes or demonstrate how it is grossly limited to the point of uselessness for production use on a non-trivial scale.