4 ms·

I would probably say that you are miss-understanding the difference between syntax and the evaluator that evaluates that syntax. All three of these expressions

I would probably say that you are miss-understanding the difference between syntax and the evaluator that evaluates that syntax. All three of these expressions contain the same data: (select (col1 col2) (table1) (= col1 "foo")) "select col1 col2 from table1 where col1 = 'foo'" <select><columns><column>col1</column><column>col2</column></columns><tables><table>table1</table></tables><filters><equalityfilter><column>col1</column><value>foo</value></equalityfilter></filters></select> All three of these are "4th generation, declarative DSLs for set theory" as you like to brandish around. > If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it. S-Expressions are just a syntax. It's quite normal to see Lisps that are functional, declarative, object-oriented or procedural. The only thing that differentiates Lisps from other programming language is the simplicity of the syntax enabling meta-programming, which is specifically the problem with SQL syntax and it's composability.

ttfkam 4y ago
JSON, and XML are data structures, not programming languages. Can you loop or iterate in JSON or does some other language do the iterating? Can XML execute instructions (without a script tag or processing instruction, which is just punting to an external 3rd-gen language)? S-Expressions blur the line a bit, but clearly not in the direction of 4GL. A 4th-gen language is specifically one that describes what you want, not how to get it. S-Expressions fail this metric in that they can describe the logic for retrieval in addition to the data (where the data portion is not conducive to it being a programming language). SELECT a.id , a.name , p.name FROM alien a JOIN planet p ON a.planet = p.id WHERE a.name = 'Kaminoan' ; Now here I'd completely agree that things might have been better with some non-implicit syntax bounds, eg.: SELECT [ a.id , a.name , p.name ] FROM [ alien a ] JOIN [ planet p, (a.planet = p.id) ] WHERE [ a.name = 'Kaminoan' ] ; As it stands today, SQL has some pretty gnarly EBNR to describe it. But that is still missing the point. Where are the datasets for "alien" and "planet"? Are they on the same disk? The same server? The same cluster? The same kind of database? Are there a lot of aliens? Would a btree index lookup be more appropriate, a sequential search, a bloom index, or some other algorithm? Is alien name enforced to be unique or not so that we can be sure to return either optional one, exactly one, zero or more, or one or more? Is "planet" a single table, a view into one or more tables, a materialized view that caches its results, or a foreign table accessing the data from another source that isn't even relational? A 3rd-gen language would need to know these things. It would require telling the system HOW to get the data rather than just describing WHAT data subsets are desired based on other known data sets. It doesn't just transform one or more sets into a new set without any consideration as to what serialization format those data sets are stored in—on disk or in memory. Here we have the need for separation between DDL and DML. Yet DDL still only describes the structure and makes access patterns available. Creating an index does not mandate use of that index. It merely puts that data access pattern on the menu. DML (as seen above) makes the query result set definition but has nothing to do with telling the engine how it should go about doing it. Ergo: 4th-gen declarative language This doesn't mean SQL is the best language or even better than all 3rd-gen languages simply because it's a 4th-gen language. But if you're going to engage in this topic, I strongly encourage you to learn what a 4th-gen language actually is and how laughable calling JSON, XML, or S-Expressions one is. I could give you HTML as a 4th-gen language in that it describes layout and general behavior without reference to how the layout engine renders it or implements its linking, form-handling, and embedding behavior. HTML+CSS make a compelling case for a composite 4th-gen language, describing what you want, not how to render it. Whether it be links, Firefox, or Mobile Safari, the description is the same and the desired behavior is well-defined despite wildly different implementations from the engines.
- ludston 4y ago
  I keep replying to you by the way because I'm really hoping you are going to have the aha moment that is holding you back here. Again, you are misunderstanding the difference between syntax and how it is used. Json and xml aren't data structures. They are syntaxes, which are commonly serialised into a data structure. (Usally a tree). S-expressions are also syntaxes that can be parsed into a data structure. Did you know that C# is also a syntax that can be parsed into a data structure? The Roslyn compiler does this, which allows for symbolic code manipulation and generation. Did you know that's how almost every programming language parser works? They will tokenise a syntax into a symbolic data structure which will then either be interpreted and executed or output a binary. You can quite easily write a parser for xml that uses it as a programming language. Two well known examples of this include xslt and xhtml. Xhtml is even one of your lauded 4th gen declarative languages. Whether or not the language is popular enough to have multiple parsers isn't relevant to the class of language that it is. In the example of a c++ program that reads xml into a tree, and then converts that xml into sql to be executed on a database, that xml syntax has become a 4th gen domain specific language. The important distinction between languages and data structures is the the implementation of the parser/evaluator and what it does with the text or symbols that it reads. A language implies execution and a datastruture implies serialisation.
  - ttfkam 4y ago
    Oh come on. You are basically arguing that Python is just syntax, not a programming language; it's just the interpreter that parses the text and makes it go. No duh! You've made a distinction without a difference. If an XML dialect were to be parsed by a processor to declaratively perform a sequence of tasks, the AST is not relevant to this discussion, only the tasks being performed. The XML dialect—the semantic structure behind it—is what I'm discussing. JSON and XML as they are used today are "just syntax", but they are examples of syntax that almost universally are parsed directly into data structures. The Liquibase XML dialect on the other hand moves beyond a simple data structure into a declarative language for migrating database structures from one form to another by virtue of the Liquibase engine. SQL is not "just syntax" any more than your speech is "just phonemes". Yes, English, Xhosa, and Mandarin are all just collections of phonemes. All written languages are "just syntax" waiting to be processed by smart meat. It is needlessly reductive. SQL absolutely implies execution in a way that JSON/XML do not. However, the style of execution is clearly different between SQL and C#. That style can accurately be described as set-oriented execution, at a higher level than 3rd-gen languages such as Python or C#. Writing a parser for SQL (or XHTML) is a very different exercise from processing the AST from that parsed SQL/XHTML if that processing happens immediately after the parsing step and is largely driven by that AST. Relational database engines are interpreters for SQL.

