Which part of it you couldn’t understand?
How does aggregate know what function to use? The examples on the aggregate page actually list aggregate functions, but everywhere else it's just... magically decided?
It supports TOP or LIMIT, but where's the windowing? Where's OFFSET 100 ROWS FETCH NEXT 25 ROWS ONLY for page 5?
What the heck does "order by: 2" mean? Even if it's an ordinal position, that's not a great example. Yes, SQL technically allows you to use ordinal positioning of columns in the ORDER BY, but it's horrible practice to use that because it's difficult to maintain. There's no way to tell what the original intent was, and the output columns change all the time when queries are reused.
My real question, however, is: "How is this actually easier?". Yes, sure, using symbols instead of English words is shorter, and a lot of programmers mistake a lower character count for being easier. However, it's not actually easier. It's just a bit less typing.
1) Nesting builds nested results (like GraphQL). This is particularly hard to do in SQL but is allows very large complex data sets to be returned in a single query.
https://looker-open-source.github.io/malloy/documentation/la...
For example the dashboard on the page below is a single SQL query:
https://looker-open-source.github.io/malloy/documentation/ex...
> How does aggregate know what function to use?
You can pre-define calculations with 'measure:' or decalre them explicitly in a query.
> where's the windowing
It's missing with a bunch of other things (like union for example). Its coming of course. The goal is that everything represent able in SQL is represent able in Malloy.
> heck does "order by: 2" mean
Same thing as it does in SQL. We try and have reasonable defaults.
https://looker-open-source.github.io/malloy/documentation/la...
> "How is this actually easier?"
The goal here is to be able to create data models that are re-usable and compose-able and verifiable. Yeah, there is a learning curve as there is with anything powerful. There are many things expressible in Malloy that cannot be easily expressed in SQL.
[{
flight_date:
carrier:
daily_flight_count:
per_plane_data: [
{
tail_num:
plane_flight_count:
flight_legs: [
https://looker-open-source.github.io/malloy/documentation/pa...
Here is the SQL we generate.
https://gist.github.com/lloydtabb/8c144d2dac978dda9bf3ec4d6b...