PRQL – A proposal for a better SQL • Hacker News Board

Re: PRQL – A proposal for a better SQL

#141

Post by tester756 » Mon, Jan 24, 2022, 9:29 PM UTC

taeric wrote: post #127

emteycz wrote: post #107

Earlier quoted context omitted.

I'd agree if there was any way whatsoever of fixing this issue, but there simply isn't. The editor can't even begin to guess what you might want until you write your FROM.

Maybe in gigantic systems with more tables than makes sense. Realistically, all of the columns available in a database can be fit in memory with ease. Then, the ide could basically fill my from out for me, based on what I'm asking for. Can even suggest what join I will need, if I list columns from multiple tables.

>Maybe in gigantic systems with more tables than makes sense. Realistically, all of the columns available in a database can be fit in memory with ease.

Every table has more than one column

So there's always more columns to remember than tables and generally tables are pretty easy like user invoices blabla

I worked with systems that had like 500 tables and some of them with 20-50 columns

you really want good intellisense in such a environment

Re: PRQL – A proposal for a better SQL

#142

Post by maximilianroos » Mon, Jan 24, 2022, 9:31 PM UTC

blintz wrote: post #109

This is a nice idea, especially given all the work people have done recently to make in-language querying nicer (Spark comes to mind). My only gripe is the 'auto-generated' column names for aggregates. This seems like a recipe for disaster - what if there is already (as there almost certainly will be) named "sum_gross_cost"? The behavior also just seems rather unexpected and implicit. My suggestion would be simple sy…

Definitely — giving the option of naming them is great.

I'm not sure whether we should force naming? When I'm writing a query often I'm fine with something auto-generated when starting out.

Re: PRQL – A proposal for a better SQL

#143

Post by tester756 » Mon, Jan 24, 2022, 9:33 PM UTC

spullara wrote: post #135

SQL could get a lot better by just adopting the ordering of operations like they did with LINQ: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Funnily enough LINQ Query syntax is really uncommon and everybody uses method syntax

var list = new List{1,2,3}

var extracted = list

....................Where(x => x > 1)

....................Select(x => $"my number: {x})

....................ToList();

Re: PRQL – A proposal for a better SQL

#144

Post by dragonwriter » Mon, Jan 24, 2022, 9:35 PM UTC

> It's not declarative. It's functional.

Functional, logical, and relational paradigms are the most commonly cited examples given of declarative programming.

Re: PRQL – A proposal for a better SQL

#145

Post by skissane » Mon, Jan 24, 2022, 9:35 PM UTC

How does this compare to QUEL?

Or Tutorial D?

Re: PRQL – A proposal for a better SQL

#146

Post by [deleted] » Mon, Jan 24, 2022, 9:36 PM UTC

phailhaus wrote: post #112

_jal wrote: post #102

Earlier quoted context omitted.

Designing languages around autocomplete is like designing toilets for better toilet paper dispensers. The language should be right for human understanding, not automated mad-lib generation.

Building for autocomplete is building for human understanding. If it is impossible for a computer to determine the context of your query, why would a human do much better?

[deleted]

Re: PRQL – A proposal for a better SQL

#147

Post by taeric » Mon, Jan 24, 2022, 9:36 PM UTC

tester756 wrote: post #141

taeric wrote: post #127

Earlier quoted context omitted.

Maybe in gigantic systems with more tables than makes sense. Realistically, all of the columns available in a database can be fit in memory with ease. Then, the ide could basically fill my from out for me, based on what I'm asking for. Can even suggest what join I will need, if I list columns from multiple tables.

>Maybe in gigantic systems with more tables than makes sense. Realistically, all of the columns available in a database can be fit in memory with ease. Every table has more than one column So there's always more columns to remember than tables and generally tables are pretty easy like user invoices blabla I worked with systems that had like 500 tables and some of them with 20-50 columns you really want good intellise…

500 times 50 is still not a big number. And you could do decent statistical suggestions on the current columns in.

Good intelligent suggestions is, of course, helpful. And I agree that suggesting one of 500 is easier than the other. That said, neither is hard for a computer. And even asking friends what table I want will often be done with starting with the actual columns I want.

Re: PRQL – A proposal for a better SQL

#148

Post by tester756 » Mon, Jan 24, 2022, 9:38 PM UTC

taeric wrote: post #147

tester756 wrote: post #141

Earlier quoted context omitted.

>Maybe in gigantic systems with more tables than makes sense. Realistically, all of the columns available in a database can be fit in memory with ease. Every table has more than one column So there's always more columns to remember than tables and generally tables are pretty easy like user invoices blabla I worked with systems that had like 500 tables and some of them with 20-50 columns you really want good intellise…

500 times 50 is still not a big number. And you could do decent statistical suggestions on the current columns in. Good intelligent suggestions is, of course, helpful. And I agree that suggesting one of 500 is easier than the other. That said, neither is hard for a computer. And even asking friends what table I want will often be done with starting with the actual columns I want.

On the other hand I don't see why it couldnt work both ways

if you start query with

SELECT MiddleName then you could receive auto complete thats adds "FROM Users" and moves your cusor after MiddleName.

if you start query with

FROM Users SELECT _ and know intellisense drops list of columns

Re: PRQL – A proposal for a better SQL

#149

Post by keithnz » Mon, Jan 24, 2022, 9:41 PM UTC

inglor wrote: post #113

_jal wrote: post #102

Earlier quoted context omitted.

Designing languages around autocomplete is like designing toilets for better toilet paper dispensers. The language should be right for human understanding, not automated mad-lib generation.

You would think that but having used both I find writing Kusto/KQL much smoother, neater and faster and if I have to choose between writing a query in either one I'd pick KQL. I understand this is just an opinion but it's an opinion held by everyone in my org who writes both. Theoretical correctness loses to pragmatism a lot and I'd read the KQL every day. Look at the examples at https://docs.microsoft.com/en-us/azur…

now if MS made a KQL -> TSQL or support it natively in SQL Server, that would be great :)

Re: PRQL – A proposal for a better SQL

#150

Post by majkinetor » Mon, Jan 24, 2022, 9:43 PM UTC

inglor wrote: post #98

galkk wrote: post #88

I'm quite opposed to the idea "from should be first". I want to understand what exactly the query returns, not the implementation detail of the source of this data (that can later be changed). Literally first example from page - I have no idea what is being returned: from employees filter country = "USA" # Each line transforms the previous result. let gross_salary = salary + payroll_tax # This _adds_ a column / varia…

The big advantage of "from first" like we have in Kusto KQL (a database we use at Microsoft) is that it provides much better autocomplete (if I write the `from` it can easily autocomplete the projection). If you want an interesting example of how a query language built for developer experience and autocompletions looks definitely check it out!.

Too bad we can't use Kusto with anything except Azure.