undefined | Better HN

0 pointsspamtarget3y ago0 comments

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.

0 comments

3 comments · 1 top-level

preseinger3y ago· 2 in thread

No.

SQL is almost the _textbook definition_ of a declarative language.

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

spamtargetOP3y ago

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.

ttfkam3y ago

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.

1 more reply

j / k navigate · click thread line to collapse