You can write selects with many joins, as long they are regular and either add a column or reduce the result set. You have to write the joins explicitly though. Just shoving all of the restrictions into the where clause will definitely confuse everybody.

How else would you send spam or stage a DDOS attack? /s

Just rewatched “The Visitor”. Can’t believe I forgot about that one. I’m definitely not crying right now, no no. Thank you.

Well, you can still have the up-to-date plugin, you just have to pay for it now.

Since working with SQLAlchemy a lot (specifically it’s SQL compiler, not it’s ORM), I don’t want to work with SQL any other way. I want to have the possibility to extract column definitions into named variables, reuse queries as columns in other queries, etc. I don’t want to concatenate SQL strings ever again.

Having a DSL or even a full language which compiles to SQL is clearly the superior way to work with SQL.

I’m wondering if a field with more detailed information would be helpful for the users. Moderators might want to clarify or explain in more detail the function or intention behind a tag. This doesn’t seem to be considered in the RFC.

deleted by creator

Depends on how large your Python projects are. If you have a million lines of Python code, navigating quickly and directed is invaluable.

I used plain vim before for Python projects, but these never grew above 50k lines of code.

I never got so far, but had a system built which some parts of what you described. It was incredibly relaxing to develop with it. Our take as a team was: boring is better, we don’t want to be paged on weekends.

It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.

Completely agree. I really love SQL, but I hate it’s syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).

Python development without PyCharm (or IntelliJ) and the IdeaVim plugin is unbearable. List usages is a game changer. Don’t care much for anything else.

You could be onto something. On of my first language was “dBase” (early 90s) which, through it’s style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.

deleted by creator

The way I perceive PRQL is somewhat like SQLAlchemy-Core (the SQL expression layer, not the ORM). Almost a 1:1 mapping to SQL but softening the rough edges in SQL when constructing more complex queries dynamically, in particular: no function calls, no real variables, only string concatenation. While SQLAlchemy-Core lets you even extract sub-queries into variables, I don’t know about how powerful PRQL is in this regard.

From what I see from the docs I’m rather hopeful though.

In order to compete in user experience we need to up our game. We need to set up communities which collect, categorize and funnel user requests upstream. These features should be focused on:

• reducing frictions like unclear UI, broken links, etc.
• improving usability of the various web frontends (the one from Lemmy, kbin, etc.)
• collecting bug reports and making sure they will be fixed

This is meant to be a proxy between average users and tech enthusiasts who know how to do pull requests or open GitHub issues. Moderators of these communities would do it for them. This would enable us to gain visibility in the needs of the users.

This is only a part of what needs to be done, but I think this can be done quickly.