Isn't this the same syntax (or very similar to) Apache Beam?
Google's new pipe syntax in SQL
51–60 of 192 posts
Re: Google's new pipe syntax in SQL
#52We should really standardize a core language for SQL. Rust has MIR, Clang is making a CIR for C/C++. Once we have that, we'll be able to to communicate much better.
Right now, it's everyone faffing around with different mental models and ugly single pass compilers (my understanding is that parsing-->query planning is not nearly as well-separated in most DBs as parsing-->optomize-->codegen in most compilers).
Re: Google's new pipe syntax in SQL
#53> This remains a long-standing pet peeve of mine. PDFs like this are horrible to read on mobile phones, hard to copy-and-paste from ... I've never understood why copying text from digitally native PDFs (created directly from digital source files, rather than by OCR-ing scanned images) is so often such a poor experience. Even PDFs produced from LaTex often contain undesirable ligatures in the copied text like fi and fl.…
It’s due to poor choices made in the implementation of pdfTeX. For example the TeX engine does not associate the original space characters with the inter-word “glue” that replaces them, so pdfTeX happily omits them. This was fixed a few years back, finally. But there’s millions(?) of papers out there with no spaces.
Re: Google's new pipe syntax in SQL
#54Earlier quoted context omitted.
A surprising problem I'm seeing with maintaining a link blog is that articles from it occasionally get submitted to Hacker News, where people inevitably call them out as not being as appropriate as the source they are linking to - which is fair enough! That's why I don't tend to submit them myself. This particular post quickly turned into a very thinly veiled excuse for me to complain about PDFs, then demonstrate a G…
Have you seen gist.io? If you replace `gist.github.com/ / ` -> ` / " rel="nofollow">https://gist.io/@ / `, you get a gist with nice typography. https://gist.io/@simonw/46a33d66e069efe5c10b63625fdabb4e is the same gist you linked, but nicer to read
That's pretty neat! I like that it's run by a GitHub employee too (presumably as a side-project, but still) - makes me less nervous about the domain name blinking out of existence one day.
Re: Google's new pipe syntax in SQL
#55As to the writer's problem with PDFs on the web: they aren't for reactive web app viewing on mobile phones. Not everything has to be. If you reeeeeeeally need to read that research paper, find a screen that's bigger than 3" wide.
Re: Google's new pipe syntax in SQL
#56> This remains a long-standing pet peeve of mine. PDFs like this are horrible to read on mobile phones, hard to copy-and-paste from ... I've never understood why copying text from digitally native PDFs (created directly from digital source files, rather than by OCR-ing scanned images) is so often such a poor experience. Even PDFs produced from LaTex often contain undesirable ligatures in the copied text like fi and fl.…
> Is it due to something inherent in PDF technology?
Exactly. PDF doesn't have instructions to say "render this paragraph of text in this box", it has instructions to say "render each of these glyphs at each of these x,y coordinates".
It was never designed to have text extracted from it. So trying to turn it back into text involves a lot of heuristics and guesswork, like where enough separation between characters should be considered a space.
A lot also depends on what software produced the PDF, which can make it easier or harder to extract the text.
Re: Google's new pipe syntax in SQL
#57[dead]
Re: Google's new pipe syntax in SQL
#58We should really standardize a core language for SQL. Rust has MIR, Clang is making a CIR for C/C++. Once we have that, we'll be able to to communicate much better. Right now, it's everyone faffing around with different mental models and ugly single pass compilers (my understanding is that parsing-->query planning is not nearly as well-separated in most DBs as parsing-->optomize-->codegen in most compilers).
> We should really standardize a core language for SQL
Do you mean something other than ISO/IEC 9075:2023 (the 9th edition of the SQL standard)?
Re: Google's new pipe syntax in SQL
#59Is there research on what is easier to read when you are sifting through many queries? I like the syntax for reading what the statement expects to output first, even though I agree that I don’t write them select first. I feel like this might be optimizing the wrong thing. Although the example is nice, it does not show 20 tables joined first, which will really muddle it.
The select list is meaningless without everything that follows. Knowing that a query selects "id, "date" tells you nothing without knowing the table, the search criteria, etc.
I really wish SQL used "RETURN" instead of "SELECT" (like in XQuery):
1. Calling it "RETURN" makes the fact of its later order of execution (relative to FROM etc) less surprising.
2. "RETURN RAND()" just reads more naturally than "SELECT RAND()". After all, we're not really "selecting" anything here, are we?
3. Would also eliminate any confusion with the selection operation in relational algebra.
Re: Google's new pipe syntax in SQL
#60If anyone is interested in the theoretical background to the thrush combinator, a.k.a. "|>", here is one using Ruby as the implementation language: https://leanpub.com/combinators/read#leanpub-auto-the-thrush Being a concept which transcends programming languages, a search for "thrush combinator" will yield examples in several languages.
I find this [1] from this [2]. Seems like a good explanation. It doesn't exist on Wikipedia though. [1] https://github.com/raganwald-deprecated/homoiconic/blob/mast... [2] https://stackoverflow.com/a/285973/88231
A key thing to keep in mind is that the thrush combinator is a fancy name for a simple construct. The semantics it provides is a declarative form of traditional function composition.
For example, given the expression:
f (g (h (x)))
h (x) |> g |> f