I agree with the premises, but the result proposed here doesn't look like anything I would like to use unfortunately. Even just looking at a glance you cannot see what it's doing and what each part means.
Rethinking Database Programming
21–30 of 167 posts
Re: Rethinking Database Programming
#22Earlier quoted context omitted.
SQL is a horrible language. I’d gladly program in something composable like Elm.
As a programming language? Sure. As a way to work with relational data? It may be my favorite "language" across all domains because of the terse beauty. I am a self-taught, no CS coder but SQL is the one place where I feel like I get all the math I should know. An opinionated, possibly hot take would be to call SQL "A more elegant weapon of a civilized age".
Or “the worst query language ever, except for all the alternatives”
Re: Rethinking Database Programming
#23Looks 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…
> …can't help but notice how sql is coming from the c-Era of programming. Having … more modern ways to express my queries would be great to improve correctness …
SQL is based in pure mathematics: set theory, relational algebra.
The process of applying mathematical rigor to your database design to prove correctness is referred to as normalization.
I don’t mind criticisms like “It’s old, yuck”, but criticisms like “it’s not correct” mean you haven’t studied or applied the mathematical underpinnings of sql.
Re: Rethinking Database Programming
#24This looks reasonably interesting, and Evan is extremely thoughtful about design; I know he’s put a huge amount of work into this. Personally, I’d be very cautious about adopting closed-source software with such a restrictive license as part of an application, especially given the context of Elm’s trajectory. When Elm went through breaking changes or regressions, or was not worked on publicly for years, users had acc…
On the other hand, with Elm there was no correlation between adoption and funding for development. With Acadia, he's trying a different funding model, so that might mean better support for both Acadia and Elm.
Re: Rethinking Database Programming
#25I was hoping for an alternative to PLSQL or stored procedures. But this isn’t about „Database Programming“, it’s a SQL replacement…
It isn't that bad, at least for those of us that like Ada, and feel at home on SQL Developer.
Re: Rethinking Database Programming
#26I'm wary of languages that seek to own the database. In particular, the claim "Coexist with SQL" seems a bit suspect given that e.g. sum types have a custom binary encoding, which likely makes them difficult to interop with from other languages. This makes the claimed interop with other languages really more of a temporary stopping point towards full Acadia adoption rather than a viable long-term equilibrium, unless…
I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported natively by databases
Re: Rethinking Database Programming
#27Is it an ORM?
Re: Rethinking Database Programming
#28Or just let the language be the database like
https://en.wikipedia.org/wiki/MUMPS
;)
Re: Rethinking Database Programming
#29Is it an ORM?
From the homepage https://acadia.engineering/:
| Not an Object-Relational Mapping (ORM).