Hacker News Reader

Comment by rgoulter | Hacker News Reader

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.

View on HN

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.

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).

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.

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.

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)

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.

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.

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.

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.

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.

SERIES, not streams.

> 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.)

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

ages = [ row['age'] for row in table ]

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.

In C#, the LINQ operators on IEnumerable and IObservable are named after the SQL causes (Select, Where, GroupBy, OrderBy, Join, Union, etc).

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.

When .NET introduced LINQ this is 90% of what the .NET world talked about for the next 3yrs.

Reply on news.ycombinator.com