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

121–130 of 167 posts

Re: Rethinking Database Programming

#121

Post by schaefer »

huahaiy wrote: post #74
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.

I'm curious if you've personally used datalog in any projects. I've written some prolog, but haven't ever worked with datalog.

Minigraph looks promising for some introductory goofing around.

Re: Rethinking Database Programming

#122

Post by treebeard901 »

The main arguments presented are that databases do not support modern types.. And that this system replaces tested authentication systems by emailing a UUID in plain text?

It does mention UInt64 which is not a modern type and as far as I know is supported by every database.

It also compiles to SQL but it isnt clear where the advantage comes from other than using a different syntax to do things.

Re: Rethinking Database Programming

#123

Post by pjmlp »

setr wrote: post #120
pjmlp wrote: post #114

Earlier quoted context omitted.

Only because some people are very opinated in avoiding stored procedures, and think smashing strings together is a much better solution.

PL/SQL is cursed and the unstandardized library system means every DB’s ecosystem is anemic. Instead of smashing strings, you can code with all the affordances of C90 and still get the chance to smash strings together if you need to do anything beyond utilizing simple variables (EXECUTE) — now with an even worse string manipulation stdlib. And you also get the privilege of working with the some of the most worthless…

PL/SQL is great and using SQL Developer definitely better than smashing strings together.

If only C90 was half as good.

Re: Rethinking Database Programming

#124

Post by setr »

geophile wrote: post #110

I have a very long history with language interfaces to databases. - As a grad student in the 80s, I read a lot about "database programming languages", which aimed to provide persistence and query capabilities to conventional programming languages, in a seamless way. - The next step to putting those ideas into practice: Participated in a research project on adding database capabilities to a programming language (anyon…

The thing I’ve never understood is why SQL itself is not the target of attack. There’s already an inherent language abstraction with the planner; Postgres in theory could be the JVM with any number of languages implemented on top. Including a language that lends itself to composition and auto generation of PL functions.

ORMs are fundamentally difficult because of the mapping problem, but SQL code builders should be trivial. Auto-generating and exposing every DB functionality as a type-safe $LANG function should be trivial. Instead, they’re also accidentally difficult because building SQL is difficult.

Outside of SQL, you’ve got datalog… and that’s about it. And I guess whatever horrors the NoSQL crowd keeps coming up with

Re: Rethinking Database Programming

#125

Post by jasomill »

closeparen wrote: post #91
ninkendo wrote: post #86

Earlier quoted context omitted.

SQL has one flaw: The verb should come last. So, "FROM users WHERE id = 1 DELETE" or "FROM users WHERE email = 'foo@example.com' SELECT id". That'd cut back on some accidental "oops I dropped the whole table" because I submitted a delete query before writing the where clause. Other than that, it's perfect, no notes.

The part that has stood the test of time and genuinely seems to carve reality at the seams is the query part. The data definition and data manipulation parts are just ok.

Even so, "FROM t SELECT t.foo, …" has an ergonomic advantage over "SELECT t.foo, … FROM t" in that editors can autocomplete column names without needing to backtrack while editing.

IIRC, this is why C# query syntax uses the former.

Re: Rethinking Database Programming

#126

Post by jasomill »

G4BB3R wrote: post #72
brodo wrote: post #62

Earlier quoted context omitted.

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.

Unless they make a point to always travel separately, this seems more like a variable bus factor between 1 and 2, just as the Presidency of the United States has a much lower bus factor during the State of the Union address.

Re: Rethinking Database Programming

#128

Post by ameliaquining »

pjmlp wrote: post #114
setr wrote: post #112

Earlier quoted context omitted.

Learning SQL doesn’t absolve you from the fact that, from the perspective of your PL, you’re smashing arbitrary strings together like a Neanderthal, and you can be offered all the support otherwise given to your string smashing problems (exactly none) It also doesn’t absolve the fact that SQL is not a particularly well-designed language for smashing strings together like a Neanderthal. In fact, you might even say it’…

Only because some people are very opinated in avoiding stored procedures, and think smashing strings together is a much better solution.

Stored procedures have the wrong versioning model. If they were version-locked to the application code, instead of to the database schema, they'd be less of a pain and people might be more willing to use them.

Re: Rethinking Database Programming

#129

Post by johnthescott »

huahaiy wrote: post #74
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.

pretty sure clang is older than sql. hal agrees.

Re: Rethinking Database Programming

#130

Post by dwohnitmok »

miniBill wrote: post #88
dwohnitmok wrote: post #40

Oh 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…

I mean, it's the same for - say - Photoshop?

No, not at least for Photoshop. If you have the subscription version and fail to pay it downgrades you to the free version which has more limited editing capacity but still has read capacities.

More broadly I think the only subscription products most software developers are used to where access to data is revoked is cloud infra. Most software stuff follows models like Jetbrains (where e.g. you pay for updates but keep the oldest version). E.g. this is how things like SQL Server or other paid DB technologies work, where you effectively are subscribing to yearly updates, but get to keep the current version if you stop paying the subscription fee.

Post reply on HN