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