Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Database Programming

acadia.engineering

Post reply on HN
Print view View original

71–80 of 167 posts

Re: Rethinking Database Programming

#71

Post by groundzeros2015 »

alpinisme wrote: post #51
mike_hearn wrote: post #45

The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints? Look at all the features supported here: https://www.postgresql.org/docs/current/sql-createtable.html…

The point is end to end type safety. Whether that is worth the tradeoff of losing direct developer access to the db primitives is another question.

SQL is end to end type safe.

Re: Rethinking Database Programming

#72

Post by G4BB3R »

brodo wrote: post #62
ModernMech wrote: post #32

Earlier quoted context omitted.

The Elm project forked into a bunch of different Elms because Evan basically abandoned / killed it. Then he got more interested with this project. What’s to say that won’t happen again?

I would make the larger point that I do not like my software to depend on any software with a bus factor of one that I can't control. Elm had this problem and Acadia has it too.

The bus factor for Elm is currently 2, since Tereza (his Wife) works on both Elm and Acadia.

Re: Rethinking Database Programming

#73

Post by huahaiy »

janderland wrote: post #13
pelagicAustral wrote: post #5

So this is capable of turning a one-liner of SQL into six lines of barely readable code?

SQL is a horrible language. I’d gladly program in something composable like Elm.

Agree. Datalog could be a better alternative: https://datalevin.org/docs/preface

Re: Rethinking Database Programming

#74

Post by huahaiy »

raumgeist wrote: post #9

Looks very nice. Last year I took up rust, coming from c++, and some of the modern features rust brings are just so nice to have (even something as simple as not having to forward declare a class). This year I started working with postgres and you just can't help but notice how sql is coming from the c-Era of programming. Having better and more modern ways to express my queries would be great to improve correctness a…

It is older than C. It is based on COBOL era idea of structured English as a computer language. There are better alternatives, e.g. Datalog.

Re: Rethinking Database Programming

#75

Post by ux266478 »

mike_hearn wrote: post #45

The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints? Look at all the features supported here: https://www.postgresql.org/docs/current/sql-createtable.html…

> Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints?

In Prolog you'd just handle those as metapredicates. There are a million different ways to skin the cat there. For example on partitioning schemes:

  :- vertical_partition(profile/4, [
      core(1, 2),       % UserID, Username -> stored in primary memory
      metadata(1, 3, 4) % UserID, Bio, Preferences -> stored in cold storage
  ]).

Re: Rethinking Database Programming

#76

Post by [deleted] »

brodo wrote: post #62
ModernMech wrote: post #32

Earlier quoted context omitted.

The Elm project forked into a bunch of different Elms because Evan basically abandoned / killed it. Then he got more interested with this project. What’s to say that won’t happen again?

I would make the larger point that I do not like my software to depend on any software with a bus factor of one that I can't control. Elm had this problem and Acadia has it too.

[deleted]

Re: Rethinking Database Programming

#77

Post by bazoom42 »

groundzeros2015 wrote: post #71
alpinisme wrote: post #51

Earlier quoted context omitted.

The point is end to end type safety. Whether that is worth the tradeoff of losing direct developer access to the db primitives is another question.

SQL is end to end type safe.

Isn’t sql weakly typed? Or does this depend on the engine?

Re: Rethinking Database Programming

#78

Post by sharno »

groundzeros2015 wrote: post #71
alpinisme wrote: post #51

Earlier quoted context omitted.

The point is end to end type safety. Whether that is worth the tradeoff of losing direct developer access to the db primitives is another question.

SQL is end to end type safe.

Which end? This moves one end to reach frontend code

Re: Rethinking Database Programming

#79

Post by znpy »

mike_hearn wrote: post #45

The issue with defining schemas in a non-SQL programming language is they always lag behind what the underlying database can do. Sure, your ORM-like framework can define basics like primary keys and maybe uniqueness constraints, but can it define partitioning schemes, compression methods or more advanced constraints? Look at all the features supported here: https://www.postgresql.org/docs/current/sql-createtable.html…

> Look at all the features supported here:

> https://www.postgresql.org/docs/current/sql-createtable.html

Unironcally, yesterday i was vibe-coding a small app for personal use using Django and was quite shocked to discover that Django's orm does not support something as simple as specifying a database schema other than the default "public" one out of the box.

You either have to add options specific from libpq:

    DATABASES = {
        "default": {
            "ENGINE": "django.db.backends.postgresql",
            "NAME": "mydatabase",
            "USER": "myuser",
            "PASSWORD": "mypassword",
            "HOST": "localhost",
            "PORT": "5432",
            "OPTIONS": {
                "options": "-c search_path=myapp,public",
            },
        }
    }
Or you have to do it from the postgresql side:

    ALTER ROLE myuser
    IN DATABASE mydatabase
    SET search_path = myapp, public;
It's not ergonomic at all.

Re: Rethinking Database Programming

#80

Post by CopyOnWrite »

By now I stopped counting the attempts to replace SQL.

There is a lot of valid critic for SQL and I would be very happy if some things would have been designed different.

OTOH the architecture and mathematics behind relational databases are simple, composable and stood the test of time more than most other designs, methodologies or approaches to software development.

Though SQL can be improved, even with my average SQL skills I never had trouble getting information out of a database and fancy stuff like window functions make to my understanding even standard SQL Turing complete.

SQL has the native database support, for most companies the data and the database will outlive any specific application or even the whole ecosystem of a programming language/platform (Visual Basic, Visual FoxPro, Python 2, ...)

Further, we have fantastic books, knowledge, ORMs, query builders and a gigantic ecosystem in tools for SQL and SQL databases.

Acadia might be brilliant from a technological point of view, but it does not matter, because it does not look like a big enough improvement compared to SQL that it seems worth to invest in it. I will rather improve my knowledge of standard SQL or my knowledge for a specific relational database.

Finally Acadia does not really seem to raise the bar compared to other ORMs/Query builder. I get that from a FP point of view map/filter are nicer than a SELECT ... WHERE, but at some point in the projects I participated one would end up interacting directly with the database anyway, and at that moment I am back at SQL, so what did I gain?

Post reply on HN