Earlier quoted context omitted.
I think it's fair to say there are other ways to interpret what happened with Elm. What if Evan stopped working on it because he needed to make a living and working on Elm wasn't going to achieve that? In that case, if working on Acadia will earn him a a living, it seems reasonable to believe he will keep working on it.
That is fair but I think that there’s not a clear thing from Evan we can point to which explains it contributes to the uncertainty in this new project. Makes me feel we should be wary of a repeat. If anything it seems what he learned from his experience with Elm is that the project should not have been open, and his main problem seemed to be community relations. Evan’s reputation precedes him so I’m sure Acadia will…
Rethinking Database Programming
41–50 of 167 posts
Re: Rethinking Database Programming
#42stuff like "The endpoint keyword" just gets a mention on the front page/readme with no further detail
Re: Rethinking Database Programming
#43Despite their claims, this is not substantially different from ORM platforms in many languages.
Re: Rethinking Database Programming
#44Earlier quoted context omitted.
That is fair but I think that there’s not a clear thing from Evan we can point to which explains it contributes to the uncertainty in this new project. Makes me feel we should be wary of a repeat. If anything it seems what he learned from his experience with Elm is that the project should not have been open, and his main problem seemed to be community relations. Evan’s reputation precedes him so I’m sure Acadia will…
Do you nurse a personal grudge?
Re: Rethinking Database Programming
#45Look at all the features supported here:
https://www.postgresql.org/docs/current/sql-createtable.html
And then consider that other databases have even more. If you manage your schemas in code then you lose access to all of those, and will eventually need to write SQL anyway.
For queries it isn't such a problem, especially if you have a nice compiler. However, I recently lost faith in SQL wrappers/abstractions. The usual justification was that a lot of developers don't know SQL well, but LLMs are great at it. It's easier for the LLM to write SQL than some less familiar DSL. And SQL was written to be relatively easy to understand, especially if you do things like use CTEs and views correctly it should be possible to factor logic out to make even complex queries understandable.
The question for frameworks like Acadia is really: assuming I am fluent in SQL and know every feature of my database, what does the framework buy me? Because that's the perspective an LLM comes to it with.
Re: Rethinking Database Programming
#46So 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.
SQL is a horrible language in the same way Excel is -- programmers hate it but the what makes it a horrible programming language to developers is what makes it accessible to non programmers.
Re: Rethinking Database Programming
#47Earlier 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 think it's fair to say there are other ways to interpret what happened with Elm. What if Evan stopped working on it because he needed to make a living and working on Elm wasn't going to achieve that? In that case, if working on Acadia will earn him a a living, it seems reasonable to believe he will keep working on it.
https://acadia.engineering/license/faq
The way I read this, Acadia is an attempt to finance working on both it and Elm.
Re: Rethinking Database Programming
#48Earlier quoted context omitted.
> …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’…
Syntax aside, programmers and mathematicians have a very different view on how things should be done. Programmers look at data and see opportunities for running a pipeline of transformations (map/filter/...). And they tend to write their SQL like this as well. Or use something like Linq or one of the various pipe syntax SQL extensions. I would say that this is a major reason why there is this sentiment of "SQL is yuc…
SQL is closer to array programming than the usual imperative implementation of looping (and stream programming like the one in Java and Javascript). A better implementation is functional programming like haskell and clojure (lazy and composition of functions).
I think developers should be able to switch their mental model on the fly according to the current domain instead of getting stuck in the first paradigm they have learned.
Re: Rethinking Database Programming
#49Is this at all similar to LINQ in C#? I never used it, but I'm vaguely aware of it being a functional approach to querying an RDBMS.
Re: Rethinking Database Programming
#50Oh man. If this lobste.rs comment is correct about the subscription terms then this feels like a really hard pill to swallow: https://lobste.rs/s/ykq7ym/rethinking_database_programming#c... Still might be viable, but would be tricky to sell. > SUBSCRIPTION TERMS > This license is subscription-based and will remain valid only for the duration of your active subscription. Upon expiration or termination of your subscrip…