News for hackers. Stuff that matters.

A comment on SQL databases come up with algorithms you’d never have dreamed of (2017) [video].

Re:SQL databases come up with algorithms you’d never have dr... by rgoulter on Saturday April 06, 2019 @03:59AM (#19589785)
At around 22:10, the speaker summarises equivalencies between common SQL clauses (SELECT, GROUP BY, etc.) and what Java 8 calls a "stream API" (map, collect, etc.). https://blog.jooq.org/2015/08/13/common-sql-clauses-and-thei...

Neat. I hadn't thought of it that way before.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by mjburgess on Saturday April 06, 2019 @04:29AM (#19589863)
I teach most (dynamic) functional programming constructs by starting with SQL.

Python comprehensions, etc. are mostly just SQL -- likewise most languages where "map" is part of the collections API.

SQL motivates the utility of functional programming for data-oriented applications.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by thesz on Saturday April 06, 2019 @08:59AM (#19590492)
https://www.schoolofhaskell.com/school/to-infinity-and-beyon...

See TransformListComprehension section. Haskell uses tricks from SQL while still having nice syntax.

http://ekmett.github.io/discrimination/ - a library to perform what SQL engines do for optimization of relational queries, online and in Haskell.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by collyw on Saturday April 06, 2019 @07:51AM (#19590321)
Have you got any material online to look at? I am curious to see the sort of stuff you are talking about ("Python comprehensions, etc. are mostly just SQL" doesn't make a lot of sense to me right now. I see them as an inline for loop).
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by afandian on Saturday April 06, 2019 @09:11AM (#19590538)
I wouldn't compare a comprehension to a loop because a loop doesn't typically have an output. If a loop does produce an output it's through side effects. List comprehensions are the same as maps, and generator comprehension even more so, as they can compose functions not values.

And a map can be the same as a projection as found in sql.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by taeric on Saturday April 06, 2019 @10:29AM (#19590901)
Loops in lisp would like a word with you. :)

The difference is that many languages have constructs that weren't value producing. It is why some have the ternary operator, but lisp just had if statements.

So, to that end, most loops do produce a value. And there are several common ways they do it. In many languages, you have to give the details of how they work. In some, you can only those details and the building if the output is a bit more declarative.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by afandian on Saturday April 06, 2019 @11:36AM (#19591233)
I was coming from the Lisp perspective! Or at least Clojure...

Maybe it's a language issue. I would say a 'loop' has a jump and a condition. So that's 'for', 'while' and 'do' in C, JS, Python, Pascal, Java...

Lots of languages including Lisp have recursion, maps etc but I wouldn't call that looping. Clojure even has TCO recursion but it only returns one value, not a sequence (unless you accumulate the whole thing)

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by taeric on Saturday April 06, 2019 @12:15PM (#19591455)
But even the LOOP macro has returned values for a long time. It isn't even hard to see how the new stream/collect API if Java is just approaching what LOOP has been doing for decades.
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by dfox on Saturday April 06, 2019 @12:34PM (#19591562)
Java's streams implement the same idea as Common Lisp's streams, which were supposed to be more Common Lisp-like replacement for LOOP (eg. composable and with syntax that does not involve string comparison of symbols). That idea was droped from the final ANSI standard.
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by lispm on Saturday April 06, 2019 @01:01PM (#19591703)
SERIES, not streams.
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by afandian on Saturday April 06, 2019 @12:31PM (#19591548)
OK agreed there's a construct called loop that returns a single value. My original point was that list comprehensions are closer to sql projections than loops.
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by taeric on Saturday April 06, 2019 @01:06PM (#19591730)
Apologies, I meant my point more as amusement than winning an argument.

I am just now reading Practical Common Lisp, and amusingly one of the first things they do is build a simple query language. Didn't even use loop. So, to your point, the imperative commands of looping can be far removed from what people today call comprehensions. That said, I don't think it is inherent. Just a quirk of history.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by afandian on Saturday April 06, 2019 @05:46PM (#19593207)
No point scoring inferred. In fact, it's a great illustration of different language and technology communities taking words and ideas and implementing them differently, crucially, with different degrees of specificity.
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by dragonwriter on Saturday April 06, 2019 @10:40AM (#19590957)
> I wouldn't compare a comprehension to a loop because a loop doesn't typically have an output.

Loops in lots of languages have outputs. It's kind of necessary in expression-oriented languages.

But it's true that comprehensions are different than Python loops in that way (and are, in fact, equivalent to maps with joins and filters, like an SQL SELECT statement.)

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by afandian on Saturday April 06, 2019 @11:39AM (#19591254)
Per my other reply [0] maybe my definition of loop, based on C, was too narrow.

I draw a distinction with map, recursion, lazy sequences etc

[0] https://news.ycombinator.com/item?id=19591233

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by mjburgess on Tuesday April 09, 2019 @12:47PM (#19616560)
ages = [ row['age'] for row in table ]
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by miguelrochefort on Saturday April 06, 2019 @08:23AM (#19590397)
In C#, the LINQ operators on IEnumerable and IObservable are named after the SQL causes (Select, Where, GroupBy, OrderBy, Join, Union, etc).
[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by Falell on Saturday April 06, 2019 @09:15AM (#19590555)
More than that, as part of LINQ they built a whole "expression" engine into the language to make LINQ to SQL more powerful than simple method chains could be. What looks like function calls is actually converted into expression tree at the language level before conversion to SQL statements when communicating with a DB backend.

The method-chains-vs-expression-tree semantics don't matter much when doing typical in-memory map/filter/reduce on lists but make LINQ to SQL and other more complex use cases much more powerful.

[ Parent | on HN ]
Re:SQL databases come up with algorithms you’d never have dr... by jayrwren on Saturday April 06, 2019 @10:40AM (#19590956)
When .NET introduced LINQ this is 90% of what the .NET world talked about for the next 3yrs.
[ Parent | on HN ]