Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CQL: Categorical Databases

categoricaldata.net

Post reply on HN
Print view View original

31–40 of 44 posts

Re: CQL: Categorical Databases

#31

Post by thesz »

da_chicken wrote: post #14
adrian_b wrote: post #12

Earlier quoted context omitted.

DROP TABLE ? Most of SQL is not imperative, but it certainly also includes some imperative commands. Inserting a new row into an existing table is an imperative command, which may be the most frequently used of the SQL features, in certain applications concerned with recording transactions. Only the subset of SQL that is used for queries can be said to not be an imperative programming language.

No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless. Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.

Imperative languages such as C/C++ specify "microtransactions" - an ordering over memory accesses (including (de)allocations) within some statement or group of statements.

Compilers are free to rearrange these accesses if the final result is same as if executed by these ordered microtransactions.

Consider loop fusion, loop splitting and/or loop skewing.

Re: CQL: Categorical Databases

#32

Post by thesz »

adrian_b wrote: post #13
js8 wrote: post #5

Earlier quoted context omitted.

My (amateur) take. CDB model (based on functions) has three advantages over RDB model (based on relations): 1. Easier modelling sum types (inheritance) due to duality. 2. Better handling of null due to labelled null. 3. Better foundation of elementary types (they're just another table ids). (Column stores often do that already, if your question is about storage.)

While the relational model is claimed to be based on relations, the vast majority of the "relations" used in practice are functions, not general relations. A general relation exists only between the columns of a table that are included in a multi-column primary key. All columns that are not part of the primary key are functions of the primary key. Most tables used in practice use a single column as the primary key, w…

While it is true on the schema level, it is not true at the query level.

The most frequently used kind of join is a general relation.

[1] https://github.com/agirish/tpcds/blob/master/query1.sql

Query 1 from TPC-DS creates a multi-column relation by using GROUP BY. Which relation is then partially constrained by different columns from different tables.

Re: CQL: Categorical Databases

#33

Post by layer8 »

thesz wrote: post #30
randomNumber7 wrote: post #9

Earlier quoted context omitted.

SQL is not an imperative programming language.

For all practical purposes, it very much is, consider random number generation.

While agree with the main statement, I don’t understand the point about RNG. You don’t need Turing-completeness nor imperativeness for RNG.

Re: CQL: Categorical Databases

#34

Post by layer8 »

ianhorn wrote: post #28
mattstir wrote: post #19

> Reduce risk of failure through artificial intelligence. CQL contains an embedded automated theorem prover that guarantees the correctness of CQL programs. Man, it's a rough environment right now marketing-wise. I don't know if they're contractually obligated to say the funny magic words, but the term AI is nearly entirely meaningless at this point. Akin to saying "behold my mighty calculator app: it prevents divisi…

Huh, I read the pitch differently. As "reduce risk of (failure through artificial intelligence)," not as "(reduce risk of failure) through artificial intelligence." Maybe that's my bias since that's what I'm working on, but it's a big benefit to have stronger compiler guarantees of correctness so that an LLM can't screw things up as much. No BSing that it works when the compiler requires proof.

I had to read it twice to come to that conclusion. Maybe the prima facie ambiguity is intentional.

Re: CQL: Categorical Databases

#36

Post by solomonb »

iron_fever wrote: post #22

I know very little about databases, but I work heavily with category theory, so fwiw: I think the main benefit is composition. The edge over SQL shows up when you combine schema mappings - a mapping is a functor, so when you migrate data along it the constraints come with it by construction, and you don't end up writing ETL and hoping integrity held. As best as I can tell (but i really dont know much about databases)…

I haven't used CQL but this is how the advantages have been described to me as well.

Re: CQL: Categorical Databases

#38

Post by da_chicken »

adrian_b wrote: post #20
da_chicken wrote: post #14

Earlier quoted context omitted.

No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless. Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.

Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is. printf("Hello world!"); also does not tell anything to the system about how to accomplish this. Anyone who claims that an SQL command like insert a row, create a table or destroy a table is not imperative, is just plainly wrong. Even in real life, when humans communicate commands to each other,…

> Anything that causes a persistent change of the state of a system is imperative, regardless of how detailed the command is.

No. That's more to do with imperative vs functional programming, which is a subset of declarative, but even then you can't simply say "I changed state so it's imperative." That's a drastic oversimplification. That's like saying Haskell can't write to a file, which is plainly false. Declarative (functional) can absolutely change the state of the system. It just doesn't let you do it except by calling fixed commands, which is exactly what `INSERT` is.

When we're talking about imperative vs declarative, state can still be manipulated in both, but it's abstracted away with declarative programming. Like, a `filter()` or a `map()` transform in JavaScript is declarative programming, even in an otherwise imperative language. That's why it returns a new object with an updated state.

Re: CQL: Categorical Databases

#39

Post by da_chicken »

cmrdporcupine wrote: post #17
da_chicken wrote: post #14

Earlier quoted context omitted.

No. Standard DDL and DML are declarative in SQL, including DROP and INSERT. Those still don't tell the system how to accomplish the thing. Declarative doesn't mean idempotent, and it doesn't mean stateless. Imperative SQL is the procedural elements that mostly do not exist at the standard level. Variables, control flow, and cursors.

This just exposes how weak this definition of declarative is, I think. Or how it's carrying two meanings here. What you're really talking about is one of the things Codd wanted to emphasize: representational independence. Which actually was the primary thrust of his famous paper: the user should not need to know how the data is stored in order to use or manipulate it. The other thing that people are talking about wit…

I would say it exposes how imperative programming was forced to adopt declarative/functional paradigms in order to write things concisely, to the extent that nobody thinks those elements are declarative/functional anymore.
Post reply on HN