Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • At the bottom is the actual code for the "language", which is only 79 lines.

    I found it helpful to read it first and then go back to the article. (On my initial reading I was like, "okay, but what is a Rel?")

    https://github.com/remysucre/prela/blob/main/tutorial/prela....

    by andai
  • Interesting concept which reminds of the operations available in pandas.

    I disagree though with the statement of SQL needing 20 lines. The given query feels verbose and has lots of redundant conditions. Not saying that it is short but a better analogy could look like this:

    SELECT DISTINCT an.name, t.title

    FROM keyword k

    JOIN movie_keyword mk ON mk.keyword_id = k.id

    JOIN title t ON t.id = mk.movie_id

    JOIN movie_companies mc ON mc.movie_id = t.id

    JOIN company_name cn ON cn.id = mc.company_id

    JOIN cast_info ci ON ci.movie_id = t.id

    JOIN aka_name an ON an.person_id = ci.person_id

    WHERE k.keyword = 'character-name-in-title' AND cn.country_code = '[us]';

    by prathje
  • Looks a lot like 6NF (https://en.wikipedia.org/wiki/Sixth_normal_form)
    by mwcremer
  • This seems harder to read than SQL, and only less verbose if you assume that an SQL database would be built with Prela's limitations in mind, which doesn't feel like a reasonable assumption.
    by Planktonne
  • The example is not particularly impressive. The SQL equivalent is much easier to understand, which means it is easier to maintain. Number of lines is not an interesting metric; understandability and maintainability are more important.
    by petilon
  • You’ve got do a better job selling the title sorry.

    I feel like the separation between a query & the query execution plan is one of the benefits of SQL. I trust the database system to do the right thing 99% of the time, and I don’t want to think about that either really.

    by grebc
  • Author here, I will be at VLDB in Boston this coming week and will be very happy to chat about Prela.

    Unrelated, we also have a tutorial on instance-optimal join algorithms: https://www.vldb.org/2026/program.html#tut-2

    by remywang
  • I think an important benefit of a good ORM is to reduce the translations that you have to do between your mental model of the data and what you are trying to do with the data.

    Before I started working a lot with SQL, ORMs fit my mental model better since I was more used to imperative programming languages and I thought they were easier to work with.

    Now that I am very comfortable with SQL, I have to translate an ORM into the SQL that it would produce. So now they just add another step in between me and the data

    by slowcache

Explore Birbla archives