Re:Why Functional Programming Should Be the Future of Software
by tsimionescu on Wednesday November 02, 2022 @03:42PM
(#33441830)
SQL was explicitly designed to appeal to business people, and uses strictly familiar words and phrases. It was very explicitly designed (though I would say it has mostly failed) to read like pseudo-natural language.
SQL DBs and the precise semantics of SQL are somewhat based on relational algebra, but SQL syntax is definitely not. It's also not using set theoretic terms in general, with the exception of UNION and INTERSECT.
Re:Why Functional Programming Should Be the Future of Software
by TexanFeller on Wednesday November 02, 2022 @07:49PM
(#33444542)
SQL tables are not actually sets at all since you can insert duplicate rows! In practice they usually are though.
Re:Why Functional Programming Should Be the Future of Software
by packetlost on Wednesday November 02, 2022 @11:09PM
(#33446506)
You can't actually insert a complete duplicate row because the ROWID (or whatever your particular RDBMS calls it) is a implicit, but unique property of each row (and corresponds to the offset in the file the row is located at). Further, while tables can be the identity element of all records they contain, they themselves aren't really a set. Usually when people associate set theory with SQL, it's with queries (and their results).
I've only really ever seen monoids referred to in Haskell. If you actually read my comment, Haskell is not all FP (no PL is). It's not even a significant portion of FP. So just don't use Haskell, it's hardly the first FP language I would reach for and it's probably not the one you should either.