Your link has the answer, declarative testing. You need to think about why you wrote that code and declare some outputs for given inputs that give you confidence in your code.

The other tests from your link are just silly. You did not write code to terminate or to provide an answer for all inputs, you wrote code to provide the right answer.

To test some HTML for instance, think about what information you want the page to convey, load up a browser, and check that the info is displayed. Easy as that.

> You did not write code to terminate or provide an answer for all inputs...

Definitely not an expert. But to my eyes checking for non-termination seems very close to things that happen in SQL all the time.

For example, a parent query joins two subqueries that both map data, and then maps on that data. To test, I could just test one specific scenario with specific values in all columns. That would be more of a concrete test case.

But I might want something more robust checking the outer bounds of acceptable data (like a min and a max). That seems much closer to the non-termination test.

Of course, I'm open to being corrected on this.

SQL is not a declarative language. It is a functional language, and structured language on the top as extensions. HTML is a declarative language.

> Although SQL is essentially a declarative language (4GL), it also includes procedural elements.

https://en.wikipedia.org/wiki/SQL

-3 votes shows how this is a common misunderstanding.

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. 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 changes (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.

> If SQL was a declarative language, there would not be expression in it, for example SELECT (1+2) , only SELECT 3

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.

one way of seeing this, everything, which is high level language is declarative, but if we do this, we make this classification meaningless. it was just an example, for an operator, which is an "activity" is not part of a declarative mindset (usually). you can twist the idea of SQL to be declarative, but in this case we go back to my first sentence, and distinction will have no purpose.

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

> 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.

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?

you can force SQL to fit in this, but this way everything become a declarative language. the approach of solving problems is the difference.

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.

No.

SQL is almost the _textbook definition_ of a declarative language.

It does not define the way. It defines the end result.

You make a statement without reasoning or examples: empty argument. You are not arguing any more, just want to be right.

> 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.

And today's physicists will say that's a perfectly adequate approximation in your local frame of reference far below the speed of light.

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.

Oh, man, you opened my floodgates pretty well. I feel I have to mention that everything I write is my opinion, and not absolute truth. I reject the idea of absolute truths anyway.

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.

The most important requirement for a functional language is that functions are first-class values. i.e. Not SQL.

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?

You are speak about things which called delegates, typed functions, defined by the parameters it gets, and the data it returns. Using delegates does not make a language functional. If you really want to speak about the underlying technology, than every high level language is declarative. You can draw a triangle by drawing three sides, or you can just put this in a function like drawtriangle(v1,v2,v3), and tadam, your language is declarative. The underlying tech is not important, the approach of the developer is important. See my longer answer above

Your comments in this thread have made for a pretty tough read, but I think your angle is finally made clear here.

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.

I'm sorry, i'm speaking with multiple people on multiple threads here, and don't have too much time to express myself perfectly. Every language is declarative is an interpretation that can make sense in certain angle, like when you use some imperative language, you create mini libraries for yourself, and that's already steps to a declarative variation, but this does not changes the fundamental design of the language.

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.

That's quite the slippery slope though.

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.

Technical and implementation details again. When we speak about programming paradigm, we speak about the language alone, not any software system, this is a theoretical discussion. It does not matter how it is executed, what matter is how you express yourself in that language to achieve your goals.

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.

> this is a theoretical discussion

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.

Thank you for actually listening and trying to communicate with me, instead of just shooting ad-lib responses like "it's in the textbook so that is that".

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?

You tell SQL what you want, not how to get it. That's declarative.

  SQL : CSV :: GraphQL : JSON :: React : HTML

Really?

SELECT 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

I’ve not encountered your definition of declarative before. SQL is often cited in cs texts as an example of a declarative language. That said, SQL does have a lot of imperative features, but those features are used to declare the result of the sql dml query.

SQL does not make sense as a declarative language to me. How you can say that SQL and HTML is the same by nature?

"Declarative language" does not mean "free of computation". It does mean the language generally specifies an output. HTML does have computation in the form of <script> tags. What makes HTML and SQL declarative instead of imperative is that in both SQL and HTML the document specifies an specific output that is wanted from the browser (in HTMLs case) or database (in SQLs case). Your earlier example of SELECT (1+3); is something that can be done in HTML (many different ways), too. Reality is that declarative languages would be little more than file formats without access to computation. For example, it would be impossible to write a query that always returned results for the interval of last week, without having to change the query every time you run it without the now and interval commands.

I never meant "free of computation", I actually mentioned a lot that forget computers and softwares, and focus on languages.

<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

next

-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.

> 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.

Further, another way to look at it is, declarative languages specify output, imperative languages focus on the steps to generate outputs. In imperative code, I'm worrying about how instead of what. In declarative code, I'm worried about what instead of how. As in all things, neither of these statements will be absolutes - there are situations and times where a declarative language user will worry about how the query planner will execute, and there are times where an imperative language user will write very much declarative code.

>neither of these statements will be absolutes - there are situations and times where a declarative language user will worry about how the query planner will execute, and there are times where an imperative language user will write very much declarative code.

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.

> That's right, in practice everything is more like a mishmash of everything.

I agree, and will die on this hill :-)