ttfkam 4y ago

JSON, and XML are data structures, not programming languages. Can you loop or iterate in JSON or does some other language do the iterating? Can XML execute instructions (without a script tag or processing instruction, which is just punting to an external 3rd-gen language)? S-Expressions blur the line a bit, but clearly not in the direction of 4GL. A 4th-gen language is specifically one that describes what you want, not how to get it. S-Expressions fail this metric in that they can describe the logic for retrieval in addition to the data (where the data portion is not conducive to it being a programming language). SELECT a.id , a.name , p.name FROM alien a JOIN planet p ON a.planet = p.id WHERE a.name = 'Kaminoan' ; Now here I'd completely agree that things might have been better with some non-implicit syntax bounds, eg.: SELECT [ a.id , a.name , p.name ] FROM [ alien a ] JOIN [ planet p, (a.planet = p.id) ] WHERE [ a.name = 'Kaminoan' ] ; As it stands today, SQL has some pretty gnarly EBNR to describe it. But that is still missing the point. Where are the datasets for "alien" and "planet"? Are they on the same disk? The same server? The same cluster? The same kind of database? Are there a lot of aliens? Would a btree index lookup be more appropriate, a sequential search, a bloom index, or some other algorithm? Is alien name enforced to be unique or not so that we can be sure to return either optional one, exactly one, zero or more, or one or more? Is "planet" a single table, a view into one or more tables, a materialized view that caches its results, or a foreign table accessing the data from another source that isn't even relational? A 3rd-gen language would need to know these things. It would require telling the system HOW to get the data rather than just describing WHAT data subsets are desired based on other known data sets. It doesn't just transform one or more sets into a new set without any consideration as to what serialization format those data sets are stored in—on disk or in memory. Here we have the need for separation between DDL and DML. Yet DDL still only describes the structure and makes access patterns available. Creating an index does not mandate use of that index. It merely puts that data access pattern on the menu. DML (as seen above) makes the query result set definition but has nothing to do with telling the engine how it should go about doing it. Ergo: 4th-gen declarative language This doesn't mean SQL is the best language or even better than all 3rd-gen languages simply because it's a 4th-gen language. But if you're going to engage in this topic, I strongly encourage you to learn what a 4th-gen language actually is and how laughable calling JSON, XML, or S-Expressions one is. I could give you HTML as a 4th-gen language in that it describes layout and general behavior without reference to how the layout engine renders it or implements its linking, form-handling, and embedding behavior. HTML+CSS make a compelling case for a composite 4th-gen language, describing what you want, not how to render it. Whether it be links, Firefox, or Mobile Safari, the description is the same and the desired behavior is well-defined despite wildly different implementations from the engines.

ludston 4y ago
I keep replying to you by the way because I'm really hoping you are going to have the aha moment that is holding you back here. Again, you are misunderstanding the difference between syntax and how it is used. Json and xml aren't data structures. They are syntaxes, which are commonly serialised into a data structure. (Usally a tree). S-expressions are also syntaxes that can be parsed into a data structure. Did you know that C# is also a syntax that can be parsed into a data structure? The Roslyn compiler does this, which allows for symbolic code manipulation and generation. Did you know that's how almost every programming language parser works? They will tokenise a syntax into a symbolic data structure which will then either be interpreted and executed or output a binary. You can quite easily write a parser for xml that uses it as a programming language. Two well known examples of this include xslt and xhtml. Xhtml is even one of your lauded 4th gen declarative languages. Whether or not the language is popular enough to have multiple parsers isn't relevant to the class of language that it is. In the example of a c++ program that reads xml into a tree, and then converts that xml into sql to be executed on a database, that xml syntax has become a 4th gen domain specific language. The important distinction between languages and data structures is the the implementation of the parser/evaluator and what it does with the text or symbols that it reads. A language implies execution and a datastruture implies serialisation.
- ttfkam 4y ago
  Oh come on. You are basically arguing that Python is just syntax, not a programming language; it's just the interpreter that parses the text and makes it go. No duh! You've made a distinction without a difference. If an XML dialect were to be parsed by a processor to declaratively perform a sequence of tasks, the AST is not relevant to this discussion, only the tasks being performed. The XML dialect—the semantic structure behind it—is what I'm discussing. JSON and XML as they are used today are "just syntax", but they are examples of syntax that almost universally are parsed directly into data structures. The Liquibase XML dialect on the other hand moves beyond a simple data structure into a declarative language for migrating database structures from one form to another by virtue of the Liquibase engine. SQL is not "just syntax" any more than your speech is "just phonemes". Yes, English, Xhosa, and Mandarin are all just collections of phonemes. All written languages are "just syntax" waiting to be processed by smart meat. It is needlessly reductive. SQL absolutely implies execution in a way that JSON/XML do not. However, the style of execution is clearly different between SQL and C#. That style can accurately be described as set-oriented execution, at a higher level than 3rd-gen languages such as Python or C#. Writing a parser for SQL (or XHTML) is a very different exercise from processing the AST from that parsed SQL/XHTML if that processing happens immediately after the parsing step and is largely driven by that AST. Relational database engines are interpreters for SQL.