Does the presence of conditional expressions mean that the language which permits them is necessarily not declarative?

no, the approach makes the difference.

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

> 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

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.

>This is exactly what SQL is. There are exceptions, but they're exceptions.

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?

it is possible to reduce your query w/case statements to essentially "all cost of all employees" if you would model every type of employee and cost relationally (and then some view for all-employees which is the union of each type projecting the approptiate cost and so on) then your query gets to just ask for records again without having to "tell how" those things are to become records.

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.

It is not possible, but it is the future, you already have a glimpse with chatgpt creating sql for you. Now that is real, 100% declarative SQL, no debate on that, as everything will be some-when in the future.

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.

You do not understand SQL. HTML and SQL are essentially unrelated. It would be to your benefit to spend some time reading and learning on these topics.

Of course they are, however they are both languages. And you classify them into the same category, so it should have some similarities, right?

I am not classifying them into the same category. I am explicitly doing the opposite. SQL is declarative, HTML is a markup language, they are categorically different.

I'm not the person you were replying to but you've misunderstood their comment - they were saying that CSV is to SQL what JSON is to GraphQL (and HTML to React) these being declarative languages for records, objects, and markup

A "case" statement in SQL (or an "iif") is still declarative, how else would you express specific cases when necessary?

Oh, i see, i did not get it. However i don't understand how "You tell SQL what you want, not how to get it. That's declarative" related to that list

iif and case by itself is not declarative or imperative. only an entire language can be described as such

SQL is declarative in the sense that you dont specify the strategy to employ in retrieving the data (ie which index to access and how, whether to sort and merge or build a hash table etc etc) however you DO need to specify how to represent your data as records (which could entail specific cases for when certain values go in the same cell as you pointed out).

You don't care about how the SQL server gets the data the same way how you don't care about what is happening in the background when you use File.ReadAllText The technology behind does not define the programming paradigm. You can speak about these paradigms without computers.

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)

I think what you're saying is accurate for describing what style of programming you might be doing, afterall we can write C++ in a declarative style. if you're coding in SQL then you're doing functional programming, but that doesn't change the fact that SQL is a declarative language for describing recordsets. you wouldn't refer to SQL as a functional programming language because it's not general purpose.

No, programming style can be "hacky", "script kiddie" or "architect kind design" or whatever. I'm speaking about "programming paradigms".

"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.

Okay, I'll grant it's not pure declarative.

But the part that is declarative is sure difficult to test.

everything is partly declarative. you can draw a rectangle line by line, or you can put this code into a function or a procedure, and call it declarative, because it is something like that.

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?

SVG: Draw rectangles and triangles. If you don't have a script tag in it, totally declarative.

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.

>SVG: Draw rectangles and triangles. If you don't have a script tag in it, totally declarative

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

And there's the crux of it all. Nothing is pure in this world except perhaps some parts of math. Everything else is an approximation or a corruption.

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.

I mean, I get what you are aiming for. HTML, though, is a markup language. You can call it declarative, but you don't get anything other than the HTML that you create. That is, it is not generating anything. You type what you get. Put differently, it is not a program.

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.

"don't get anything other than the HTML that you create" that's the point of declarative languages

"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.

Comparing to html is nonsensical. Period. It is not instructions on how to do anything, but markup of a document. Would be akin to asking if a bitmap is declarative. It is literally the data. It is not a declaration of what you want, but is a definition of what you have. In that vein, you would need a new taxonomy of "definitive" languages.

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?

"Comparing to html is nonsensical" No, absoltely not. We are speaking about programming paradigms. We can speak about those without computers, we never have to speak about HTML. A food recipe is a program, what you are executing when you cook, and it is imperative. Going to the restaurant you can achieve the same (the dish) but in a declarative way.

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.

You keep retreading the same ground. Have you actually gone out and researched why so many people are telling you that SQL is declarative? Right now, it is reading as though you are being willfully ignorant of the entire field.

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.

You taking apart languages, saying this is imperative part and this is declarative. That does not make sense only entire languages can be described like that.

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...

Declarative: giving your order to the waiter and having the food returned to you fully prepared.

Imperative: following and executing a cooking recipe

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.

SQL is absolutely a declarative language. It is practically the textbook definition of a declarative language.

Very often literally as well.